Re: Upstream support of Google Chromebook keyboards (udev, xkeyboard-config)?

[Dmitry Torokhov]

Hi Paul,

On Mon, Dec 27, 2021 at 05:18:44PM +0100, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> 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:

> 
> 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. The "globe" key you see is
supposed to select next keyboard layout. 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
 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).

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

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

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

Thanks.
 
-- 
Dmitry