|Summary:||XKB options set in the Keyboard KCM sometimes don't work on Wayland|
|Product:||[Applications] systemsettings||Reporter:||Johnny Nalley <liljohnnyrayy>|
|Component:||kcm_keyboard||Assignee:||Fabian Vogt <fabian>|
|Severity:||normal||CC:||alex765, butirsky, fabian, herzenschein, ipha00, kde, nate, ndrzj1gbo, peter|
|Latest Commit:||https://invent.kde.org/plasma/plasma-desktop/commit/e6cc0b1fca1176ffbcc6e024a3fb72729049f3c9||Version Fixed In:||5.23.5|
Description Johnny Nalley 2021-02-19 18:39:16 UTC
SUMMARY STEPS TO REPRODUCE 1. Log into Plasma (Wayland) 2. Open Setting application 3. Go to Input Devices -> Keyboard -> Caps Lock behavior 4. Enable "Swap Esc and Caps Lock" 5. Save settings 6. Pressing caps lock should still enable caps lock, even though it was swapped with esc. OBSERVED RESULT Caps lock and Esc didn't swap, they both perform the functions they were made to do even though they were supposed to be swapped. EXPECTED RESULT Caps lock and Esc should have swapped, with Esc activating caps lock, and Caps lock activating Esc. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Liuux, rolling release (available in About System) KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION System is up-to-date.
Comment 1 Thiago Sueto 2021-02-20 19:25:25 UTC
*** Bug 433266 has been marked as a duplicate of this bug. ***
Comment 2 Nate Graham 2021-02-26 22:03:13 UTC
Input on Wayland goes through KWin; moving there.
Comment 3 Nate Graham 2021-03-04 18:58:37 UTC
Confirmed. It looks like no XKB options set in the Keyboard KCM are working in the Wayland session
Comment 4 Vlad Zahorodnii 2021-03-05 10:32:59 UTC
Cannot reproduce this bug. "Swap Esc and Caps Lock" works on my machine. Can you attach your .config/kxkbrc file please?
Comment 5 Nate Graham 2021-03-05 14:25:54 UTC
I have no such file. Perhaps the bug is that the keyboard KCM isn't setting this?
Comment 6 Vlad Zahorodnii 2021-03-05 16:09:05 UTC
(In reply to Nate Graham from comment #5) > I have no such file. Perhaps the bug is that the keyboard KCM isn't setting > this? That or you have missing X11 dependencies. If the keyboard kcm updates the config as expected, you should see caps:swapescape in the kxkbrc file.
Comment 7 Nate Graham 2021-03-05 17:26:41 UTC
Sorry my mistake. The file is there after all. Here is what it says: [$Version] update_info=kxkb_variants.upd:split-variants [Layout] DisplayNames= LayoutList=us LayoutLoopCount=-1 Model=pc101 Options=altwin:prtsc_rwin,print:insert_is_print,compose:caps ResetOldOptions=true ShowFlag=false ShowLabel=true ShowLayoutIndicator=true ShowSingle=false SwitchMode=Global Use=true VariantList=\\0 These options all work on X11, but are ignored on Wayland for me. (print:insert_is_print is a custom one that I have created myself which is currently not working right now due to system updates blowing away the changes I made to the files)
Comment 8 David Edmundson 2021-03-10 00:28:36 UTC
Nothing points to this being a reggresion, I do not believe this was ever especially tested on wayland.
Comment 9 David Edmundson 2021-03-10 00:33:02 UTC
Kwin wayland (currently) only applies options on load. Does that match what we're seeing here?
Comment 10 Nate Graham 2021-03-10 00:55:30 UTC
I marked it as a regression because my XKB options always worked in the wayland session until a few weeks ago. I'm seeing options not being applied at all, even if I set them in the keyboard KCM in the Wayland session itself (not on X11).
Comment 11 Thiago Sueto 2021-03-10 21:33:48 UTC
(In reply to Nate Graham from comment #10) > I marked it as a regression because my XKB options always worked in the > wayland session until a few weeks ago. Same here. I've been using this for a few months at least.
Comment 12 Nate Graham 2021-03-19 22:42:09 UTC
Huh, as of today's git master Wayland session, these are all working again. So either it was accidentally fixed by something, or else for some reason it's unreliable and only works some of the time.
Comment 13 Thiago Sueto 2021-03-21 03:38:22 UTC
(In reply to Nate Graham from comment #12) > Huh, as of today's git master Wayland session, these are all working again. > > So either it was accidentally fixed by something, or else for some reason > it's unreliable and only works some of the time. I deliberately waited a few days to retest on current Plasma from git. Still not working for me. Neither Johnny's "Swap Esc and Caps Lock" or my "Caps Lock as Ctrl" and "Both shift keys enable Caps Lock, one shift disables it" (mentioned in my accidental duplicate bug 433266).
Comment 14 Nate Graham 2021-03-21 04:03:33 UTC
So I guess that lends some fuel to the "it's unreliable or buggy" hypothesis.
Comment 15 Peter Hoeg 2021-03-26 14:40:07 UTC
This sounds very similar to https://bugs.kde.org/show_bug.cgi?id=422329 which was reported in June 2020.
Comment 16 Nate Graham 2021-03-31 19:49:44 UTC
It looks like this is indeed Bug 433576, which is about to be fixed! *** This bug has been marked as a duplicate of bug 433576 ***
Comment 17 Andrey 2021-03-31 20:31:51 UTC
Sorry for the regression, my bad
Comment 18 Nate Graham 2021-04-01 03:19:50 UTC
No worries. *** This bug has been marked as a duplicate of bug 433576 ***
Comment 19 Nate Graham 2021-12-17 14:11:24 UTC
Re-opening as I can still reproduce this on Wayland. :(
Comment 20 Nate Graham 2021-12-17 14:11:35 UTC
*** Bug 433266 has been marked as a duplicate of this bug. ***
Comment 21 Nate Graham 2021-12-17 14:44:46 UTC
If I set the options with `localctl set-x11-keymap us pc101 "" compose:caps` and log out and log back in again, I can see that the xkb variables are populated correctly: $ env | grep XKB 29:XKB_DEFAULT_MODEL=pc101 46:XKB_DEFAULT_LAYOUT=us 83:XKB_DEFAULT_OPTIONS=compose:caps However they aren't getting picked up, even if I comment those options out of ~/.config/kxkbrc and log out and back in again.
Comment 22 Andrey 2021-12-17 15:23:20 UTC
Is it reproducible on Neon? Do others Options work? Can we have ~/.config/kxkbrc dump again? Could someone try on others DEs Wayland sessions to isolate upstream libxkbcommon bugs?
Comment 23 Nate Graham 2021-12-17 17:01:37 UTC
cat ~/.config/kxkbrc [$Version] update_info=kxkb_variants.upd:split-variants [Layout] DisplayNames=\\0 LayoutList=us LayoutLoopCount=-1 Model=pc101 Options=compose:caps ResetOldOptions=true ShowFlag=true ShowLabel=false ShowLayoutIndicator=true ShowSingle=false SwitchMode=Global Use=true VariantList=\\0 No other options work either. Haven't tested on Neon. Fabian Vogt confirmed that he can reproduce this issue in #plasma chat, presumably on an openSUSE distro, probably Tumbleweed.
Comment 24 Andrey 2021-12-17 17:10:07 UTC
(In reply to Nate Graham from comment #23) > cat ~/.config/kxkbrc > ... > VariantList=\\0 Hmm, that was fixed above, presumably older Plasma ran somehow and reintroduced the bug in config.. Does it recover if you delete this line?
Comment 25 Fabian Vogt 2021-12-17 17:12:36 UTC
The issue is that the port to KConfigXT unintentionally changed the format of various entries, so they are incompatible to older files and the way KWin reads it. I'm working on a MR with some fixes for some other issues I found.
Comment 26 Fabian Vogt 2021-12-28 11:15:54 UTC
Git commit e6cc0b1fca1176ffbcc6e024a3fb72729049f3c9 by Fabian Vogt. Committed on 28/12/2021 at 11:05. Pushed by fvogt into branch 'master'. [kcms/keyboard] Avoid serializing list options as \\0 VariantList, DisplayNames and Options are comma-delimited string lists in a setxkbmap/libxkbcommon compatible format, but serializing a QStringList with a single empty string ends up as "\\0" in the config file, which is not compatible. This can't happen for LayoutList, because layout strings are never empty. Add a kconf_update script to convert \\0 into empty lists for the affected entries. This restores the old format for compatibility with e.g. KWin. M +13 -4 kcms/keyboard/kcm_keyboard_widget.cpp M +4 -0 kcms/keyboard/kconf_update/CMakeLists.txt A +8 -0 kcms/keyboard/kconf_update/kxkb.upd A +17 -0 kcms/keyboard/kconf_update/kxkb_emptylists.awk M +10 -0 kcms/keyboard/keyboard_config.cpp M +4 -0 kcms/keyboard/keyboardsettings.kcfg https://invent.kde.org/plasma/plasma-desktop/commit/e6cc0b1fca1176ffbcc6e024a3fb72729049f3c9
Comment 27 Fabian Vogt 2021-12-28 11:16:02 UTC
Git commit ef3a2c6c6b07978a0d3267f659a8e9134c4f5ce3 by Fabian Vogt. Committed on 28/12/2021 at 11:05. Pushed by fvogt into branch 'master'. [kcms/keyboard] Fix fallback handling in X11Helper::getGroupNames - Remove checks of QString against nullptr - Return an empty list if no options are set, instead of a single empty option M +9 -6 kcms/keyboard/x11_helper.cpp https://invent.kde.org/plasma/plasma-desktop/commit/ef3a2c6c6b07978a0d3267f659a8e9134c4f5ce3
Comment 28 Fabian Vogt 2021-12-28 11:30:42 UTC
Git commit 701d94ff1399eb18dabc77693f76893c95b7c768 by Fabian Vogt. Committed on 28/12/2021 at 11:28. Pushed by fvogt into branch 'Plasma/5.23'. [kcms/keyboard] Fix fallback handling in X11Helper::getGroupNames - Remove checks of QString against nullptr - Return an empty list if no options are set, instead of a single empty option (cherry picked from commit ef3a2c6c6b07978a0d3267f659a8e9134c4f5ce3) M +9 -6 kcms/keyboard/x11_helper.cpp https://invent.kde.org/plasma/plasma-desktop/commit/701d94ff1399eb18dabc77693f76893c95b7c768
Comment 29 Fabian Vogt 2021-12-28 19:49:07 UTC
FTR, this was initially broken in v5.20.90 by 343ad3bab21597f6fff898b27219d63408d59543, then fixed in v5.21.90 by 1c10a6f6612f09281f4fdcfdba6ba7c250f23f72, broken in master by the kconfigxt port (dd5db629ed99a97ed4753731d742afe752d1423b) and then fixed by e6cc0b1fca1176ffbcc6e024a3fb72729049f3c9 again. I hope the comment in kcms/keyboard/keyboardsettings.kcfg file helps that a future QML port doesn't follow a similar fate.