Add Caps Lock, Num Lock, and Scroll Lock LED synchronization
following Linux 7.1 hid-input.c: hidinput_output_event().
Led state tracking:
- Caps Lock (usage 0x39) → toggles bit 1
- Scroll Lock (usage 0x47) → toggles bit 2
- Num Lock (usage 0x53) → toggles bit 0
SET_REPORT (Output) via XhciClientHandle::device_request():
- PortReqTy::Class, PortReqRecipient::Interface
- bRequest = 0x09 (SET_REPORT)
- wValue = (0x02 << 8) | 0x00 (Output report type, report ID 0)
- wIndex = interface_num
- Data = 1-byte LED state
The SET_REPORT is sent only when the LED state changes (tracked
with last_led_state sentinel). A failed SET_REPORT is logged at
warn level but does not block the input loop.
Cross-reference: Linux 7.1
- drivers/hid/hid-input.c: hidinput_output_event()
- drivers/hid/usbhid/hid-core.c: usbhid_output_report()
- HID 1.11 spec §7.2.1: SET_REPORT request
This means USB keyboards with Caps/Num/Scroll Lock LEDs will now
have their LEDs synchronized with the host lock state.
Both daemons previously produced no Info-level output on successful start,
making it impossible to confirm from the boot log whether ps2d and inputd
were actually alive. The kernel serial log shows no [INFO] ps2d: or [INFO]
inputd: lines during normal boot, leading operators to assume the input
stack was dead when in fact it was working.
This adds two log::info!() calls:
- ps2d main.rs: after daemon.ready(), log that ps2d has registered
its ProducerHandle and is listening on serio/0 (keyboard) and
serio/1 (mouse).
- inputd main.rs: after setup_logging, log that inputd has registered
scheme:input and is waiting for handles.
These are emitted only on the successful startup path; existing
.error!()/.warn!() calls continue to surface real failures. No behavior
change; no functional effect on input handling.
Red Bear OS