Common searches

Dosbox dropping pressed keys?

Topic actions

Reply 40 of 44, by ZakMcKracken

User metadata
Rank Newbie

Using aaronp's sdl_test I got the following results on arch using gnome3:
After seeing the cursor pressing and holding "down arrow",
approximately 5 seconds later single press of space while still holding "down arrow"
and keeping "down arrow" pressed for around 5 seconds and quitting with esc while still holding it down.

default key repeat settings:
Pressed: down - 2619
Pressed: space - 7804
Released: space - 7976
Released: down - 9478
Released: down - 10980
Released: down - 12481

disabled gnome3 key repeat (universal access settings):

Pressed: down - 2169
Released: down - 3670
Released: down - 5171
Released: down - 6673
Pressed: space - 7303
Released: space - 7430
Released: down - 8931
Released: down - 10433
Released: down - 11935

So using no repeat actually releases the key even before pressing space , I am confused...
But seeing this now I remembered using Linux Multimedia Studio music software (also using SDL1)
The piano roll can be played with the keyboard, and when holding a note (with enabled key repeat), it will release by its own and start repeating the key.

The repeats while holding a note there are:
8000ms / 13000ms / 13400ms / 14500ms / 16300ms
This will continue in a seemingly random fashion

But turning off key repeat in gnome3 works ok for LMMS , but not for dosbox.
Could this be a broken key repeat detection ?
Have to check how this is handled using wayland and its XWayland compatibility layer.
EDIT: Scratch that, on my system my dosbox build under wayland gets almost NO KEYS, as in 1 keystroke of 100... so better not explore this any further 😊

Reply 41 of 44, by dreamer_

User metadata
Rank Member

I just compiled and tested DOSBox with SDL2 support and it fixed random KeyUp events in at least one of the titles I experience the problem (Megarace 2). It also fixed DOSBox alt-tab behaviour and I think mouse movement in-game feels more native (I need to properly test this though).

Compiled version: r4258 with rebased patch from SDL 2.0 thread. You can find exact code I used in my git repo: dreamer/dosbox-staging, on branch po/sdl2-1.

I purged SDL1.2 headers from my system to make sure it compiles and uses SDL2 - this removed imgmount support due to missing SDL_sound headers, so can't test with Tomb Raider at the moment.

| ← Ceci n'est pas une pipe

Reply 42 of 44, by DosFreak

User metadata
Rank l33t++

Did some digging and it looks like the fixes for the missing keys and using both monitors for one output were added to SDL2 between 2012-2013 . Comparing SDL1.2 to SDL2 right now. Seems pretty minor.

< SDL 2.0.2 should have the same behavior as SDL 1.2 but haven't verified yet.

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

Reply 43 of 44, by dreamer_

User metadata
Rank Member

DosFreak, nice 😀 hopefully you'll be able to bisect the change. In the meantime I made my copy of TR1 work without the need for SDL_sound, so I could test input in SDL2 build - with the same result: input worked correctly in fullscreen, in SDL2-based build. Then I tried openglide (SDL1) - and input issue came back (but was harder to trigger). In the process I found out, that SDL2_sound library appeared in 2018, but never reached releasable-state - tried SDL2 build + SDL2_sound, but it crashes in TR1 (works with other games, but e.g. ogg decoding is a bit borked).

| ← Ceci n'est pas une pipe

Reply 44 of 44, by Vladimir

User metadata
Rank Newbie

I had the same problem for at least two years now. I also concluded some things:

It only happens in Linux: Any BSD or Windows works fine. I used to have FreeBSD just for DosBox
I also concluded it is a bug on SDL1.2

I couldn't solve without removing SDL1.2, so I had to compile DosBox-X. That let me compile directly with SDL2 and not lose imgmount capabilities. In any case DosBox has a lingering and annoying bug on this, at least under Linux