VOGONS

Common searches


Dosbox dropping pressed keys?

Topic actions

Reply 20 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

Huh, no I'm still getting this with the latest revision. It's interesting that you are also using Arch and ran into the same problem though. Were you using gcc 8 or 9 when you built dosbox? gcc 9 was in [testing] for a couple of days, but was dropped because it caused a major regression. Also, what is your cpu, and did you notice the bug only in fullscreen mode or did you get it in windowed mode as well?

Reply 21 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

Okay! After being reminded that this only happened in fullscreen, I was able to reproduce in a test 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());
SDL_ShowCursor(SDL_DISABLE);
break;
case SDL_KEYUP:
printf("Released: %s - %d\n", SDL_GetKeyName(event.key.keysym.sym), SDL_GetTicks());
SDL_ShowCursor(SDL_ENABLE);
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_FULLSCREEN | SDL_HWSURFACE | SDL_HWPALETTE);
if (!screen)
return 1;
SDL_Flip(screen);
SDL_GrabMode SDL_WM_GrabInput(SDL_GrabMode mode);
while (1) {
if (!poll_events())
break;
SDL_Delay(1);
}
return 0;
}

Here I more closely mimic dosbox's call to SDL_SetVideoMode. I was not able to reproduce this exact issue with the "up" key specifically (after a good while I did see a keyup event followed immediately by a keydown event, but I think that would not be easily noticed in a game typically), but I am able to very quickly reproduce with ctrl. I only see the behavior when SDL_FULLSCREEN is set.

Reply 22 of 46, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Interesting that you managed to reproduce it. That is somewhat good news.

Could you again add some time stamping to it to see if there is maybe some "weirdness" going on with that ? As it might be more obvious with a minimal testcase.

Is the SDL_GrabMode maybe related to the problem ? (of course dosbox needs that else the mouse won't work), as we had a problem with the cursor locking before. (the SDL_XORG_FIX in SVN)

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

Reply 23 of 46, by aaronp

User metadata
Rank Newbie
Rank
Newbie

Output looks like this:

Pressed: left ctrl - 450
Released: left ctrl - 1951
Released: left ctrl - 3452
Released: left ctrl - 4954
Released: left ctrl - 6456
Released: left ctrl - 7957
Released: left ctrl - 9458
Released: left ctrl - 10960
Released: left ctrl - 12154

where the number is in ms. That's about a second and a half between keyup events, so that might not be the same thing at all... Happens with both SDL_GRAB_ON and SDL_GRAB_OFF, and also with SDL_GRAB_ON with the SDL_XORG_FIX block included.

In the "up" case, it's looking more like this

Pressed: up - 436
Released: up - 41112
Pressed: up - 41119

with a release immediately followed by a press.

Reply 24 of 46, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

7 ms is still a considerable amount of time (for the "up" case).
I think that the 1500 ms is too regular to be a coincidence for ctrl.

It's somewhat puzzling that there is no press of the left-ctrl like there is for the up.
The time interval of 40 seconds is pretty long as well (for the up). That is not very logical either.

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

Reply 25 of 46, by dreamer_

User metadata
Rank Member
Rank
Member

I see this problem in several games in 0.74-2 and can still reproduce it in 0.74-3 (revision 4241).

It can be reproduced in practically any game, but sometimes it's quite hard to do so (due to e.g. level design). It's easiest to reproduce in Megarace 2, as it's a racing game and depends on pressing forward for long periods of time.

* Megarace 2: reproducible 0.74-2 (easily) and 0.74-3 (seems harder, but regularly)
* Doom: reproducible 0.74-3 (very hard to reproduce, due to level design)
* Dark Forces: I never noticed it in 0.74-2, but can reproduce it in 0.74-3 (but a bit randomly - sometimes it happens frequently, sometimes not for long stretches of the game). To reproduce keep moving forward without touching the mouse.
* Tomb Raider (with software rendering): happens almost immediately in 0.74-2 game is broken in 0.74-3 due to imgmount being broken ("imgmount D "GAME.DAT" -t iso -fs iso" results in "Must specify drive letter to mount image at.")

BTW, revision 4241 does not build out of the box because of following compilation error:

drive_iso.cpp:142:11: error: class `isoDrive` does not have any field named `iso`

I worked around it simply by adding missing field to this class, but it's likely the root cause for Tomb Raider failing.

For what it's worth, this issue is completely fixed in dosbox-x fork (maybe by using SDL2, but it's speculation on my part).

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

