Add gamepad HID support following Linux 7.1 hid-input.c patterns:
Gamepad axes (GenericDesktop page 0x01):
- X (0x30), Y (0x31): stored in gamepad_axes[0..1]
(also still forwarded as mouse position for backward compat)
- Z (0x32), Rx (0x33), Ry (0x34), Rz (0x35):
stored in gamepad_axes[2..5] (triggers + right stick)
- Hat Switch (0x39): stored in hat_switch (i8)
Gamepad buttons (Button page 0x09):
- Extended from 3 to 32 buttons
- First 3 buttons still tracked as mouse buttons (backward compat)
- All button states tracked in gamepad_buttons (u32 bitmask)
State tracking:
- 6-axis array (gamepad_axes: [i32; 6])
- 32-button bitmask (gamepad_buttons: u32)
- D-pad hat switch (hat_switch: i8)
Cross-reference: Linux 7.1
- drivers/hid/hid-input.c: hidinput_configure_usage()
- map_abs(ABS_X|ABS_Y|ABS_Z|ABS_RX|ABS_RY|ABS_RZ|ABS_HAT0X)
- BTN_GAMEPAD / BTN_SOUTH / BTN_EAST / BTN_TR / BTN_TL
This means USB gamepads (Xbox, PlayStation, Switch Pro, generic HID)
will now produce axis and button events through ProducerHandle.
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