For some reason it works if you -print
and pipe the output to xkbcomp
:
setxkbmap \
-I ~/.config/xkb/ \
-rules evdev-local \
-layout "my-us(mdvp)" \
-print |
xkbcomp -I ~/.config/xkb/ - "$DISPLAY"
I don’t think there is anything wrong with your layout. I tried setting
it up with setxkbmap
directly, but even with the -verbose
option the
output is not helpful:
Warning! Multiple definitions of rules file
Using command line, ignoring X server
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+my-us(mdvp)+inet(evdev)+terminate(ctrl_alt_bksp)
geometry: pc(pc104)
Error loading new keyboard description
This is with the default verbose level. But even if I set it to 10,
which is apparently the max level, it just outputs “locale is C” as well
as where it tries to look for the rules file, in addition to the above.
It does not output anything more about why it fails to load the keyboard
description.
One of the reasons why I prefer to pipe to xkbcomp
instead of just
using setxkbmap
is because the former seems to give better error
messages.
As I've stated in my question, there is already xkb which already has alot options for modifying the keyboard. It wasn't an option for me because the only option to modify the printscr key, replaced it with Win_R. Gunnar Hjalmarsson on this thread suggested to me that I modify xkb's modifications so that the printscr/win_r would do printscr/menu instead. We worked out a solution together and I'm going to retransmit it here:
In terminal, enter:
sudo su
nano /usr/share/X11/xkb/symbols/altwin
At the bottom of the file you will find:
// Win is mapped to the PrtSc key (and the usual Win key).
partial modifier_keys
xkb_symbols "prtsc_rwin" {
replace key <PRSC> { [ Super_R, Super_R ] };
modifier_map Mod4 { <PRSC>, <RWIN> };
};
Delete this section and replace it with this:
// Menu is mapped to the PrtSc key (and the usual Win key).
xkb_symbols "prtsc_rwin" {
replace key <PRSC> { [ Menu, Menu ] };
modifier_map Mod4 { <PRSC>, <MENU> };
};
To delete in nano, use backspace key (highlighting and deleting doesn't work). To paste, use shift-ctrl-v. To exit and save, press ctrl-x, select yes to overwrite and press enter.
Reboot.
In Gnome/Ubuntu
Go to gnome-tweak-tools
In tweak tools go to Keyboard & Mouse section, press the Additional Layout Options button and expand Alt/Win key behavior. Selecting the option on the very bottom: Win is mapped to printscr (remember that we've modified just this behavior to swap print and Menu instead of print and Win).
(I'm sure there is a way of turning on the modded xkb option in KDE but I don't use it, so I can't give you the exact procedure).
Best Answer
Yes, Wayland uses XKB for keyboard layouts. But it's not quite the right question, because things work different than in X. Remember that Wayland is only a protocol (plus a wrapper library).
At the protocol level, wayland has a wl_keyboard.keymap event. This event contains a file descriptor to the keymap and a format classifier. Right now, only one format is defined: "xkb". So a wayland client will receive an XKB-compatible keymap and can use libxkbcommon to interpret that to get the right glyph on the screen, etc.
But Wayland does not define how this keymap is decided on. This decision is up to the compositor. In Weston, it is read from the config file on startup, in GNOME it comes from gsettings, etc. And this decision thus also defines how you can change keymaps at runtime (if at all possible). In GNOME you'd either use the config panel or you'd set the gsettings keys directly.
The X protocol has requests to set the keymap on the protocol level and these are what makes tools like setxkbmap possible. The Wayland does not have these requests, it's not possible to set the keymap using the Wayland protocol alone.