Bug 433265

*** Bug 433266 has been marked as a duplicate of this bug. ***

Input on Wayland goes through KWin; moving there.

Confirmed. It looks like no XKB options set in the Keyboard KCM are working in the Wayland session

Cannot reproduce this bug. "Swap Esc and Caps Lock" works on my machine. Can you attach your .config/kxkbrc file please?

I have no such file. Perhaps the bug is that the keyboard KCM isn't setting this?

(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.

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)

Nothing points to this being a reggresion, I do not believe this was ever especially tested on wayland.

Kwin wayland (currently) only applies options on load. 

Does that match what we're seeing here?

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).

(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.

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.

(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).

So I guess that lends some fuel to the "it's unreliable or buggy" hypothesis.

This sounds very similar to https://bugs.kde.org/show_bug.cgi?id=422329 which was reported in June 2020.

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 ***

Sorry for the regression, my bad

No worries.

*** This bug has been marked as a duplicate of bug 433576 ***

Re-opening as I can still reproduce this on Wayland. :(

*** Bug 433266 has been marked as a duplicate of this bug. ***

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.

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?

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.

(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?

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.

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

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

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

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.