Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapping from scancode to keycode doesn't work for remapped modifier keys #1074

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.1
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2013-09-11 04:35:26 +0000, Jacob Lee wrote:

If a user has a non-standard keyboard mapping -- say, their caps lock key has been mapped to Ctrl -- then SDL_GetModState() is no longer accurate: it only considers the unmapped keys. This is a regression from SDL 1.2.

I think there are two parts to this bug: first, GetModState should use keycodes, rather than scancodes, which is easy enough.

Unfortunately, on my system, SDL considers Caps Lock, even when mapped as Control, to be both SDL_SCANCODE_CAPSLOCK and SDLK_CAPSLOCK. The output from checkkeys for it is:

INFO: Key pressed : scancode 57 = CapsLock, keycode 0x40000039 = CapsLock modifiers: CAPS

Whereas the output for xev is:

KeyPress event, serial 41, synthetic NO, window 0x4a00001,
root 0x9a, subw 0x0, time 40218333, (144,177), root:(1458,222),
state 0x10, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
XKeysymToKeycode returns keycode: 37
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

I think the problem is that X11_UpdateKeymap in SDL_x11keyboard.c only builds a mapping for keycodes associated with a Unicode character (anything where X11_KeyCodeToUcs returns a value). In the case of caps lock, SDL scancode 57 becomes x11 keycode 66, which becomes x11 keysym 65507(Control_L), which does not have a unicode value.

To fix this, I suspect that SDL needs a mapping of the rest of the x11 keysyms to their corresponding SDL key codes.

On 2014-08-23 18:50:39 +0000, Benoit Pierre wrote:

The 2 attached patches fix this issue for me:

  1. video/x11: improve keyboard mapping by handling keycodes not associated with a Unicode character in X11_UpdateKeymap

  2. events: improve keyboard modifiers handling by using remapped key codes, instead of scan codes, to track modifiers state

On 2014-08-23 18:51:18 +0000, Benoit Pierre wrote:

Created attachment 1839
video/x11: improve keyboard mapping

On 2014-08-23 18:51:51 +0000, Benoit Pierre wrote:

Created attachment 1840
events: improve keyboard modifiers handling

On 2014-08-24 07:16:15 +0000, Sam Lantinga wrote:

The intent is that if you remap the capslock key to control, you'll get scancode capslock and keycode control. I can't test it here, does that happen with your patch?

The second patch looks fine and makes sense to me.

On 2014-08-24 14:43:37 +0000, Benoit Pierre wrote:

Yes, I use a modified colemak layout: backspace and capslock switched, right alt and control switched, left alt activating a 3rd layer overlay with left/right/up/down/home/end near the right home row, and with this patch all keys are properly remapped. You can test the patch easily on Linux by switching the layout to colemak and checking capslock is now backspace: setxkbmap us -variant colemak

On 2014-09-09 05:47:30 +0000, wrote:

Confirming that the patch works on a layout where ctrl and caps are swapped (both keyboard event's keysym and SDL_GetModState() behave). Also the example code on https://wiki.libsdl.org/SDL_Scancode produces correct output:

scancode CapsLock acting as Left Ctrl
scancode Left Ctrl acting as CapsLock

On 2015-01-05 18:32:12 +0000, Benoit Pierre wrote:

So... Anything else I can do to get those 2 patches merged?

On 2015-02-19 04:24:12 +0000, Ryan C. Gordon wrote:

*** Bug 2819 has been marked as a duplicate of this bug. ***

On 2015-02-19 05:22:23 +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-05-28 19:48:47 +0000, Sam Lantinga wrote:

Your patches are in, thanks!
https://hg.libsdl.org/SDL/rev/9e8323b058d6

On 2015-05-28 20:06:14 +0000, Daniel Gibson wrote:

*** Bug 2978 has been marked as a duplicate of this bug. ***

On 2015-05-28 20:34:11 +0000, Benoit Pierre wrote:

Great, thanks!

On 2015-05-29 01:11:52 +0000, Zack Middleton (zturtleman) wrote:

This breaks SDL key codes that do not have a Ucs4 character and are not XOR'd with SDLK_SCANCODE_MASK such as backspace and return.

The change to the keymap to use SDL_SCANCODE_TO_KEYCODE in SDL_x11keyboard.c causes all SDL scancodes without a Usc4 character to be XOR'd with SDLK_SCANCODE_MASK, but not all key code are suppose to be (as seen in include/SDL_keycodes.h). SDLK_BACKSPACE is not 0x4000002A.

I think the full list of keys affected are return, escape, backspace, tab, and delete.

On 2015-05-29 01:15:24 +0000, Zack Middleton (zturtleman) wrote:

Created attachment 2166
x11keyboard: Specifically remap scan codes for return, escape, backspace, tab, and delete

Fix remapping scan codes to key codes for keymap in SDL_x11keyboard.c.

On 2015-05-29 02:06:49 +0000, Sam Lantinga wrote:

Looks good, thanks!
https://hg.libsdl.org/SDL/rev/0265666d0238

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant