VOGONS

Common searches


Dosbox dropping pressed keys?

Topic actions

First post, by aaronp

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 1 of 46, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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 ?

Water flows down the stream
How to ask questions the smart way!

Reply 2 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

Definitely something weird is going on with the input events.

Released: numlock
Released: numlock
Pressed: return
Released: return
Pressed: return
Released: return
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Pressed: return
Released: return
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Pressed: return
Released: return
Pressed: return
Released: return
Pressed: return
Released: return
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Released: numlock
Pressed: right
Released: right
Pressed: right
Released: right
Pressed: right
Released: right
Pressed: up
Released: up
Pressed: left
Released: left
Pressed: up
Released: up
Pressed: right
Released: right
Pressed: up
Released: up
Pressed: up
Released: up
Pressed: up
Released: up
Pressed: left
Released: left
Pressed: up
Released: up
Pressed: left
Released: left
Show last 63 lines
Pressed: left
Released: left
Pressed: up
Released: up
Pressed: left
Released: left
Pressed: up
Released: up
Pressed: left
Pressed: up
Released: left
Released: up
Pressed: right
Released: right
Pressed: up
Released: up
Pressed: left
Released: left
Pressed: up
Released: up
Pressed: return
Released: return
Released: numlock
Pressed: up
Pressed: left
Released: left
Released: up
Released: numlock
Released: up
Released: numlock
Released: up
Released: numlock
Released: up
Released: numlock
Released: up
Released: numlock
Released: up
Released: numlock
Pressed: right
Released: right
Pressed: left
Released: left
Pressed: right
Released: right
Pressed: left
Released: left
Released: up
Released: numlock
Pressed: right alt
Pressed: return
Released: return
Released: up
Released: numlock
Released: right alt
Released: return
Released: right alt
Pressed: left alt
Pressed: f3
Released: up
Released: f3
Released: numlock
Released: 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.

Reply 3 of 46, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

numlock can be a weird, but f3 and the keyup for up are weird

Can you add the time index as well ?

PIC_FullIndex() 

(returns double) include is pic.h
Maybe something similar to

SDL_XORG_FIX

is needed, but that would not be nice.

Water flows down the stream
How to ask questions the smart way!

Reply 4 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

On second thought, the f3 is just me trying to hit alt+f4, so that can be ignored.

Released: numlock - 6.000025
Released: numlock - 6.000025
Pressed: return - 1277.000100
Released: return - 1342.000100
Pressed: return - 1677.000000
Released: return - 1757.000000
Released: numlock - 3257.000050
Released: numlock - 4980.000025
Released: numlock - 6480.000000
Released: numlock - 7981.000075
Released: numlock - 9481.000025
Released: numlock - 10982.000000
Released: numlock - 12482.000150
Released: numlock - 13982.000025
Pressed: return - 15204.000000
Released: return - 15268.000050
Released: numlock - 16768.000025
Released: numlock - 18269.000150
Released: numlock - 19768.000050
Released: numlock - 21269.000100
Released: numlock - 22770.000025
Released: numlock - 24270.000000
Pressed: return - 24413.000050
Released: return - 24492.000000
Pressed: return - 24987.000100
Released: return - 25060.000050
Pressed: return - 25604.000075
Released: return - 25660.000025
Released: numlock - 27160.000275
Released: numlock - 28661.000125
Released: numlock - 30161.000100
Released: numlock - 31662.000200
Released: numlock - 33162.000025
Released: numlock - 34661.000025
Pressed: right - 35469.000050
Released: right - 35772.000000
Pressed: up - 36349.000075
Released: up - 57379.000075
Pressed: left - 57698.000000
Released: left - 58379.000050
Pressed: up - 59722.000150
Pressed: left - 65292.000050
Released: left - 65523.000075
Pressed: left - 65899.000000
Released: left - 66058.000075
Pressed: right - 66364.000125
Released: right - 66818.000100
Released: up - 68317.000125
Released: numlock - 68317.000125
Released: up - 69818.000100
Released: numlock - 69818.000100
Released: up - 71319.000025
Released: numlock - 71319.000025
Pressed: left alt - 72115.000250
Pressed: return - 72211.000050
Released: return - 72211.000050
Released: up - 72211.000050
Released: numlock - 72211.000050
Released: left alt - 72211.000050
Released: return - 72274.000100
Show last 8 lines
Released: left alt - 72355.000175
Pressed: left alt - 72834.000000
Pressed: f3 - 73074.000000
Released: f3 - 73161.000050
Released: up - 73633.000075
Released: numlock - 73633.000075
Released: 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.

