Date:   Tue, 4 Jan 2022 16:31:59 +0100
From:   Paul Menzel <pmenzel@...gen.mpg.de>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     linux-input@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Felix Singer <felixsinger@...teo.net>,
        Matt DeVillier <matt.devillier@...il.com>
Subject: Re: Upstream support of Google Chromebook keyboards (udev,
 xkeyboard-config)?

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

Powered by blists - more mailing lists