Bug 104040 - CapsLock remapped to Compose key broken
Summary: CapsLock remapped to Compose key broken
Status: RESOLVED INVALID
Alias: None
Product: libxkbcommon
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Daniel Stone
QA Contact: Ran Benita
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-02 18:28 UTC by Jehan
Modified: 2017-12-03 11:28 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jehan 2017-12-02 18:28:54 UTC
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.
Comment 1 Jehan 2017-12-02 23:37:20 UTC
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!
Comment 2 Ran Benita 2017-12-03 11:28:02 UTC
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.