We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1998 - SDL Keyboard events missing when certain key combinations are present
Summary: SDL Keyboard events missing when certain key combinations are present
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: 2.0.0
Hardware: x86 Windows 7
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-29 00:53 UTC by Leeor Dicker
Modified: 2013-08-01 00:23 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leeor Dicker 2013-07-29 00:53:31 UTC
Since moving to SDL2 I've noticed that certain key combinations never fire events in SDL. This seems to be different for different hardware/drivers.

I have three Windows 7 computers. On my primary dev machine (with an HP PS/2 multi-media keyboard), when LEFT/UP are pressed, pressing the SPACEBAR does nothing (no down/up events).

On another machine with Windows 7 and a Logitech USB gaming keyboard, no issues are present.

On another machine with a Kensington USB keyboard (also Windows 7), LEFT/UP, LEFT/DOWN or RIGHT/DOWN held down, SPACEBAR does nothing.

All keyboards are QWERTY layout.

At first I thought it was my code until I realized that SDL2 is not actually pushing any keydown/keyup events at all with these key combinations.
Comment 1 Sam Lantinga 2013-07-31 03:52:55 UTC
I'm pretty sure that it's the hardware issue described here:
http://www.sjbaker.org/wiki/index.php?title=Keyboards_Are_Evil

If these key combinations work with other programs with the same hardware, please reopen this bug!
Comment 2 Leeor Dicker 2013-07-31 14:11:51 UTC
That was my first thought (and I agree that keyboards produced that way are evil)... until I got the annoying "key is being leaned on" beep that Windows is so fond of producing.

So there are in fact key events that are being generated, but for whatever reason SDL is not catching them.

I checked a couple of other programs that are not SDL based or even games and the same key combinations are producing events (e.g., arrow keys held with a spacebar tap shows a spacebar) with no beeping.

To be clear, I've implemented a DooM style of control system (arrow keys move a character around, space bar fires a weapon) which is when I came across this issue. I don't remember if it was a problem with SDL 1.2 but I'm pretty sure I've had other apps I've run with SDL 1.2 without running into this problem using the same methods I'm using here (SDL_PollEvent calls) vs. getting keydown states. I have another mapping that does work (WASD/SPACE) without issue but it feels weird... plus I'd like to allow for key customization.

I tend to prefer event-driven approaches vs. getting hardware states but I have a sneaking suspicion that even if I queried key-states I would see that the spacebar is not being pressed with the above stated key combinations regardless.

I'm somewhat unfamiliar with SDL's code which is why I haven't attempted to look into it myself. I'll let you decide if this is something worth looking into further.
Comment 3 Leeor Dicker 2013-07-31 14:18:37 UTC
Confirmed that querying key states shows no detection of space pressed during certain key combinations.
Comment 4 Leeor Dicker 2013-07-31 14:33:54 UTC
Okay, I think I can make a final note on this.

I dug deeper into this using SPY++ to inspect events that are sent to an application.

Turns out the application built with SDL doesn't get key events from the space bar when certain other keys are pressed. This ALSO happens across other programs as well.

I guess that leaves this is a hardware/software issue.

Maybe now we need to tell the keyboard manufacturers to fix their flawed designs? ;)
Comment 5 Sam Lantinga 2013-08-01 00:23:51 UTC
Great, thanks for investigating! :)