Conversation
The TUF `kbd_rgb_state` interface takes five values: cmd, boot, awake, sleep and the shutdown state occupying the fifth slot. That fifth byte was hardcoded to 1 and the configured value was dropped, so every write re-enabled the shutdown LED state on the EC - and because the write carries the save bit, the user's configuration was overridden in non-volatile EC state on every boot. Measured on a TUF Gaming A15 FA507NV (BIOS 318): writing `1 0 1 0 0` vs `1 0 1 0 1` differs only in bit 7 of the state flags (arg0 0x000804BD vs 0x008804BD for DEVS(0x00100057)). With the bit set, the EC lights the keyboard with its power-on default colour (white) while the S5 power-off sequence runs; with it clear the LED stays dark. The same bit position is named `shutdown` by `new_to_byte()` for the 2021+ keyboards, and rog-control-center already exposes the matching toggle for TUF laptops, so pass the configured value through instead of forcing it on. Machines that never touched the setting are unaffected: `AuraPowerState::default()` keeps `shutdown` enabled.
`AuraPowerState.shutdown` is honoured by the TUF interface now, and the TUF state set consists of four states, not three.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (2)
🔇 Additional comments (1)
📝 SummarySummary by CodeRabbit
WalkthroughThe TUF power encoding now sends the configured shutdown bit instead of always sending ChangesTUF shutdown encoding
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Low Suggested labels: Suggested reviewers: Merge Risk: ⚪ Minimal · up to The PR correctly makes TUF shutdown behavior configurable without changing the existing default, so no current merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
This may need some changes to the asusctl cli as well? Can you pls check that. In the meantime I'll see if I can get a friend with an older TUF to test this patch. You can write here any specific paths you want anyone seeing this to test |
echo "1 0 1 0 0" | sudo tee /sys/class/leds/asus::kbd_backlight/kbd_rgb_stateBefore entering this laptop, when you shut down the computer: if the LED is off, it turns on and a white LED lights up. If the LED is on but in a color other than white (e.g. red), it slowly fades out and then turns on (this doesn't happen on Windows). When you turn the laptop on, it's as if the keyboard backlight calibrates itself, lighting up all colors in 3 different intensity ranges. After the calibration finishes, it switches to the settings you previously configured. Although I couldn't figure out the exact cause of the issue, setting this to 0 (the 5th flag) fixes the problem. The same parameter exists for ROG devices (a bit below the part I changed) but Luke didn't add it for TUFs (he had said by guessing that it should be sorry for the PR description, I was in a hurry, it was entirely written by an llm |
|
To test this, you'll need to rebuild asusd and use the patched one instead of the original asusd. So far I've only tested it with simple commands. Since it's hardcoded as 1, even if you toggle the shutdown parameter from the cli or rogcc, it doesn't take effect. |
|
TLDR: works Machine info: Asusctl 6.4: Asusctl 6.5 master: Asus 6.5 with pr: Other issue but likely unrelated: |
@Rashnan I think I'm having the same issue. Did this happen when you first turn on the laptop, or after waking from sleep (opening the laptop lid)? To avoid cluttering the PR, could I ask you to write in the Discord server or open an issue on GitHub for this? |
When first turn on (after opening after every shutdown) and not on wake from sleep. |
3 participants
Description
AuraPowerState.shutdownis silently dropped for TUF laptops:tuf_to_bytes()hardcodes the fifthkbd_rgb_statebyte to1, so asusd always writes the shutdown LED state as enabled and whatever the user configured is ignored. Since that write carries the save bit, the forced value is stored in non-volatile EC state on every daemon start and the configuration can never win.The fifth byte of the TUF interface gates the keyboard LED during the S5 / power-off sequence. Measured on a TUF Gaming A15 FA507NV (BIOS 318, writing to
/sys/class/leds/asus::kbd_backlight/kbd_rgb_state):1 0 1 0 1-> arg00x008804BDforDEVS(0x00100057): the EC lights the keyboard with its power-on default colour (white) while power drops.1 0 1 0 0-> arg00x000804BD: the LED stays dark through the power-off sequence.Only bit 7 of the state flags differs between the two writes. The same bit position is named
shutdowninAuraPowerState::new_to_byte()for the 2021+ keyboards,rog-control-centeralready exposes the matching toggle, andasusctl aura power-tufalready sendsshutdown: falseon the D-Bus call - only the TUF byte packing threw the value away. Pass the configured value through instead of forcing it on.Machines that never touched the setting keep the previous behaviour:
AuraPowerState::default()hasshutdownenabled.Tested Hardware & Environment
Verification and testing:
cargo fmt --all -- --check)cargo clippy --all -- -D warnings/cargo check --all-targets)cargo test --all)cargo cranky)Additional hardware checks performed on the FA507NV:
check_tuf_control_bytescovers bothshutdown: false->[1, 0, 1, 0, 0]andshutdown: true->[1, 0, 1, 0, 1]forLaptopKeyboardTuf.poweroff; with it set the EC runs its white power-off animation.AuraPowerState::default()keeps the bit set, so the new code path is byte-identical for anyone who did not change the setting.