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.
1. Non-working super key and two function keys on Google Chromebook
Dell Latitute 5400 Chrome (google/sarien) [1]
2. Wrong caps lock key and function key mappings on Google Chromebook
Dell Latitute 5400 Chrome (google/sarien) [2]
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"
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"
Kind regards,
Paul
[1]:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/298
[2]:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/299
[3]:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/783bd8563450d9e9e575323a83321fdc67e334bf/sys-fs/udev/files/91-chromeos-keyboard.rules
[4]:
https://github.com/systemd/systemd/commit/d7d31692bf7cde5dce7f4ed3cae429a5b302a9f0?branch=d7d31692bf7cde5dce7f4ed3cae429a5b302a9f0
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
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
Hi Paul,
On Tue, Jan 04, 2022 at 04:31:59PM +0100, Paul Menzel wrote:
> 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.)
If you adjust the way you do kernel install (by altering or providing an
alternative to /sbin/installkernel) you can keep Chrome OS partition
scheme and write kernel image to KERN_A or KERN_B partition... Some
people do that.
>
> > > 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.)
Right, I am only talking about Chromebooks.
>
> > 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?
You can find it here:
https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/refs/heads/main/overlay-sarien/chromeos-base/chromeos-bsp-sarien/files/81-sarien-keyboard.hwdb
If you look through other overlays you will find a couple more adding
"assistant" key definitions to Pixelbook and Pixelbook Go.
> Do you know the reason, why these are not upstreamed to udev/systemd?
Just an oversight I think.
>
> > > 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.
What I am trying to say is that for Chromebooks this is not a bug but
rather how they are supposed to work.
>
> > > 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?
We have 4 hard-coded ones:
- classic one - back, forward, refresh, full screen, scale/overview,
brightness up, brightness down, mute, volume up, volume down, sleep.
- "Pixelbook" - no forward key, play/pause between brightness up and
mute key
- sarien/arcada - as shown in the mapping above
- drallion (followup to sarien) - same as sarien, with the exception
that units with privacy screen have privacy screen toggle on what is
typically F12 instead of mirror/switchvideomode.
Newer devices have key map for internal keyboard specified via ACPI
(see drivers/input/keyboard/atkbd.c::atkbd_get_keymap_from_fwnode()) and
therefore we no longer need static ones when we want to add or remove
some keys from the top row.
Hope this helps.
--
Dmitry