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 599 - Numlock events broken on X11
Summary: Numlock events broken on X11
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 1.2
Hardware: Other Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords: target-1.2.14
Depends on:
Blocks:
 
Reported: 2008-06-19 05:04 UTC by Alistair John Strachan
Modified: 2009-09-28 00:42 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alistair John Strachan 2008-06-19 05:04:36 UTC 
On X11 platforms (and OS X) it would seem that numlock handling is broken.

SDL_GetModState() does not return the current state of the numlock after application init. That is to say, SDL_GetModState() will initially be correct for any given numlock state (at startup), but if the user changes the state it will not be updated.

On Windows, toggling numlock ON sends SDLK_KEYDOWN and toggling numlock off sends SDLK_KEYUP. However, on X11 platforms, SDLK_KEYDOWN and SDLK_KEYUP are both sent for each toggling of numlock. That is, either enabling or disabling numlock will generate both events each time.

Understandably this makes supporting number pads more difficult in SDL applications. My current workaround has been to ignore the SDLK_KEYUP event on X11 and respect it on Windows, house-keeping the numlock status based on the application startup's mod state. This is obviously not ideal, as numlock can change state when the SDL application does not have focus.
Comment 1 Ryan C. Gordon 2009-09-13 16:33:41 UTC 
Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.

Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).

--ryan.
Comment 2 Ryan C. Gordon 2009-09-27 22:30:06 UTC 
Taking bug.

--ryan.
Comment 3 Sam Lantinga 2009-09-27 23:48:48 UTC 
Is this still a problem with the recent snapshot?
http://www.libsdl.org/tmp/SDL-1.2.zip

I just tried this with the checkkeys test program on Linux and Mac OS X, and I got the expected results.  Pressing and releasing the key gave a "Key pressed" message and doing it again gave a "Key released" message.  This worked correctly with both NumLock and CapsLock.
Comment 4 Alistair John Strachan 2009-09-27 23:59:30 UTC 
(In reply to comment #3)
> Is this still a problem with the recent snapshot?
> http://www.libsdl.org/tmp/SDL-1.2.zip

Looks fixed now. If I run the checkkeys from the SDL in that package with my _system_ SDL (Debian 1.2.13-4+b1) I see the buggy behaviour. If I LD_LIBRARY_PATH to the SDL from the snapshot, the problem goes away.

OLD:
Key pressed:  300-numlock  modifiers: (none)         
Key released:  300-numlock  modifiers: (none)        
Key pressed:  300-numlock  modifiers: (none)         
Key released:  300-numlock  modifiers: (none)

NEW:
Key pressed:  300-numlock  modifiers: NUM
Key released:  300-numlock  modifiers: (none)
Comment 5 Sam Lantinga 2009-09-28 00:42:43 UTC 
Great, thanks for the update!