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
