Exploring the Embedded Controller

One tiny mistake I made: it’s wFF not W255 … I don’t know why I assumed decimal number format.

So the actual command to remap the Caps-lock key to fn is:
ectool raw 0x3E0C d1,d1,b4,b4,w255
(and to reverse it: ectool raw 0x3E0C d1,d1,b4,b4,w58 back to normal)

3 Likes

in Fedora 41, kernel 6.11 the keyboard backlight brightness is exposed through /sys/class/leds/chromeos::kbd_backlight/brightness and can be changed with the command

echo 40 > /sys/class/leds/chromeos::kbd_backlight/brightness

This example will set the brightness of the keyboard backlight at 40%

It is also visible in and can be changed with Gnome settings.
Screenshot From 2024-11-08 12-35-16

But in contrast to my Thinkpad, no osd (on screen display indicator) appears when changing the keyboard backlight with the keyboard (fn + space). And, after changing the keyboard brightness with these keys, it does no longer correspond with Gnome settings.

Can someone tell me what is needed to fix this, how to enable the osd when changing the keyboard backlight with the fn+space keys.

Thanks a lot.

meijero

Unfortunately the EC does not emit notifications when the keys are pressed.
So the driver can not notify gnome.

Perhaps a potential solution is for the Gnome app to periodically poll the EC /sys/class/leds/... for the current state while the app is open. Maybe once per second.

I am not familiar with what is available in the EC API/ABI or Gnome programming but it may be a direction to investigate.

If you close and re-open the Gnome settings app does it show the current state as set by the keyboard input? That may show that the app looks at the settings when started. If it stays out of sync then it may indicate that the app sets but never looks at the state for the keyboard backlight.

However, the value in /sys/class/leds/chromeos::kbd_backlight/brightness
is changed when pressing fn+space. Can this change not be used to trigger a notification? Or is it perhaps possible to modify the EC firmware? (I am not a developer, I am only a Linux user.)

No. The kernel only reads this from the EC when triggered by userspace.
Gnome could/should reread it before evaluating its own hotkeys.
This will not fix the UI but make the gnome shortcuts usable.

1 Like

For my understanding, I use Linux only, but is there an osd in Windows when fn+space are pressed?

No idea, I only use Linux, too.

But I specifically looked for an notification mechanism in the EC and didn’t find anything.
So I doubt Windows can provide this.

The EC handling Fn+Space is a Framework specific addition to the EC. On real Chromebooks this seems to be all handled in the OS, so no notification is necessary in the first place.

I have a patch for this here (only for azalea/Ryzen 7040 series, but should be relatively easy to adapt): azalea: forward keyboard brightness hotkey to OS · leo60228/EmbeddedController@0053830 · GitHub

I considered sending a PR upstream, but decided that the OSD popup was not worth the regression in functionality when in the firmware menu/etc.

1 Like

The .most compatible mechanism would be a new key code that notifies the OS that something has changed and it can then reread the value from sysfs.

I think this would require a mode change. Where an OS that supports handling keyboard brightness switches the mode of the EC. Then it should forward the fn+keypress instead of capturing it and handling it in the EC autonomously.
Reset this mode on boot.
Would be interesting if that is what other manufacturers do. That or they’d need a separate channel for the events. Because my Dell notebooks can still change the keyboard backlight via keyboard if the OS is not handling it…

A mode mechanism seems very complex and hard to reason about. A notification mechanism is much better.

If the channel for EC initiated communications already exists, yes.

Hey, I posted a PR for this 2 days ago! Emit HID event when keyboard brightness changed via fn+space by Jules-Bertholet · Pull Request #53 · FrameworkComputer/EmbeddedController · GitHub

(Unlike @vriska’s patch, this should not regress behavior when no OS is loaded.)

1 Like

This is not strictly a notification.
It triggers the DE to set the backlight again,
making it slightly inefficient.
But I think I like it very much.

1 Like

Thank you very much for making a patch. If this patch has been tested and works, is it possible for me to try it out? I am not a developer, and do not own a chrome book. A chrome book is required to compile the source code I understand.

Can you give e.g., a link to instructions and binaries so that I can use your solution? I will appreciate that.

Kind regards, Otto1.