| Summary: | CapsLock remapped to Compose key broken | ||
|---|---|---|---|
| Product: | libxkbcommon | Reporter: | Jehan <jehan> |
| Component: | General | Assignee: | Daniel Stone <daniel> |
| Status: | RESOLVED INVALID | QA Contact: | Ran Benita <ran234> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Ok that's weird. I realized that setting a different order in the several layouts configured on my OS change the behavior. - When I set "Korean (Hangul)" first (which was the case currently), I have the behavior described: CapsLock works as CapsLock despite remapping to Compose. - If I set "Japanese" first (not "Japanese (Kana Kanji)", but simple "Japanese" which is the qwerty layout corresponding to Japan-sold keyboard), then "Korean (Hangul)", the CapsLock still does not work as Compose but at least it does not work as a CapsLock either (so the key is rendered useless, which in my case is still better since I really don't like this key). - If "Korean (Hangul)" is first and "Japanese" is second, not only CapsLock still works as CapsLock whether "Korean (Hangul)" or "Japanese" is active. - If "Japanese" is first and "Korean (Hangul)" is second, the CapsLock is rendered useless in "Korean (Hangul)", as explained above, but suddenly it works in "Japanese"! This is completely messy! The order of the layout determines the behavior of xkbd-options! Hi, The order does indeed matter. The jp layout explicitly overrides the CapsLock key[1] which causes the behavior you observe. [1] https://cgit.freedesktop.org/xkeyboard-config/tree/symbols/jp?h=xkeyboard-config-2.22#n47 xkbcommon is working as intended; please report or reassign this to the xkeyboard-config (the project which defines the keyboard layouts) if you feel something should be changed. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
My system is Fedora 27/GNOME 3.26. I remap the CapsLock into the compose key using the tweak tool, which apparently set /org/gnome/desktop/input-sources/xkb-options dconf settings as: ['compose:caps']. This used to work, but stopped working from Fedora 26/GNOME 3.24 where the CapsLock now behaves as a CapsLock only, by locking uppercase (and the key lights on/off), both with X11 and Wayland. Also this is broken in all my computers with these versions of Fedora/GNOME, even when newly installed. I was told the problem seems to come from libxkbcommon. xev output without remapping: KeyPress event, serial 35, synthetic NO, window 0x3200001, root 0x109, subw 0x0, time 5439582, (663,460), root:(663,524), state 0x10, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 38, synthetic NO, window 0x3200001, root 0x109, subw 0x0, time 5439654, (663,460), root:(663,524), state 0x12, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False When the CapsLock is mapped to Compose: KeyPress event, serial 35, synthetic NO, window 0x3200001, root 0x109, subw 0x0, time 5512263, (745,384), root:(745,448), state 0x10, keycode 66 (keysym 0xff20, Multi_key), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 38, synthetic NO, window 0x3200001, root 0x109, subw 0x0, time 5512366, (745,384), root:(745,448), state 0x12, keycode 66 (keysym 0xff20, Multi_key), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False As you can see, as far as xev sees it, it seems to work fine! And yet, it doesn't. Everywhere I type, CapsLock key still behaves as a CapsLock! Now `xinput test-xi2 --root` with the mapping being done, 2 CapsLock clicks (one locks, the other unlocks): EVENT type 2 (KeyPress) device: 10 (10) detail: 66 flags: root: 201.00/239.00 event: 201.00/239.00 buttons: modifiers: locked 0x10 latched 0 base 0 effective: 0x10 group: locked 0 latched 0 base 0 effective: 0 valuators: windows: root 0x109 event 0x109 child 0x260001d EVENT type 14 (RawKeyRelease) device: 3 (10) detail: 66 valuators: EVENT type 3 (KeyRelease) device: 10 (10) detail: 66 flags: root: 201.00/239.00 event: 201.00/239.00 buttons: modifiers: locked 0x12 latched 0 base 0x2 effective: 0x12 group: locked 0 latched 0 base 0 effective: 0 valuators: windows: root 0x109 event 0x109 child 0x260001d EVENT type 13 (RawKeyPress) device: 3 (10) detail: 66 valuators: EVENT type 2 (KeyPress) device: 10 (10) detail: 66 flags: root: 201.00/239.00 event: 201.00/239.00 buttons: modifiers: locked 0x12 latched 0 base 0 effective: 0x12 group: locked 0 latched 0 base 0 effective: 0 valuators: windows: root 0x109 event 0x109 child 0x260001d EVENT type 14 (RawKeyRelease) device: 3 (10) detail: 66 valuators: EVENT type 3 (KeyRelease) device: 10 (10) detail: 66 flags: root: 201.00/239.00 event: 201.00/239.00 buttons: modifiers: locked 0x12 latched 0 base 0x2 effective: 0x12 group: locked 0 latched 0 base 0 effective: 0 valuators: windows: root 0x109 event 0x109 child 0x260001d EVENT type 13 (RawKeyPress) device: 3 (10) detail: 37 valuators: As you can see here, even while xev still see the mapping, it doesn't look like xinput sees it since at the KeyRelease of the first click, the lock is effective; after KeyRelease of the second click, the lock disappears (not visible here, but I could paste more events and it would show as "locked 0x10". This means that it still functions as a CapsLocks; yet it is not supposed to since it has been remapped otherwise.