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)
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.
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.
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.
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.)
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.
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.
Hi folks,
I’m on an AMD|16"|Win11 configuration, I’d rather not mess with Secure Boot, and I want to set the battery’s charge limit from the OS. If my re-reading of this thread is correct, I should be able to set charge limits via @TomsonTom 's WinRing0 branch of @DHowett ectool build, at PR1
Is something holding back the merge of that PR? There haven’t been commits since it was opened some months ago, but it’s also not merged yet. I have limited experience with C++ projects, so I’d rather just download an artifact from GitLab than try to CMake the branch myself 
Hi, thank you for your interest! I think it was never merged because @DHowett is busy and there didn’t seem to be that much interest from the community. A few people liked it and probably built it themselves. I suggest that you try to build it, it’s really not that hard and my pull request also contains a tutorial on how to run the WinRing0 version.
So a quick update from vanilla debian land here…
Latest coreboot just landed in unstable, which brings us up to speed with that upstream at least. It doesn’t give me all the goodies like chargecontrol here, as that still seems to be specific to the fork and not available in upstream coreboot code (which, frankly, is kind of unfortunate).
There is, however, more drivers in the kernel itself. The module mentioned in Exploring the Embedded Controller - #158 by DHowett (cros_ec_lpcs.ko) is available, and I think that brings me LED controls? It’s not exactly clear to me what this module does because the source code actually talks about keyboard control, so I’m not sure what that thing does (nor why I need to load it manually):
modprobe cros_ec_lpcs
Anyways, something in newer kernels brings with it a bunch of LED controls:
/sys/class/leds/chromeos::kbd_backlight
/sys/class/leds/chromeos:multicolor:left
/sys/class/leds/chromeos:multicolor:power
/sys/class/leds/chromeos:multicolor:right
so that’s cool. I can, for example, make my power button green with:
echo 0 255 0 0 0 0 | sudo tee /sys/class/leds/chromeos\:multicolor\:power/multi_intensity
The multi_index file shows what the various digits are used for:
$ cat /sys/class/leds/chromeos\:multicolor\:power/multi_index
red green blue yellow white amber
There’s also a cros_charge-control module, and apparently it’s supposed to work with the latest framework laptops, but attempts at adding support for it in TLP seems to have failed:
I can also confirm that I don’t see the /sys/class/power_supply/BAT1/charge_control_end_threshold file here, after loading the module.
So that’s what I got: LED control works, which is cool, although I’d like to have better control over how the EC changes the LED colors when charging. Specifically: i’d like a better “rainbow”, ie:
right now, it seems we only do amber and white.
And, of course, i’d like to be able to control the charge limit. Ideally, I’d switch it to 100% when i’m undocked or have some way to trigger that more easily.
Any tips?