This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Set numlock/capslock state on window focus on X11 (fix_x11_numlock_default.diff, text/plain, 2014-09-21 08:03:36 +0000, 3028 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2014-09-21 08:03:36 +0000, Zack Middleton (zturtleman) wrote:

Created attachment 1873
Set numlock/capslock state on window focus on X11

Using X11 (on Debian Wheezy), SDL_GetModState() & KMOD_NUM and KMOD_CAPS are not set to system state (numlock/capslock LEDs). Pressing numlock or capslock toggles the mod state, though if num/caps lock is enabled before starting the program it's still reversed from system state. This makes getting KMOD_NUM and KMOD_CAPS in programs unreliable. This can be seen using the checkkeys test program.

The function that appears to have handle this in SDL 1.2 is X11_SetKeyboardState. The function call is commented out with "FIXME:" in SDL 2.

Using Windows backend through WINE; on first key press if numlock and/or capslock is enabled on system, numlock/capslock SDL_SendKeyboardKey is run and toggles KMOD_NUM/KMOD_CAPS to the correct state. On X11 this does not happen.

The attached patch makes X11 backend set keyboard state on window focus if no window was previously focused. It sets all keys to system up/down state and toggles KMOD_NUM/KMOD_CAPS via SDL_SendKeyboardKey to match system if needed. The patch is based on SDL 1.2's X11_SetKeyboardState.

On 2015-02-11 22:39:58 +0000, wrote:

SDL_GetModState doesn't seem to catch numlock being already ON on actual Windows.

On 2015-02-13 03:11:38 +0000, Sam Lantinga wrote:

Hey Ryan, I believe you are looking at this for 2.0.4?

On 2015-02-19 05:22:20 +0000, Ryan C. Gordon wrote:

Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!

On 2015-04-07 04:57:57 +0000, Ryan C. Gordon wrote:

(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)

--ryan.

On 2015-05-28 16:34:45 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL/rev/7099e2df7b29

On 2015-06-20 19:27:11 +0000, Philipp Wiesemann wrote:

There may be a small compatibility problem with this fix because of the SDL_KEYDOWN/SDL_KEYUP events with SDL_SCANCODE_NUMLOCKCLEAR which are received now if numlock was activated before starting the program.

If a program uses SDL_PollEvent() to check for "any key" directly after start, it now gets an interaction although there was none. For example testspriteminimal.c now instantly closes with numlock activated.

On 2015-06-22 00:19:04 +0000, Sam Lantinga wrote:

I think the right thing to do is add a new internal API to set initial key state. Ryan, can you look at this for 2.0.4?

Thanks!

On 2015-07-17 12:50:44 +0000, terencehill wrote:

Since the patch only applied to X11, this issue shouldn't be fixed in Windows (I experienced it in Windows 8 and XP SP2), despite what the author of the patch said: "Using Windows backend through WINE; on first key press if numlock and/or capslock is enabled on system, numlock/capslock SDL_SendKeyboardKey is run and toggles KMOD_NUM/KMOD_CAPS to the correct state. On X11 this does not happen."

Both SDL 2.0.3 and SDL 1.2.14 have the very same issue.

Just for reference, I proposed to work around this bug in DarkPlaces with this patch: https://gitlab.com/xonotic/darkplaces/merge_requests/13/diffs

On 2015-12-28 00:12:59 +0000, Ryan C. Gordon wrote:

(In reply to Philipp Wiesemann from comment # 6)

If a program uses SDL_PollEvent() to check for "any key" directly after
start, it now gets an interaction although there was none. For example
testspriteminimal.c now instantly closes with numlock activated.

Hmm, I'll fix that.

(In reply to Sam Lantinga from comment # 7)

I think the right thing to do is add a new internal API to set initial key
state. Ryan, can you look at this for 2.0.4?

Yes, but nothing too complex. Mostly we just need a way to run through SDL_SendKeyboardKey() without sending the key events on to the queue. I don't think it's worth checking the entire keyboard to see if a random key is held down by the user, so we really only need these three magic "toggle" keys dealt with.

(In reply to terencehill from comment # 8)

Since the patch only applied to X11, this issue shouldn't be fixed in
Windows (I experienced it in Windows 8 and XP SP2)

This patch doesn't fix this on Windows, but I just fixed this on Windows today; see Bug # 3125 for ongoing status.

I'm going to close this bug as fixed for the X11-specific problem and move further work over to Bug # 3125, which is dealing with other platforms too...just so we aren't tracking this issue in two places.

Thanks everyone!

--ryan.

On 2015-12-28 18:36:28 +0000, Ryan C. Gordon wrote:

(this should all be more properly resolved now, as of the latest in revision control.)

--ryan.