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:
https://wiki.archlinux.org/index.php/Map_scancodes_to_keycodes:

Ah yeah, I suppose that could be wrapped in a GUI to avoid having to use XKB at all.

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

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.

Please do. I would be eternally grateful!

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.

*** This bug has been confirmed by popular vote. ***

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:
https://github.com/xkbcommon/libxkbcommon/issues/114
https://github.com/xkbcommon/libxkbcommon/issues/112

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.

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.

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.

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.

See bug 447206 for details

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

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.

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

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_LOG_VERBOSITY=10
export KWIN_XKB_DEFAULT_KEYMAP=yes
export XKB_DEFAULT_LAYOUT=fr
export XKB_DEFAULT_VARIANT=my_fr_variant
export XKB_CONTEXT_NO_SECURE_GETENV=yes

(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

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.

Created attachment 161839 [details]
fcitx5-diagnose

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. 

```sh
$ env | grep XKB
XKB_DEFAULT_MODEL=altgr-intl
XKB_DEFAULT_LAYOUT=us
XKB_DEFAULT_VARIANT=ctrl:hyper_capscontrol,lvl3:menu_switch,lvl3:ralt_alt
```

```
$ cat ~/.config/kxkbrc

[$Version]
update_info=kxkb.upd:remove-empty-lists,kxkb.upd:add-back-resetoptions,kxkb_variants.upd:split-variants

[Layout]
DisplayNames=
LayoutList=us
Model=pc105
Options=custom:types,ctrl:hyper_capscontrol,lv3:menu_switch,lv3:ralt_alt
ResetOldOptions=true
Use=true
VariantList=
```

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.

(In reply to David Conner from comment #19)
Did you see the comment above?
https://bugs.kde.org/show_bug.cgi?id=432818#c17

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

Implemented by Arkadiusz Guzinski for Plasma 6.1 with https://invent.kde.org/plasma/plasma-desktop/-/commit/f5f8038321e44d191e925c4e999fd0bf4fd539e6!