You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fn Lock state not readable/queryable – blocks GNOME applet/tray indicator #176
The current Fn Lock state (toggled via Fn + Esc to make F1–F12 the default on the top row) is not readable or queryable from the operating system. This is handled entirely internally by the Embedded Controller (EC) firmware, with no exposure via:
EC host commands (e.g., ectool/framework_tool raw queries)
HID reports or standard input events
Sysfs/debugfs attributes (via cros_ec drivers)
Any other documented interface
As a result, it's impossible to implement a reliable software indicator (e.g., GNOME Shell extension, tray applet, status bar icon, or notification area emulation) showing the current mode (F-keys first vs. media/special functions first).
Users often resort to manual testing (pressing F5/F7/F8 to check behavior) or hardware LED wishes, but software exposure would enable clean OS-level indicators.
Affected Hardware / Scope
All Framework Laptop models (explicitly tested on Framework Laptop 13 AMD Ryzen AI 300 Series)
BIOS/EC Firmware: 0.0.3.5
Applies across OSes (Ubuntu 24.04 LTS, Windows, etc.), but particularly impacts desktop environments like GNOME/KDE on Linux.
Proposed Solution
Expose the Fn Lock state (read-only is sufficient; write-optional for software toggling) via:
A new EC host command (queryable via framework_tool or ectool)
HID report extension (ideal for standard integration, like Caps/Num Lock LEDs)
Or cros_ec driver sysfs attribute
This would allow community extensions to poll the state and display a simple icon (e.g., lock symbol or "Fn" indicator) in the panel/quick settings.
Why This Matters
No visual feedback beyond manual key testing, which is inconvenient after boot, suspend, or rare EC resets (e.g., full battery drain).
Blocks useful QoL tools for developers/power users who prefer F-keys by default.
Aligns with open-source ethos: enables community-driven indicators without needing hardware changes.
Thanks for reviewing—happy to test any prototype firmware or provide more details!
For anyone who needs an indicator now: FrameworkComputer/EmbeddedController#87 adds an opt-in EC build option, CONFIG_PLATFORM_EC_FRAMEWORK_FNLOCK_CAPS_LED, that shows Fn lock on the Caps Lock key's LED.
It's a firmware workaround and doesn't resolve this issue. The OS still can't read the state, so it won't help a GNOME/KDE applet. If you enable it, Caps Lock has no indicator.
I've tested it on a Framework Laptop 13 Pro (Intel Core Ultra Series 3, sakura): Fn+Esc toggles the LED, the LED blanks with the lid closed and in suspend, and the state survives a reboot. It's untested on other boards. The same PR also fixes a bug where auto keyboard backlight isn't restored on boot while Fn lock is on.
Flashing a self-built EC means writing the RO region, which has no software fallback. Dump your stock flash before trying it.
Activity
AlexTu2 commentedon Sep 11, 2026
For anyone who needs an indicator now: FrameworkComputer/EmbeddedController#87 adds an opt-in EC build option,
CONFIG_PLATFORM_EC_FRAMEWORK_FNLOCK_CAPS_LED, that shows Fn lock on the Caps Lock key's LED.It's a firmware workaround and doesn't resolve this issue. The OS still can't read the state, so it won't help a GNOME/KDE applet. If you enable it, Caps Lock has no indicator.
I've tested it on a Framework Laptop 13 Pro (Intel Core Ultra Series 3, sakura): Fn+Esc toggles the LED, the LED blanks with the lid closed and in suspend, and the state survives a reboot. It's untested on other boards. The same PR also fixes a bug where auto keyboard backlight isn't restored on boot while Fn lock is on.
Flashing a self-built EC means writing the RO region, which has no software fallback. Dump your stock flash before trying it.