fwk: keyboard: opt-in Fn-lock indicator on Caps Lock LED; fix lost auto backlight

[AlexTu2]

The EC never tells the host whether Fn lock (Fn+Esc) is on: there's no host command and no HID report for it (see FrameworkComputer/SoftwareFirmwareIssueTracker#176). So you can't tell which state the top row is in without pressing a key. This PR adds an opt-in build option that shows Fn lock on the Caps Lock key's LED. It also fixes a bug in the same file that bites anyone who leaves Fn lock on.

Two commits, so the fix can be taken without the feature:

1. Restore auto backlight when Fn lock is set. board_kblight_init() compares the BBRAM byte to KEYBOARD_BL_BRIGHTNESS_AUTO (101) without masking off KB_FN_LOCKED (bit 7). With Fn lock on, the stored value is 229, the compare never matches, and auto keyboard backlight is lost on every boot. The fix masks the byte before comparing.
2. CONFIG_PLATFORM_EC_FRAMEWORK_FNLOCK_CAPS_LED (default n, depends on PLATFORM_EC_FRAMEWORK_LAPTOP_13). When it's enabled, gpio_cap_led follows Fn_key & FN_LOCKED instead of Caps Lock. It keeps the existing lid/S0 blanking in keyboard_caps_led_update(), and Caps Lock gets no indicator. When it's off, LED behaviour is unchanged. Separately from the option, the Fn-lock flag is now written to BBRAM on every toggle, not only in fnkey_shutdown().

To enable it on a board, add this to its project.conf:

CONFIG_PLATFORM_EC_FRAMEWORK_FNLOCK_CAPS_LED=y

Testing

On a Framework Laptop 13 Pro (sakura), with the option enabled. That build is byte-identical to the image flashed for these tests.

• Fn+Esc toggles the LED
• the LED goes dark with the lid closed and comes back when it is opened
• the LED is dark in suspend and comes back on wake
• Fn lock and the LED state are restored after a reboot
• with Fn lock on and backlight set to auto, auto is retained across a reboot (commit 1)

Builds with the option off: sakura, azalea, marigold.

Not tested: restoring the Fn-lock flag after an unclean power loss; the option-off configuration on hardware; any hardware other than sakura.

Notes

• Boot-time restore comes from HOOK_CHIPSET_RESUME, not fnkey_startup(). HOOK_CHIPSET_STARTUP fires while power_get_state() is still POWER_S5S3, and the blanking rejects that state. There's a comment in the code about this.
• Related: Report fn key and lock states via HID  #55 reports Fn and Fn-lock state over HID, which lets the OS read the state instead of showing it on an LED.
• For anyone building this from the fork: flake.nix points zephyr at ssh://git@github.com/FrameworkComputer/zephyr-ec, which isn't reachable from outside. The pinned revision 8bdbcbb is public as FrameworkComputer/zephyr branch fwk-sakura-20260429. On sakura the EC runs its RO copy, so flashing needs framework_tool --flash-ec --force (RO+RW), and RO has no software fallback. Dump your stock flash first.

---

Cherry-pick status (the template lists fwk-main, which doesn't exist; this PR targets fwk-sakura-20260429):

Branch	PR
fwk-sakura-20260429	This PR
fwk-marigold-22606	Not needed (file not present at this path)
fwk-hx20-hx30-4410	Not checked
fwk-lotus-azalea-19573	Not checked
fwk-sunflower-26784	Not checked
fwk-dogwood-27111	Not checked
fwk-lilac-27116	Not checked
fwk-tulip-29169	Not checked

🤖 Generated with Claude Code

https://claude.ai/code/session_014dAnHutxgoW4y9K7DAZomY