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.

1default key repeat settings:
2Pressed: down - 2619
3Pressed: space - 7804
4Released: space - 7976
5Released: down - 9478
6Released: down - 10980
7Released: down - 12481

disabled gnome3 key repeat (universal access settings):

1Pressed: down - 2169
2Released: down - 3670
3Released: down - 5171
4Released: down - 6673
5Pressed: space - 7303
6Released: space - 7430
7Released: down - 8931
8Released: down - 10433
9Released: 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 😊

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.

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.

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

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

Erm a stupid question of mine, Autolock function is off?
If not it could be the case that if you pressed a key longer as three seconds you will release the autolock function, shut that tard off to play games with the keyboard.
The Problem is most probably not rooted in DOSBox.

Exactly Doom well, a young friend of mine played it not long ago, he likes FPS games a lot and he's somewhat to young to know Doom.
He stumbled very soon over this issue which i fixed to his surprise by simply disabling the autolock function.

I won't claim that this is the solution, but often it's a quite simple one and often not related to the emulator you run.

Always guess only our new OS' assume things you never will like.
They call it "intelligent" i call it stupidity.
Just because 51% of users use it in a certain way it won't mean that it is intelligent if i assume this.

Besides, i still never played Doom for real, he played it through but i like the music mostly 😀

@Gernot66 The problem is rooted in using SDL 1.2, which is unmaintained since 2013. Some Linux distributions are starting to drop SDL 1.2 from the repositories because almost whole open source world moved on to SDL2, DOSBox is one of very few stragglers.

Just dropped in to contribute my similar experiences in GODS while running distribution-specific packages of Dosbox in both latest Arch Linux and Mint 19.3. The spartan becomes unresponsive while a directional movement key is being pressed. I needed to release and press the key again.

EDIT : Installing the SDL2 version (dosbox-sdl2 SVN) from AUR repo in Arch solves this problem.

Looking into this and I just want to confirm that what I'm seeing matches what others are experiencing:
- Switch DOSBox (running under X11) to fullscreen
- Start a game, hold and press any key
- Press and release any other key (while still holding the first)
- 1.5 seconds later, if no other keys have been pressed, DOSBox will act as if the first key was released

Can anyone confirm this behavior?

jmarsh wrote on 2021-01-03, 12:49:

Can anyone confirm this behavior?

On X.Org X Server 1.20.10 I cannot confirm this.

You're out of luck. I suspect you are using an older version 1.20.4 that doesn't include this commit. But I'm not 100% sure if it's this fix, I don't remember.
This was generally the case with the initial versions 1.20.x. It has long been fixed.

Apply the dirty hack. Change the value from 1500 to a higher value and recompile SDL-1.2.
https://hg.libsdl.org/SDL/file/f476ab1f110f/s … 11events.c#l500

latalante wrote on 2021-01-03, 14:12:

You're out of luck. I suspect you are using an older version 1.20.4 that doesn't include this commit. But I'm not 100% sure if it's this fix, I don't remember.
This was generally the case with the initial versions 1.20.x. It has long been fixed.

Earlier in this thread there was a conversation posted with an xorg dev that confirmed that commit did not affect the problem with SDL, since the focus events are valid. It is SDL's handling of them that is wrong.

Apply the dirty hack. Change the value from 1500 to a higher value and recompile SDL-1.2.
https://hg.libsdl.org/SDL/file/f476ab1f110f/s … 11events.c#l500

That's not going to do anything besides change the period before keys are incorrectly released, possibly interfere with switching back to fullscreen when forcibly kicked out of it due to loss of focus and is also an unfeasible long-term solution as DOSBox is not (and will not be) distributed with a statically linked build of SDL.

If you haven't already experienced the problem, great; your input isn't needed. I'm asking the other people who have posted in this thread to confirm their experience matches mine.

Of course I experienced under Archlinux a year and a half ago. I was playing Screamer in dosbox-SVN.
It has been repaired a long time ago, so I do not remember exactly, because I was patching Xorg myself.
In my free time, I will recompile the Xorg-server and check which patch exactly fixes this problem.

I was using this dirty SDL hack anyway. I increased the value from 1500 to 15000 and did not experience any adverse effects. The effect was satisfactory for my modest needs.

I am looking for confirmation of the behaviour of the problem. Telling people to upgrade other packages (or patch and rebuild their own Xorg!) is not a practical solution.

I am currently using the distribution version of Xorg-server-1.20.10. I cannot confirm this error on it.
He is closely related to the Xorg version.

I am not the only one who cannot confirm it. On this thread, Qbix also couldn't. The explanation is simple as he was using Ubuntu 20.04 with the xorg-server-1.20.9 version.
With the version that contains the necessary fix to eliminate this bug.
https://gitlab.freedesktop.org/xorg/xserver/- … a5b2b5a69e.diff

I rebuilt Xorg-server-1.20.10 with this patch removed.

1patch -Rp1 -i 364d64981549544213e2bca8de6ff8a5b2b5a69e.diff

I ran dosbox-SVN-r4400 with Screamer in it. I chose the Palm Town route. After 1.5 seconds, the engine stopped speeding. This happens every time the up key is pressed.

Not everyone will notice it from Xorg-server version older than 1.20.9. You have to use dosbox in full screen mode and run a game that often uses long keystrokes.

I can confirm it nowadays. but the important bit is that you have to press (and release) a second key while keeping the first one pressed and be in fullscreen mode.
(this is on ubuntu 20.04.1)

That patch does NOT fix the issue with SDL because grabinfo->grab is NULL when the events that trigger the bug are sent.

Test code running under Xorg-server-1.20.10.
I keep the 'Up' key pressed, three times press and release the 'A' key, and finally release the 'Up' key.

1Pressed: up - 1675
2Pressed: a - 3580
3Released: a - 3698
4Pressed: a - 7899
5Released: a - 8056
6Pressed: a - 13873
7Released: a - 13993
8Released: up - 16933

Same goes for Xorg-server-1.20.10 with a commit undone.

1Pressed: up - 1460
2Pressed: a - 3901
3Released: a - 4018
4Released: up - 5520
5Released: up - 7022
6Released: up - 8524
7Pressed: a - 9151
8Released: a - 9280
9Released: up - 10782
10Released: up - 12284
11Pressed: a - 13500
12Released: a - 13631
13Released: up - 14011

Does not pass the test. I haven't released the 'Up' key in the meantime. I did it only at the very end.

A few days ago this bug was finally fixed in SDL.
https://hg.libsdl.org/SDL/rev/336bcaa9432c