Reply 26 of 46, by junglemontana

User metadata
Rank Newbie
Rank
Newbie

I've also noticed this with GTA1, both low-color (GTA8) and high-color (GTA24) versions, see:
GTA1 - up arrow "stops" after a while

It only happens in full screen mode, and it only seems to happen after using another key while walking.

Reply 27 of 46, by dreamer_

User metadata
Rank Member
Rank
Member

Good find! I tested all the games in fullscreen mode so far. With TR1 in windowed mode, the problem is not there any more. I guess it's really time to switch to SDL2 and its improved fullscreen handling?

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

Reply 28 of 46, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Well it would be nice if it's determined to be a DOSBox issue, SDL 1.2 issue, X.org or some combination of all there. A couple posts above may indicate it not being a DOSBox issue but SDL1.2 and/or X.org but most likely SDL1.2 There really hasn't been that much testing done. If found to be a SDL 1.2 issue and no fix can be created (doubtful) then possibly changing DOSBox to maximize the window without switching to fullscreen may be a possible "fix" until DOSBox moves to SDL2. If this only occurs in Linux but not Windows then even more likely a X.Org/SDL issue.

For now a user can modify their dosbox.conf and change windowresolution to a higher value as well as enabling aspect.

For Windows :
When I worked on getting DOSBox working on NT 3.50 I did so in a hackish way by using the NO_CHANGEDISPLAYSETTINGS 1 define in SDL_config.h.
DOSBox Compilation Guides
C:\MinGW\codeprojects\dosbox\32\vanilla\SDL-1.2.15351\include\SDL_config.h
Add
#define NO_CHANGEDISPLAYSETTINGS 1

I'm sure there is a more elegant solution like https://github.com/joncampbell123/dosbox-x/co … 5123d2a4a0ede87

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

Reply 29 of 46, by dreamer_

User metadata
Rank Member
Rank
Member

Please note that creators of SDL urge every project to abandon SDL1.2 (which does not receive updates at all at this point) and move to SDL2 - I think it's very likely to be a problem on the interaction between SDL1.2 and desktop environment. I will pick one of patch series implementing SDL2 to check if that's the case.

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

Reply 30 of 46, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Finalley setup my Latitude D520 with 18.04 to test with and going to install a newer distro on my C2Q

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

Reply 31 of 46, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Haven't noticed the issue with the below:

DOSBox version: 0.74-4.3
DOSBox SDL version: 1.2
DOSBox: Default settings, fullscreen
Game: GTA 1
GTA Gameplay: Held down up arrow while walking or driving while using other arrows.
OS: Ubuntu 18.04.3 LTS
X.org version: 1.19.6
Laptop: Dell Latitude D520
CPU: Intel Core Duo T2400
RAM: 4GB

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

Reply 32 of 46, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

X.org version: 1.19.6

I think it was confirmed on post-1.19.x versions of xorg; so this is good you've confirmed 1.19.x and below is unaffected.

I was also on 18.04 and couldn't reproduce it, but have since moved to Ubuntu 19.04 and, although I've only recently tried a couple games, I now recall this button release issue might have affected my gameplay (I remember having to relese and press again to maintain a turn.. at the time I remember thinking the game is probably a bit flakey).

I will try later with the small test code above and see if it happens on 19.04.

Reply 33 of 46, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

What annoys me about X.org is I don't know of any way to test out specific versions of it to track down where the issue starts without installing a distro. I'll work on setting up the latest Ubuntu version or mabye possibly step through Ubuntu versions on my C2Q next.

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