Reply 5 of 46, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Water flows down the stream
How to ask questions the smart way!

Reply 6 of 46, by CrossBow777

User metadata
Rank Member
Rank
Member

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.

g883j7-2.png
Midi Modules: MT-32 (OLD), MT-200, MT-90, SD-20

Reply 7 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie
CrossBow777 wrote:

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. 🤣

Reply 8 of 46, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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.

Mouse capture not working in Linux with Xorg 1.20.x

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 9 of 46, by CrossBow777

User metadata
Rank Member
Rank
Member

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.

g883j7-2.png
Midi Modules: MT-32 (OLD), MT-200, MT-90, SD-20

Reply 10 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

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.

Oh. Are you on Linux?

Reply 11 of 46, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

There are some similar issues that are patched post SDL 1.2.15 but not upstreamed https://discourse.libsdl.org/t/interest-in-a- … release/24784/8 that may be helpful in determining if it's an SDL issue and if so where to look in SDL.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 12 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 13 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

Finally got around to rooting around for the old 1.2 docs. With this program:

#include <stdlib.h>
#include <stdio.h>
#include <SDL/SDL.h>
int poll_events() {
SDL_Event event;
while (SDL_PollEvent(&event)) {
switch (event.type) {
case SDL_KEYDOWN:
if (event.key.keysym.sym == SDLK_ESCAPE)
return 0;
printf("Pressed: %s - %d\n", SDL_GetKeyName(event.key.keysym.sym), SDL_GetTicks());
break;
case SDL_KEYUP:
printf("Released: %s - %d\n", SDL_GetKeyName(event.key.keysym.sym), SDL_GetTicks());
break;
}
}
return 1;
}
int main(void) {
SDL_Init(SDL_INIT_VIDEO);
atexit(SDL_Quit);
SDL_Surface* screen = NULL;
screen = SDL_SetVideoMode( 640, 480, 32, SDL_SWSURFACE );
SDL_Flip(screen);
SDL_GrabMode SDL_WM_GrabInput(SDL_GrabMode mode);
while (1) {
if (!poll_events())
break;
SDL_Delay(1);
}
return 0;
}

I get output like this:

Pressed: up - 692
Released: up - 11627
Pressed: up - 11629
Released: up - 40105
Pressed: up - 40107
Released: up - 78541
Pressed: up - 78542
Released: up - 95094
Pressed: 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?

Reply 14 of 46, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 15 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

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 😜

Reply 16 of 46, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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).

Reply 17 of 46, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
aaronp wrote:

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)

[cpu]
core=dynamic
cycles=fixed 180000

[dosbox]
machine=vesa_nolfb

[dos]
ems=false

[mixer]
nosound=false
rate=48000
blocksize=2048
prebuffer=20

[gus]
gus=on
gusrate=48000
gusbase=240
gusirq=5
gusdma=3

[speaker]
tandy=off
pcspeaker=off
disney=off

[sblaster]
sbtype=none
oplmode=none

[midi]
mpu401=none
mididevice=none

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:

top - 20:07:04 up 11 days, 23:21,  7 users,  load average: 1.49, 1.13, 1.66
Tasks: 288 total, 2 running, 193 sleeping, 0 stopped, 1 zombie
%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
MiB Mem : 15903.21+total, 817.691 free, 5225.512 used, 9860.012 buff/cache
MiB Swap: 50890.28+total, 50720.28+free, 170.000 used. 8592.211 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16745 kcroft 20 523.8m 103.0m 12.1m R 60.5 0.6 0:27.36 dosbox
6162 kcroft 32 12 887.0m 185.9m 151.9m S 4.0 1.2 165:19.89 Xorg
20232 kcroft 32 12 115.0m 35.9m 5.7m S 3.3 0.2 242:09.80 ia
19207 kcroft 32 12 114.2m 35.0m 5.6m S 2.7 0.2 149:06.43 ia
647 root -51 S 2.3 463:47.36 irq/140-iwlwifi
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.

Reply 18 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 19 of 46, by ZakMcKracken

User metadata
Rank Newbie
Rank
Newbie

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 😀