Bug 432818 - Use libxkbregistry to parse the rules files
Summary: Use libxkbregistry to parse the rules files
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_keyboard (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
: 471273 480159 (view as bug list)
Depends on:
Reported: 2021-02-11 21:52 UTC by Nate Graham
Modified: 2024-04-13 13:39 UTC (History)
14 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.1

fcitx5-diagnose (14.99 KB, text/plain)
2023-09-24 03:01 UTC, David Conner

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2021-02-11 21:52:57 UTC
This is a library that will parse xkb rules files and is aware of user-supplied rules in ~/.config/xkb/rules. It's relatively new (see https://who-t.blogspot.com/2020/07/user-specific-xkb-configuration-part-2.html and the keyboard KCM doesn't use it yet. As a result, user-created XKB rules in ~/.config/xkb are ignored, and changed need to be made to the distro-provided files, which is generally a no-no.

GNOME got support for this last year: https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/79

This is probably a necessity before we can offer a proper GUI for key re-mapping, since such a thing would optimally implement the map as an auto-generated xkb option added to the user's home folder.
Comment 1 Andrey 2021-03-26 20:55:19 UTC
Just a note - the key mapping GUI doesn't necessary have to operate on XKB level.
For trivial physical keys remapping, much simpler would be to change keycodes they produce. It can be done via udev hwdb:
Comment 2 Nate Graham 2021-04-01 03:12:59 UTC
Ah yeah, I suppose that could be wrapped in a GUI to avoid having to use XKB at all.
Comment 3 zeertzjq 2021-04-17 01:35:26 UTC
Using udev hwdb maps keycodes, not keysyms, so XKB is still needed to map keys to keysyms like `Multi_key` and to create extra two-level keys (like making KEY_WLAN toggle Wi-Fi on the first level and toggle Bluetooth on the second level), etc..
Comment 4 Charles Samborski 2021-05-21 18:56:07 UTC
I also wanted to use a user-specific layout and followed the articles from Who-T's but was disappointed that it is not supported yet by Plasma. 

This feature is important to me: I'd be happy to help fix this issue.
Comment 5 Nate Graham 2021-05-21 18:58:39 UTC
Please do. I would be eternally grateful!
Comment 6 Johannes Schmidt 2023-03-25 08:35:58 UTC
Is there any progress on this? I just tried to add my own layout as per the official documentation (https://xkbcommon.org/doc/current/md_doc_user_configuration.html) and it doesn't show up in systemsettings.

This seams somewhat important for wayland support because the old X11 way of using .xmodmap is no longer available to use for user configuration. Libxkbcommon is now the only way to modify/define layouts and libxkbregistry is the only way to dynamically add user configuration.
Comment 7 Johannes Schmidt 2023-03-25 08:40:05 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Andrey 2023-03-25 09:31:53 UTC
AFAIK, there was no progress and no is planned.
libxkbregistry  doesn't give you any extra functionality, it's just for developer convenience. 

Do you know you can place your stuff in ~/.xkb, $XDG_CONFIG_HOME/xkb or $HOME/.config/xkb (I might be wrong about exact paths)?

See here and derivative links:
Comment 9 Andrey 2023-03-25 09:52:37 UTC
Does your custom config get applied at least?

There is a note in the docs:
"Note: Where libxkbcommon runs in a privileged context, only the system (datadir) path is available."
I remember there was a patch merged to KWin master some time ago to allow it run in unprivileged mode.

You also have to remove a tick in the Keyboard KCM so it doesn't override system settings.
Maybe some env vars need to be set, I don't remember..

Anyway, if you can't get you config applied, please file a separate bug as it should work already.
Having your changes in the Keyboard KCM is the other thing and can be tracked here.
Comment 10 Johannes Schmidt 2023-03-27 10:52:19 UTC
I'm not 100% solid on this, but as far as I'm aware, even if you uncheck layout settings and options in the KCM, the only way to apply xkb settings (user or system) manually is using xkbcomp/setxkbmap in .xinitrc/.bashrc or globally via xorg.conf, which all have downsides and all require X11 to work.

On Wayland, as far as I know, all xkb stuff requires the compositor (kwin) to do the work and thus discoverability to present the choices added by the user in the settings. And for that, KDE needs to either add support for libxkbregistry or otherwise parse the ~/.config/xkb/rules/evdev.xml file to discover what settings are available.

And even if Wayland isn't a priority yet (which surely can't be true, but fine), can "just disable the GUI setting and do it manually somewhere outside KDE" really be the answer for a project that strives for user-friendliness, convenience and standard conformity?

Correct me if I'm entirely wrong on this or missing something, But I don't see what I, as a user am supposed to do when I want to add a modified layout or options on Plasma Wayland.
Comment 11 Johannes Schmidt 2023-03-27 11:01:03 UTC
To further clarify:

(In reply to Andrey from comment #9)
> Does your custom config get applied at least?

No, it doesn't get applied, since it doesn't show up in settings and thus there is no way to apply it, unless I'm completely mistaken.

XKB gives me a way to add layouts and options, but no way to set them (on wayland). Something else is needed to set them. On X11 that could be manually via setxkbmap/xkbcomp or globally via xorg.conf. On Wayland that job necessarily goes to the compositor. And the compositor can't know which layout to pick on its own so it needs a way to discover user settings and allow to pick between them.
Comment 12 Andrey 2023-03-27 12:31:38 UTC
As said above, XKB custom configuration should get applied having you put it in proper place in HOME, and other mentioned conditions met. Even on Wayland.
That might need recent KWin enough (I'm not sure) - can you test on Neon dev VM if the test on your current system fails (by the way, dump your system's details)?
Anyway, that should be checked first, because it should already work and if it's not, it should be fixed in the first place.

Please file a separate report if you can't make it work.
Comment 13 Andrey 2023-03-27 12:40:00 UTC
See bug 447206 for details
Comment 14 Johannes Schmidt 2023-03-28 11:41:55 UTC
(In reply to Andrey from comment #12)
> As said above, XKB custom configuration should get applied having you put it
> in proper place in HOME, and other mentioned conditions met. Even on Wayland.

"and other mentioned conditions" is doing a lot of work here, but yes, putting in these environment variables to load custom keymaps/options from $XDG_CONFIG_HOME indeed works. I wasn't aware of these variables and that plasma supported them.

For my use-case this is already good enough, but I'd still rather see proper config discovery being implemented.
Comment 15 Andrey 2023-03-28 12:01:11 UTC
XKB_* vars are parsed by libxkbcommon itself and have nothing to do with Plasma.
KWIN_XKB_DEFAULT_KEYMAP is from KWin but I'm not sure if it's necessary.
Comment 16 Andrey 2023-06-20 20:53:55 UTC
*** Bug 471273 has been marked as a duplicate of this bug. ***
Comment 17 Gerry Agbobada 2023-06-20 21:25:01 UTC
For the record, the "other mentioned conditions" end up looking like this:

$ cat ~/.config/plasma-workspace/env/setkeymap.sh
export QT_LOGGING_RULES="kwin_*.debug=true"
export XKB_DEFAULT_VARIANT=my_fr_variant

(Or just using XKB_DEFAULT_LAYOUT if you're making your own layout without being another variant).

As Johannes Schmidt pointed out though, it still makes for a not-that-much user-friendly setup, as the dialog in ksystemsettings still shows the layouts that I had before, which is outdated info (my layouts in systemsettings show "us(EURKey)", while I'm typing in the custom layout specified in env). I can live with that on a single user machine knowing where I did the trick though
Comment 18 Aldoo 2023-06-29 16:27:23 UTC
Also, relying on environment variables is not really convenient, since you need to restart the session to take changes into account.
So not only it is just user unfriendly, but also it is much less flexible than setxkbmap used to be.
Comment 19 David Conner 2023-09-24 03:01:30 UTC
Created attachment 161839 [details]

I can't get KWin Wayland to respond at all to the keyboard settings, whether using:

+ `localectl`
+ `setxkbmap`
+ `.config/kxkbrc`
+ `xkbcli` with `~/.config/xkb`, confirmed working with `xkbcli list`
+ keyboard settings: no customizations in `~/.config/xkb/rules/evdev.xml` show

when I change things in the keyboard settings dialog, nothing happens. 

$ env | grep XKB

$ cat ~/.config/kxkbrc



this is a reference to a function i'm trying to export, but is unrelated. there's no other mention.

$ cat ~/.local/share/sddm/wayland-session.log
org.kde.plasma.libkworkspace: Skipping syncing of environment variable  "BASH_FUNC_guix_arch_load%%" as name contains unsupported characters
org.kde.plasma.libkworkspace: Skipping syncing of environment variable  "BASH_FUNC_guix_arch_load%%" as name contains unsupported characters

the moz japanese keyboad for fcitx5 does work, but nothing else does. it doesn't respect the keyboard options in the keyboard settings.

i've attached the fcitx5-diagnose output, since it contains more detail on related environment variables.

I've spent about a week on this, on and off.
Comment 20 Andrey 2023-10-02 22:15:52 UTC
(In reply to David Conner from comment #19)
Did you see the comment above?
Comment 21 Andrey 2024-01-24 13:26:12 UTC
*** Bug 480159 has been marked as a duplicate of this bug. ***
Comment 22 Nate Graham 2024-04-13 05:35:51 UTC
Implemented by Arkadiusz Guzinski for Plasma 6.1 with https://invent.kde.org/plasma/plasma-desktop/-/commit/f5f8038321e44d191e925c4e999fd0bf4fd539e6!