Reply 34 of 46, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Lol, yeah... back when I ran gentoo this type of thing was a bit easier because you could flip versions of packages and their dependencies one by one, and you had a hope of isolating issues to a specific dependency.

Definitely harder on these binary distros built with the kitchen sink of dependencies, and no easy way to switch versions!

Reply 35 of 46, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Spent the morning attempting to install Linux on my C2Q

On this motherboard it looks like Ubuntu may not be compatible with my iodd so had to burn a cd, rufus doesn't appear to work either.
lubuntu 18.10 x86 doesn't work on x86-64 hardware or at least not mine. A couple of posts I found no one seemed to care and stated to just use the x64 ver. Pitiful.
My 8800GT and 780GTX will not boot x.org. Tried with my Geforce 4 MX X.org loads but desktop corrupted

Finally stuck in an old ATI PCI express card and X.org loads with Ubuntu 18.10 x64 and is installing now.

I bet all of the above works fine in 2000 and above.....

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

Reply 36 of 46, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Reproduced using Aaronp's test code on Ubuntu 19.04 x86_64 with distro-provided binaries of SDL (1.2.15+dfsg2-4) and X-Org (1.20.4-1ubuntu3).

Hardware: i6700k using a USB mechanical-switch DAS keyboard (K3 Pro).

Pressed and held left-ctrl for 15 seconds then released, followed by holding up-arrow for about 40 seconds then released. No other keys nor the mouse were touched during this time.

Pressed: left ctrl - 1344
Released: left ctrl - 2846
Released: left ctrl - 4348
Released: left ctrl - 5850
Released: left ctrl - 7353
Released: left ctrl - 8855
Released: left ctrl - 10357
Released: left ctrl - 11859
Released: left ctrl - 13362
Released: left ctrl - 14864
Released: left ctrl - 15833
Pressed: up - 17009
Released: up - 63216

Why is ctrl so flakey versus the up-arrow key? (maybe a distinction for modifier keys in whatever code is causing this bug?)
The DAS keyboard I'm using has full n-key rollover allowing up to 6 keys to be held simultaneously, where as some laptops and other USB keyboards have lower limits; https://en.wikipedia.org/wiki/Rollover_(key)
But that doesn't seem to influence this bug.

g++ sdl_keypress_test.cpp -lSDL -o sdl_keypress_test
ldd sdl_keypress_test | grep SDL
libSDL-1.2.so.0 => /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 (0x00007fe42c484000)

dpkg -S /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
libsdl1.2debian:amd64: /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
dpkg -s libsdl1.2debian | grep ^Version
Version: 1.2.15+dfsg2-4

dpkg -s xserver-xorg-core | grep ^Version
Version: 2:1.20.4-1ubuntu3
Last edited by krcroft on 2019-08-29, 21:10. Edited 1 time in total.

Reply 37 of 46, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Haven't noticed the issue with the below:

DOSBox version: 0.74-4.3
DOSBox SDL version: 1.2
DOSBox: Default settings, fullscreen
Game: GTA 1
GTA Gameplay: Held down up arrow while walking or driving while using other arrows.
OS: Ubuntu 18.04.3 LTS
X.org version: 1.19.6
Laptop: Dell Latitude D520
CPU: Intel Core Duo T2400
RAM: 4GB

DOSBox version: 0.74-3
DOSBox SDL Version: 1.2
DOSBox: Default settings, fullscreen
Game: GTA 1
GTA Gameplay: Held down up arrow while walking or driving while using other arrows.
OS: Windows 10 v1903
CPU: Intel Core i7 5700HQ
RAM: 32GB

Issues occurs with the below:

DOSBox version: 0.74-2.1
DOSBox SDL version: ??? ldd shows SDL1.2 and SDL2?
DOSBox: Default settings, fullscreen
Game: GTA 1
GTA Gameplay: Held down up arrow while walking or driving while using other arrows.
OS: Ubuntu 18.10 x64
X.org version: 1.20.1-3
CPU: Intel Core 2 Quad Q6600
RAM: 8GB

