Bug 408227

Summary:	Setting Caps Lock as Compose doesn't disable Caps Lock functionality
Product:	[Plasma] kwin	Reporter:	David Gow <david>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED UPSTREAM
Severity:	normal
Priority:	NOR
Version First Reported In:	git master
Target Milestone:	---
Platform:	Other
OS:	Linux
URL:	https://github.com/xkbcommon/libxkbcommon/issues/97
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	kxkbrc which reproduces the problem

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.