VOGONS


Dosbox dropping pressed keys?

Topic actions

Reply 40 of 57, by ZakMcKracken

User metadata
Rank Newbie
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 57, by dreamer_

User metadata
Rank Member
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
dosbox-staging

Reply 42 of 57, by DosFreak

User metadata
Rank l33t++
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.

How To Ask Questions The Smart Way
Make your games work offline

Reply 43 of 57, by dreamer_

User metadata
Rank Member
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
dosbox-staging

Reply 44 of 57, by Vladimir

User metadata
Rank Newbie
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

Reply 45 of 57, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

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 😀

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 46 of 57, by dreamer_

User metadata
Rank Member
Rank
Member

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

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 47 of 57, by Malik

User metadata
Rank l33t
Rank
l33t

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.

5476332566_7480a12517_t.jpgSB Dos Drivers

Reply 48 of 57, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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?

Reply 49 of 57, by latalante

User metadata
Rank Newbie
Rank
Newbie
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

Reply 50 of 57, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 51 of 57, by latalante

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 52 of 57, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 53 of 57, by latalante

User metadata
Rank Newbie
Rank
Newbie

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.

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

Reply 54 of 57, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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)

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

Reply 55 of 57, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 56 of 57, by latalante

User metadata
Rank Newbie
Rank
Newbie

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.

Pressed: up - 1675
Pressed: a - 3580
Released: a - 3698
Pressed: a - 7899
Released: a - 8056
Pressed: a - 13873
Released: a - 13993
Released: up - 16933

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

Pressed: up - 1460
Pressed: a - 3901
Released: a - 4018
Released: up - 5520
Released: up - 7022
Released: up - 8524
Pressed: a - 9151
Released: a - 9280
Released: up - 10782
Released: up - 12284
Pressed: a - 13500
Released: a - 13631
Released: 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.