I've noticed this in several games including the Keens, but it's particularly egregious in GTA. If you're walking or driving, for example, your player will stop moving fairly soon, and you'll have to release "Up" and press it again. I've tested this with an unpatched dosbox, revision 4205. I've also tried fake keypresses w/ antimicro and I'm also getting this issue, so it's not an issue with my specific keyboard.
I'm on Linux 5.0.7 with X.org 1.20.4 using libinput 1.13.1. It seems to only happen in fullscreen. I've seen it with output=openglnb and output=overlay.
Can you add a log message (LOG_MSG) same syntax as printf, in sdlmain, gfx_events to see if the problem is in the input (sdl) level or in dosbox itself ?
Definitely something weird is going on with the input events.
1Released: numlock 2Released: numlock 3Pressed: return 4Released: return 5Pressed: return 6Released: return 7Released: numlock 8Released: numlock 9Released: numlock 10Released: numlock 11Released: numlock 12Released: numlock 13Released: numlock 14Released: numlock 15Pressed: return 16Released: return 17Released: numlock 18Released: numlock 19Released: numlock 20Released: numlock 21Released: numlock 22Released: numlock 23Pressed: return 24Released: return 25Pressed: return 26Released: return 27Pressed: return 28Released: return 29Released: numlock 30Released: numlock 31Released: numlock 32Released: numlock 33Released: numlock 34Released: numlock 35Pressed: right 36Released: right 37Pressed: right 38Released: right 39Pressed: right 40Released: right 41Pressed: up 42Released: up 43Pressed: left 44Released: left 45Pressed: up 46Released: up 47Pressed: right 48Released: right 49Pressed: up 50Released: up 51Pressed: up 52Released: up 53Pressed: up 54Released: up 55Pressed: left 56Released: left 57Pressed: up 58Released: up 59Pressed: left 60Released: left
…Show last 63 lines
61Pressed: left 62Released: left 63Pressed: up 64Released: up 65Pressed: left 66Released: left 67Pressed: up 68Released: up 69Pressed: left 70Pressed: up 71Released: left 72Released: up 73Pressed: right 74Released: right 75Pressed: up 76Released: up 77Pressed: left 78Released: left 79Pressed: up 80Released: up 81Pressed: return 82Released: return 83Released: numlock 84Pressed: up 85Pressed: left 86Released: left 87Released: up 88Released: numlock 89Released: up 90Released: numlock 91Released: up 92Released: numlock 93Released: up 94Released: numlock 95Released: up 96Released: numlock 97Released: up 98Released: numlock 99Pressed: right 100Released: right 101Pressed: left 102Released: left 103Pressed: right 104Released: right 105Pressed: left 106Released: left 107Released: up 108Released: numlock 109Pressed: right alt 110Pressed: return 111Released: return 112Released: up 113Released: numlock 114Released: right alt 115Released: return 116Released: right alt 117Pressed: left alt 118Pressed: f3 119Released: up 120Released: f3 121Released: numlock 122Released: left alt
I'm seeing a ton of keyup events for keys I never pressed (numlock, f3), and near the end I'm getting several keyup events for "up" while I'm actively holding the button down.
61Released: left alt - 72355.000175 62Pressed: left alt - 72834.000000 63Pressed: f3 - 73074.000000 64Released: f3 - 73161.000050 65Released: up - 73633.000075 66Released: numlock - 73633.000075 67Released: left alt - 73633.000075
w/ PIC_FullIndex(). You see the second "up" keydown event is followed by 5 keyup events, but I don't release the key at all before closing the app after pressing it the second time.
Very weird.
There is some regularity is the upper part (of 30 milliseconds (between the press and release)
but the 5 releases in a row are all at millisecond level difference
I've experienced this quite a bit as well. Happens a lot with earlier FPS games where I use the keyboard for everything. I think the issue is that newer keyboards like my gaming keyboard are interpreting these massive presses as an error and logic is kicking in to prevent what it thinks are unintended keystrokes? Would be nice if I still had a plain Jane (No offense to Janes) USB keyboard on hand to verify this more.
It also happens quite a lot with older Sierra Adventure games I've noticed since I tend to use the keypad for controller my character. Dosbox seems to have issues registering the diagonals since I will frequently use the up and left or right instead of the actual numpad key to do this. It was how I always played them when I was in my teens on my original 286 as I never got used to using the 1,3,7. and 9 keys for walking diagonal.
Happens a lot with earlier FPS games where I use the keyboard for everything.
Just in dosbox, or in general? The other day I opened up ioquake 3 and ran around an empty map for a bit, but wasn't able to reproduce this there. Definitely will happen after awhile in doom on dosbox, though. Then again, ioquake3 is linked against SDL2, which seems to have changed the way key events worked. I'll have to find something else that still uses sdl1.
Or write a minimal program. If there is definitely an issue with SDL1 on xorg, I could file a bug on freedesktop. But I couldn't get a window open from the online docs because even that has changed in SDL2. 🤣
Xorg has been updating rapidly for the past year so it could be an issue with SDL 1.2 and newer versions of Xorg. If you can try Xorg versions before 1.20 and see if there is still an issue. Those using distros that update frequently seem to be noticing these issues first.
I've really only noticed it in Dosbox. Doom wasn't so bad, but the original Quake sure didn't like it much and now that I think about it, I had the same issue with the no frills logitech usb keyboard I was using with the 10ZIG device too.
Like I said, it is like the antighosting logic of the keyboard is kicking in or that the keyboards do not allow certain combos of keys to be pressed together at the same time and always register properly.
I doubt it's actually the keyboard, or you would see it in other programs and also it wouldn't happen when using a controller w/ antimicro to emulate keypresses. This has got to be a software bug somewhere—either in dosbox or sdl or possibly xorg.
Hmm, I'm on Arch, so it turns out I'm using some of those patches already. I tried building SDL without them (except SDL-1.2.15-const_XData32.patch is needed for the package to actually build) and dosbox was still misbehaving, so I was able to confirm at least that the bug isn't caused by some downstream sdl patch.
1Pressed: up - 692 2Released: up - 11627 3Pressed: up - 11629 4Released: up - 40105 5Pressed: up - 40107 6Released: up - 78541 7Pressed: up - 78542 8Released: up - 95094 9Pressed: up - 95094
from just holding the button down. Is this what you would expect qbix? I'm not getting the weird numlock thing with this. Is there a way to make this example program more similar to whatever dosbox is doing?
Aaronp,
Is it reproduceable just sitting at the DOSBox prompt? (prior to launching doom)
If not, then it feels somewhat like a cpu starvation issue; for example if the single DOSBox thread is over-scheduled and sdl's event handler function is not context-switched to in time for sdl to consider the key still down.
If that's true, you could try launching doom with cpu-frugal settings (which should provide enough performance to keep doom smooth with ample free cycles on the core its running on):
core = dynamic
cputype = auto
cycles = max 50% limit 36000
Can you reproduce it in doom using those?
2019-Sept-22 EDIT: For those reading through this thread from the start, I wrote the above when I was using Ubuntu 18.04.
I've since updated to 19.04 (and newer X Org version) and now DOSBox repeatedly and rapidly drops and 'unpresses' keys that I'm actually holding down. By making game control unreliable and frustrating, this issue has rendered DOSBox SVN unusable for even casual gaming on Linux for me, across all of my games except pure text entry like Adventure and Zork.
Last edited by krcroft on 2019-09-22, 14:33. Edited 3 times in total.
I wasn't able to reproduce in doom using those settings, at least not in a few minutes of running around the acid pit in e1m1. It always took awhile to reproduce in doom though. I can still reproduce in gta very quickly with those settings, though. I wanted an excuse to say something like "john carmack didn't write gta though", but then I remember I've seen this bug in Commander Keen as well 😜
Did you try logging other functions in sdlmain that generate sdl keyboard events? At least for comparison between the windowed and fullscreen modes (output=opengl or =overlay).
I wasn't able to reproduce in doom using those settings, at least not in a few minutes of running around the acid pit in e1m1. It always took awhile to reproduce in doom though. I can still reproduce in gta very quickly with those settings, though. I wanted an excuse to say something like "john carmack didn't write gta though", but then I remember I've seen this bug in Commander Keen as well 😜
I think we're getting somewhere. GTA needs 60,000 cycles at low resolution and 180,000 cycles at high, plus headroom for SDL -> OS -> drivers -> hardware (and vice-versa).
On my my i7-6700k@4.2Ghz, DOSBox at 180,000 cycles consumes roughly 60% of one core, which provides plenty of headroom for the OS. To test this in GTA, I run laps around the building where he starts - I can do 5+ laps on one "up arrow" press & hold, while periodically also tapping the left-arrow to steer him around the corners. I haven't been able to reproduce the lost-key scenario once. Let me know if it takes longer to reproduce.. but 5 laps feels like quite a while 😀
Here's my GTA-specific deltas to dosbox-SVN.conf (I've configured GTA to use Gravis audio)
Start up GTA in windowed-mode, Ctrl+F10 to regain your mouse, then open a new terminal along side it and run 'top'. What percent of your CPU is DOSBox consuming? Here's mine:
1top - 20:07:04 up 11 days, 23:21, 7 users, load average: 1.49, 1.13, 1.66 2Tasks: 288 total, 2 running, 193 sleeping, 0 stopped, 1 zombie 3%Cpu(s): 8.2 us, 1.5 sy, 1.5 ni, 86.7 id, 0.8 wa, 0.0 hi, 1.2 si, 0.0 st 4MiB Mem : 15903.21+total, 817.691 free, 5225.512 used, 9860.012 buff/cache 5MiB Swap: 50890.28+total, 50720.28+free, 170.000 used. 8592.211 avail Mem 6 7 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 816745 kcroft 20 523.8m 103.0m 12.1m R 60.5 0.6 0:27.36 dosbox 9 6162 kcroft 32 12 887.0m 185.9m 151.9m S 4.0 1.2 165:19.89 Xorg 1020232 kcroft 32 12 115.0m 35.9m 5.7m S 3.3 0.2 242:09.80 ia 1119207 kcroft 32 12 114.2m 35.0m 5.6m S 2.7 0.2 149:06.43 ia 12 647 root -51 S 2.3 463:47.36 irq/140-iwlwifi 13 6382 kcroft 28 8 1409.3m 10.7m 8.0m S 1.7 0.1 39:25.01 pulseaudio
2019-Sept-22 EDIT: For those reading through this thread from the start, I wrote the above when I was using Ubuntu 18.04.
I've since updated to 19.04 (and newer X Org version) and now DOSBox repeatedly and rapidly drops and 'unpresses' keys that I'm actually holding down. By making game control unreliable and frustrating, this issue has rendered DOSBox SVN unusable for even casual gaming on Linux for me, across all of my games except pure text entry like Adventure and Zork.
Last edited by krcroft on 2019-09-22, 14:34. Edited 1 time in total.
Sorry for the late reply. Video games happened, you know how it is.
Actually, this experiment reminded me that this issue doesn't happen at all in windowed mode, so I don't think it's necessarily a cpu utilization issue anymore. Oddly, I also only use about 60% cpu at 180k cycles, despite having a much slower cpu (2.66 ghz core 2 quad). I thought this might be because of Gnome's compositor forcing vsync, but I saw the same cpu usage in openbox without a compositor. I've also confirmed that this isn't an issue specifically with Gnome (happens in Openbox) or with libinput (happens if I run sudo cp /usr/share/X11/xorg.conf.d/10-evdev.conf /etc/X11/xorg.conf.d/). It also happens in Gnome Wayland with usescancodes=false.
The time to reproduce is usually just a few seconds. Sometimes it's a little longer, but usually less than a minute.
It seems I had a similar problem with magically releasing keys (arch vanilla and in modded dosbox builds), just checked out revision 4228 however and now it seems to be gone, can any of you recheck if it fixed something for you too?
Thanks again for Qbix pointing me to this thread 😀