X - version for xorg verison info

X.org 1.19.6 Released Dec 20, 2017
X.org 1.19.7 Released March 2, 2019
X.org 1.20 Released May 10, 2018
X.org 1.20.1 Released August 7, 2018

24 APR 2018 xserver 1.20 RC5
10 APR 2018 Xserver 1.20 RC4
02 APR 2018 Xserver 1.20 RC3 *
28 MAR 2018 Xserver 1.20 RC2

Ubuntu 18.04 Released April 26th, 2018
Ubuntu 18.10 Released October 18, 2018

https://gitlab.freedesktop.org/xorg/xserver/commits/master
https://gitlab.freedesktop.org/xorg/xserver/c … accb7c79bc00f6a (from the previous DOSBox issue with X.org)
https://gitlab.freedesktop.org/xorg/xserver/c … e6ff8a5b2b5a69e (later updated)

Need to check
xwininfo
xev -id windowid

Need to see if an 18.04 x64 build can upgrade to specific newer versions of xorg

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

Reply 38 of 46, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

DosFreak - nice coverage across xorg versions.
Does building Aaronp's test code reveal anything? (Re: Dosbox dropping pressed keys?)
especially with your left-ctrl held -- he and I both saw repeated "key-release" reported, despite it being held. Non-modifer keys seem to be less affected.

I've attached an SDL2 implementation. It can be built with:

g++ sdl2_keypress_test.cpp -lSDL2 -o sdl2_keypress_test

It opens a full-screen window for you to test in. Press escape when you want to quit.
It correctly tracks key press and release events (both modifier keys and normal repeat keys). Repeats are reported as dots:

timestamp=1.4   key=Left Ctrl   pressed
timestamp=4.4 key=Left Ctrl released
timestamp=7.9 key=Left Shift pressed
timestamp=11.2 key=Left Shift released
timestamp=11.7 key=Left Alt pressed
timestamp=14.9 key=Left Alt released
timestamp=16.0 key=Right Alt pressed
timestamp=18.7 key=Right Alt released
timestamp=19.3 key=Right Shift pressed
timestamp=22.5 key=Right Shift released
timestamp=23.2 key=Right Ctrl pressed
timestamp=26.2 key=Right Ctrl released
timestamp=26.9 key=Backspace pressed.................................................................
timestamp=32.8 key=Backspace released
timestamp=33.2 key=Up pressed............................................
timestamp=38.5 key=Up released
timestamp=39.0 key=PageUp pressed............................................................
timestamp=45.5 key=PageUp released

Here I steadily press more and more modifier keys until 6 are held simultaneously, and then release them all at the same time:

timestamp=1.1   key=Left Ctrl   pressed
timestamp=2.4 key=Left Shift pressed
timestamp=3.8 key=Left Alt pressed
timestamp=5.1 key=Right Alt pressed
timestamp=7.4 key=Right Shift pressed
timestamp=10.0 key=Right Ctrl pressed
timestamp=17.0 key=Left Ctrl released
timestamp=17.0 key=Left Shift released
timestamp=17.0 key=Left Alt released
timestamp=17.0 key=Right Ctrl released
timestamp=17.0 key=Right Shift released
timestamp=17.0 key=Right Alt released

Attachments

  • Filename
    sdl2_keypress_test.cpp
    File size
    1.4 KiB
    Downloads
    20 downloads
    File comment
    SDL2 implementation to test dropped key presses
    File license
    Fair use/fair dealing exception

Reply 39 of 46, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I'll try the test code next week. I'd also like to go through each SDL2 version from earliest to latest to see if the issue occurs in earlier SDL2 versions if so then it should be easier to identify what needs to be fixed in SDL 1.2. This would benefit other SDL 1.2 programs and also when DOSBox switches to SDL2 then it would be nice to load up 0.74 to test for regressions or if any issues occur with SDL2. This is all assuming nothing is changed in DOSBox to work around the issue.

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