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