F1-F10 function keys in full UEFI firmware

[mapmot]

MrChromebox full UEFI firmware remaps the top keyboard row from F1-F10 to KEY_BACK...KEY_VOLUMEUP.

This leaves no easy way to use F1-F10 in Linux environment, which is the most most common use case for switching to such environment in the first place (Alt-F2 = run command, Ctr+Alt+F[1-10] to switch to a virtual terminal, even in console text mode, etc).

There is an easy way however to remap to the ChromeOS keyboard layout in a Linux Desktop Environment by selecting the "chromebook" X11 keyboard model.

I think that the full UEFI MrChromebox firmware should leave the top keyboard row to be F1-F10, and the user will then have a choice of using that traditional Linux functionality, or selecting the "chromebook" X11 keyboard layout in their Desktop Enviromment to get the ChromeOS experience.

...or leave it F1-F10 for devices, that cannot easily run Windows, like hatch (i.e. nightfury) ;)

[w3bFinger]

I agree!

[ChristianIvarsson]

Add me to the list of whiners (sorry). Those shortcuts are just in the way.

[mapmot]

For hatch, the offending commit is this.

I have managed to compile the ChromeOS EC RW firmware from source using native toolchain with that commit reverted. If anybody with a nightfury chromebook (actually, anything hatch based), is interested, I can upload a MrChromebook full UEFI firmware with the annoying functionality removed.

I fully sympathise with Matt (MrChromebox), who already had to revert 2 of his commits in the hatch ec firmware branch. The remainig 2 of 4 total are the keyboard remapping, and a change to the version reported by the firmware :)

[MrChromebox]

the change on the EC side was to unify all HATCH based devices, since some used Vivialdi and some didn't. There's no need to make any change in the EC firmware however, you can simply disable it in coreboot instead

[mapmot]

There's no need to make any change in the EC firmware however, you can simply disable it in coreboot instead

can you elaborate on that?

[MrChromebox]

can you elaborate on that?

coreboot generates the ACPI code that tells the linux HID driver to remap the keys. Comment out the acpi generation and the keys should work as normal f-keys

[mapmot]

@MrChromebox, based on your somewhat cryptic comment, I am assuming you mean acpigen_ps2_keyboard_dsd in src/ec/google/chromeec/ec_acpi.c? Should I make a PR based on that, close the bug with WORKSFORME, or you will close it with WONTFIX?

[MrChromebox]

I'm talking to some of the Google coreboot devs, trying to figure out the best way to handle this so that the keys both work OOTB and also still have the ability to function as F-keys

[dewitte-77]

You can use udev rules to remap scan codes that are above 255 and then use "keyd" to create shortcuts. I prefer to have the top row working as multimedia keys and use SUPER to call the F1-F10 functions. With "keyd" the shortcuts work in xorg, wayland and terminal. See https://wiki.archlinux.org/title/Lenovo_IdeaPad_Flex_3_CB_11IGL05_Chromebook#Function_keys

[sesquipedality]

I have seen the F keys work in other solutions (depthboot) by holding down search and pressing the top row buttons. Web searches suggest this may be the "official" method to get F key scan codes on a Chromebook.

[zwimer]

I'm talking to some of the Google coreboot devs, trying to figure out the best way to handle this so that the keys both work OOTB and also still have the ability to function as F-keys

@MrChromebox Is it not not possible to simply prompt the user to select which they prefer upon install?

[MrChromebox]

@MrChromebox Is it not not possible to simply prompt the user to select which they prefer upon install?

I'm not building two firmware images for every device