You are not logged in.
I have arch running on a chromebook. Rather than the traditional function key row at the top of the keyboard I have a set of "special" keys for controlling volume, monitor brightness and navigation. Prior to gnome 3.22, when xorg was default, I was able to leverage the chromebook symbols in /usr/share/X11/xkb/symbols/inet to map these keys to their corresponding functions:
partial alphanumeric_keys
xkb_symbols "chromebook" {
include "level3(ralt_switch)"
key <FK01> { [ XF86Back ] };
key <FK02> { [ XF86Forward ] };
key <FK03> { [ XF86Reload ] };
key <FK04> { [ F11 ] };
// key <FK05> { [ F5, F5, F5, F5 ] }; // Overview key
key <FK06> { [ XF86MonBrightnessDown ] };
key <FK07> { [ XF86MonBrightnessUp ] };
key <FK08> { [ XF86AudioMute ] };
key <FK09> { [ XF86AudioLowerVolume ] };
key <FK10> { [ XF86AudioRaiseVolume ] };
key <BKSP> { [ BackSpace, BackSpace, Delete ] };
key <UP> { [ Up, Up, Prior, Up ] };
key <DOWN> { [ Down, Down, Next, Down ] };
key <LEFT> { [ Left, Left, Home, Left ] };
key <RGHT> { [ Right, Right, End, Right ] };
key <LWIN> { [ Super_L, Super_L, Caps_Lock, Super_L ] };
};Ever since gnome switched to wayland I haven't been able to figure out how to get this functionality back. Wayland (or libinput) detects the keyboard model as a standard "pc105" rather than "chromebook". However, even if I manually set the correct model and symbols via setxkbmap the keys continue to operate as standard function keys.
I think I'm missing some fundamental understanding of how XKB and libinput integrate (or maybe they don't) under wayland. Could somebody explain this gap to me (and help me resolve my issue at the same time)?
Offline
From what I understand, XKB would only apply with applications running under the Xwayland compatibility backend.
Offline
I believe you are correct. It looks like with libinput it only captures the basic key press events and passes those up to the DM to do composition and determine context (what xkb used to do). So in my case I need to figure out how to configure gnome to redirect my key presses. Unfortunately it doesn't look like that level of configuration has been exposed yet.
In the meantime I came up with an acceptable (for my use case) workaround. I updated the scancode mappings in udev for the f6-f10 keys (volume and monitor brightness controls) and remapped them directly to the desired keycode. However, there is one downside to this method, since keycodes are evaluated at the kernel level there is no opportunity to redirect based on context or modifiers (RALT + BACKSPACE == DELETE). For this reason I left f1-f5 with their default mapping. I need those keys for swtiching between vterms, launching the run dialog and other common function-key based shortcuts.
I'll try living with this for a few weeks and keep digging into gnome to see if I can figure out a better solution.
Offline