GNOME Bugzilla – Bug 777000
Add an option to set the keyboard model
Last modified: 2021-07-05 13:46:01 UTC
When using some keyboards (like the Chromebook keyboards), setting the XKB model is needed for them to work as expected (in this case, so the keys in the function key row work as modifier keys. When using Xorg it is possible to set the model manually by using: setxkbmap -model chromebook However, this does not work when using Gnome on Wayland, since input sources are handled directly by the desktop compositor. This could ideally be set at least via an option on org.gnome.desktop.input-sources in dconf.
I think this should rather be fixed properly for everyone. Optimally, we should do it in the same way as we handle special XKB layouts/variants (used by devices such as the YubiKey) by adding a XKB_FIXED_MODEL to the hwdb. This way we mark each device that needs a special xkb model and it'll work for everyone without any need to tweak any knob. I made a systemd branch here that introduces the udev tag: https://github.com/jadahl/systemd/commits/wip/xkb-fixed-model
ACK, this seems like the most effective solution.
See: https://bugzilla.gnome.org/show_bug.cgi?id=650772
(In reply to Bastien Nocera from comment #3) > See: https://bugzilla.gnome.org/show_bug.cgi?id=650772 Could you summarize? Whats the conclusion? The intended solution will not introduce any UI or preferences, it'd be a udev property set according to the hwdb that mutter would try to honor. See bug 775681 for a similar thing we need to do.
al, in order to get the device you have that needs the "chromebook" xkb model match a potential udev hwdb rule, could you run "evemu-describe" to get the given keyboard device details?
The DMI identificator of the keyboard in my device as shown by evemu-describe is: DMI: dmi:bvncoreboot:bvr4.0-6588-g4acd8ea-dirty:bd09/04/2014:svnGOOGLE:pnPeppy:pvr1.0:rvnGOOGLE:rnPeppy:rvr1.0:cvnGOOGLE:ct3:cvr: This hwdb rule correctly matches my keyboard: evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGOOGLE:pnPeppy:pvr* This is an Acer C720 Chromebook (codename Peppy), btw.
I have the same problem with my Chromebook. AFAIK, unlike other desktop environnement, there is no way to change the keyboard model with Gnome Shell. It's not really a problem with X11 since there is multiple ways to change the keyboard model. I use this method "$ sudo localectl set-x11-keymap fr chromebook". But in Gnome Shell with wayland, since all the X11 tools doesn't work anymore, it's impossible to change the keyboard model. Is there a workaround ? Can you add a way to change the keyboard model ? Thanks.
Created attachment 366339 [details] Chromebook keyboard By the way, we need to select a custom keyboard model because there is some missing key on the Chromebook keyboards. We "unlock" them with an overlay key. Here is mine and here is the more official one that come with crouton https://github.com/dnschneid/crouton/blob/master/targets/keyboard Here is more explanation https://github.com/dnschneid/crouton/wiki/Keyboard
If that can be add to a udev hwdb rule it could be nice too I guess.
Sorry for the multiple comments but that make me think that I use a udev hwdb rule in complement for my Chromebook : # tee "/etc/udev/hwdb.d/90-chromebook-keyboard-fix.hwdb" << 'EOF' # Chromebook 14 fix evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnFalco:pvr* KEYBOARD_KEY_db=leftmeta EOF # udevadm hwdb --update
Well, after some research, a udev hwdb rule, afaik, is not the solution. hwdb can't handle the 'overlay" keys to add the missing keys like "overlay key (Right Ctrl)" + "backspace" = "delete". So we really need that gnome allow us to choose the keyboard model like other desktop environment and display manager do (xfce, kde, sway, etc...). Thanks.
the hwdb is a merely descriptive database that can add udev properties. Actual functionality changes depend on external bits that read those properties (the udev-builtin-keyboard for KEYBOARD_KEY_* for example). The proposal in comment #1 is to add such a merely descriptive property but then have mutter read it and apply the model correctly based on that. This is more work initially (and where your focus should be if you want to help out) but long-term makes things work out-of-the-box for everyone.
Does the proposal in comment #1 can handle the "latch" keys needed to emulate the missing keys ? If that's the case how can we help ?
(In reply to Jonas Ådahl from comment #4) > (In reply to Bastien Nocera from comment #3) > > See: https://bugzilla.gnome.org/show_bug.cgi?id=650772 > > Could you summarize? Whats the conclusion? The intended solution will not > introduce any UI or preferences, it'd be a udev property set according to > the hwdb that mutter would try to honor. See bug 775681 for a similar thing > we need to do. The conclusion is exactly that :) udev/hwdb property to tag devices that need specific models, and mutter to apply those properties.
(In reply to Peter Hutterer from comment #12) > the hwdb is a merely descriptive database that can add udev properties. > Actual functionality changes depend on external bits that read those > properties (the udev-builtin-keyboard for KEYBOARD_KEY_* for example). The > proposal in comment #1 is to add such a merely descriptive property but then > have mutter read it and apply the model correctly based on that. This is > more work initially (and where your focus should be if you want to help out) > but long-term makes things work out-of-the-box for everyone. Peter can you tell me if the proposal in comment #1 can handle the "latch" key needed to emulate the missing keys (like "overlay key (Right Ctrl)" + "backspace" = "delete") ?
if the current XKB model supports what you need, then that proposal supports it too. If it doesn't, then not :) It's literally no different to adding a xkb model, except that it'll be a fixed database of devices rather than a config option.
Well I guess that should work. Do you know when we will be able to test it ?
Somebody needs to write the code first, and it's unfortunately ETIME for a lot of people
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.