Messages in this thread | | | Date | Tue, 4 Jan 2022 16:31:59 +0100 | Subject | Re: Upstream support of Google Chromebook keyboards (udev, xkeyboard-config)? | From | Paul Menzel <> |
| |
Dear Dmitry,
Am 04.01.22 um 01:00 schrieb Dmitry Torokhov:
> On Mon, Dec 27, 2021 at 05:18:44PM +0100, Paul Menzel wrote:
>> Installing a non-Chromium OS distribution like Debian on a Google >> Chromebook, in this case a Dell Latitude 5400 Chrome (google/sarien), not >> all keys work as expected. > > Looking at the issues you are referencing you are flashing a 3rd party > firmware on the device so I am unable to comment on behavior of that > firmware, however:
Not quite, I only flash the RW_LEGACY section, so only the payload is changed as the vendor firmware unfortunately does not ship with a depthcharge alternative making booting another operating system impossible. (Or I missed something.)
>> 1. Non-working super key and two function keys on Google Chromebook Dell >> Latitute 5400 Chrome (google/sarien) [1] > > There is no "super" key on Chromebooks.
Sorry for mixing the terminology. (On the identical in design Dell Latitude 5400 it is that key.)
> The "globe" key you see is supposed to select next keyboard layout.
Oh, interesting choice.
> This is the udev hwdb entry that we have for Sarien/Arcada devices in > our tree: > > # Copyright 2019 The Chromium OS Authors. All rights reserved. > # Distributed under the terms of the GNU General Public License v2 > > # > # Special keyboard mapping for the Sarien project. The keyboard emits both > # function and action scan codes depending on Fn-modifier key. > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pnSarien:pvr* > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pnArcada:pvr* > KEYBOARD_KEY_ea=back > KEYBOARD_KEY_e7=refresh > KEYBOARD_KEY_d5=full_screen > KEYBOARD_KEY_d6=scale
(As I was unfamiliar with `scale`, after pressing it, you see an overview of the currently opened windows on the current virtual desktop.)
> KEYBOARD_KEY_95=brightnessdown > KEYBOARD_KEY_91=brightnessup > KEYBOARD_KEY_a0=mute > KEYBOARD_KEY_ae=volumedown > KEYBOARD_KEY_b0=volumeup > KEYBOARD_KEY_8b=switchvideomode > KEYBOARD_KEY_d8=sleep > KEYBOARD_KEY_d4=kbd_layout_next > > (Note that on Chrome OS we are transitioning from F1-F10 being primary > key codes emitted by the kernel to what we call "action" codes - back, > refresh, etc).
Thank you, in what Chromium repository is that file? Do you know the reason, why these are not upstreamed to udev/systemd?
>> 2. Wrong caps lock key and function key mappings on Google Chromebook Dell >> Latitute 5400 Chrome (google/sarien) [2] > > There is no CapsLock on Chromebooks either. We are using "search" or > "launcher" key which is actually Left Meta in place of CapsLock.
Yes, that is what I described in the bug report.
>> Peter replied, this should be fixed in udev, so it’s not directly related to >> the Linux kernel, as the Linux kernel exposes the scancodes(?) just fine. >> But what is the upstream process for this in general? Chromium OS carries >> `91-chromeos-keyboard.rules` for example. >> >> systemd/udev currently has an entry for two Google Chromebook models in >> `hwdb.d/60-keyboard.hwdb` [4]: >> >> ######################### FIXED MODEL DEVICES ############################# >> # This section lists devices which require special handling in their key >> # code to keysym mapping by setting the xkb model. >> # The model must be an xkb compatible model (defined with XKB_FIXED_MODEL). >> >> # Chromebooks >> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnFalco:pvr* >> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:pvr* >> XKB_FIXED_MODEL="chromebook" > > Yes, that is the right place for it. You submit a PR against systemd > with the new mappings.
From `/usr/share/X11/xkb/symbols/inet` from *xkb-data* 2.33-1:
``` 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 ] }; ```
This layout is different from the one used on google/sarien. How many different layouts are there, and how do you organize them in Chromium OS?
>> The Dell Chromebooks, unfortunately, also use the embedded controller with >> Dell’s proprietary firmware (Wilco(?)), and not Chrome EC making special >> handling necessary. `91-chromeos-keyboard.rules` has >> >> # Wilco keyboard (5220W-C) for Chrome OS >> SUBSYSTEM=="input", \ >> ATTRS{idVendor}=="413c", ATTRS{idProduct}=="2510", \ >> ENV{CROS_KEYBOARD_TOP_ROW_LAYOUT}="3", \ >> ENV{ID_INPUT_KEYBOARD}="1" > > This is only needed on Chrome OS to let Chrome know how to map the > "action" scancodes back to F1-F10 when they are chorded with "launcher" > key. This is Chrome on Chrome OS-specfic behavior and is of no interest > to other parties.
Thank you for the clarification.
Kind regards,
Paul
| |