Bug 408227 - Setting Caps Lock as Compose doesn't disable Caps Lock functionality
Summary: Setting Caps Lock as Compose doesn't disable Caps Lock functionality
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: general (other bugs)
Version First Reported In: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://github.com/xkbcommon/libxkbco...
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-02 23:14 UTC by David Gow
Modified: 2019-06-25 17:35 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
kxkbrc which reproduces the problem (214 bytes, text/plain)
2019-06-04 01:15 UTC, David Gow
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Gow 2019-06-02 23:14:11 UTC
SUMMARY
When running KDE as a Wayland session, setting "Position of Compose key" to "Caps Lock" in kcm_keyboard causes the Caps Lock key to work as _both_ Compose and Caps Lock — pressing it toggles the Caps Lock LED and inverts the case of characters, but also activates the "dead key" nature of Compose.

Additionally, disabling Caps Lock specifically with "Caps Lock behaviour"→"Caps Lock is disabled" doesn't seem to work. Setting "Caps Lock is also a Ctrl" seems to successfully make Caps Lock a Ctrl (in addition to Compose), but this is still suboptimal.

These all work as expected under X11.

STEPS TO REPRODUCE
1. Run a Plasma Wayland session.
2. Set "Position of Compose Key" to "Caps Lock" in kcm_keyboard's "Advanced" tab.
3. Press Caps Lock: the LED will toggle, and Caps Lock mode will activate.

OBSERVED RESULT
Caps Lock is enabled in addition to the Compose key functioning.
Caps Lock cannot be disabled with the "Caps Lock behaviour"→"Caps Lock is disabled" setting.

EXPECTED RESULT
Setting "Position of Compose Key" to "Caps Lock" disables Caps Lock.
Caps Lock can be disabled with the "Caps Lock is disabled" setting.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kubuntu 19.04 (kernel 5.0.0-15-lowlatency, libxkbcommon0: 0.8.2-1, xkb-data 2.23.1-1ubuntu1.18.10.1)
(available in About System)
KDE Plasma Version: 5.16.80 (kwin git c6265039...), also happens with stock Kubuntu
KDE Frameworks Version: 5.56.0
Qt Version: 5.12.2

ADDITIONAL INFORMATION
Comment 1 Vlad Zahorodnii 2019-06-03 07:49:41 UTC
Can you post your kxkbrc?
Comment 2 Vlad Zahorodnii 2019-06-03 10:57:50 UTC
I have no luck reproducing this bug.
Comment 3 David Gow 2019-06-04 01:15:05 UTC
Created attachment 120539 [details]
kxkbrc which reproduces the problem

This is a kxkbrc which reproduces the problem. Having multiple keyboard layouts seems to be a prerequisite — I'm unable to reproduce the issue from a clean kxkbrc by just following the instructions in the original report.
Comment 4 David Gow 2019-06-04 01:21:55 UTC
Thanks for pointing me to kxkbrc — I'm unable to reproduce the issue after deleting it, unless I add multiple keyboard layouts. If there are multiple layouts configured, I can reproduce the issue — deleting them fixes it.

For example, creating a US English ("us") and Japanese ("jp") keyboard layout, allows me to reproduce the issue from within the us layout. Disabling the "Configure Layouts" checkbox doesn't fix the issue by itself, the layouts seem to have to be deleted.
Comment 5 Vlad Zahorodnii 2019-06-04 07:51:19 UTC
The compose key works even though I have several layouts. I guess it's somehow related to CJK.
Comment 6 Vlad Zahorodnii 2019-06-04 08:44:49 UTC
I can reproduce it on X11.
Comment 7 Vlad Zahorodnii 2019-06-04 08:47:48 UTC
Can you please file an upstream bug report? (against libxkbcommon I guess)
Comment 8 David Gow 2019-06-06 02:21:13 UTC
I've filed this against libxkbcommon (and been able to reproduce it with their interactive-evdev test):
https://github.com/xkbcommon/libxkbcommon/issues/97
Comment 9 Christoph Feck 2019-06-25 17:35:45 UTC
Bug seems to be confirmed upstream. If not, please add a comment or reopen.