feat(CapabilityMap): add generic hidraw button driver#563
Conversation
pastaq
left a comment
pastaq
left a comment
There was a problem hiding this comment.
Much needed feature, thanks for working on this. I want to discuss a few things, so before you change anything below lets get to a consensus.
pastaq
left a comment
pastaq
left a comment
There was a problem hiding this comment.
Thanks for making those changes. I'll test it this week and verify there are no strange effects in other hid devices.
ShadowApex
left a comment
ShadowApex
left a comment
There was a problem hiding this comment.
Thank you for this change! This is something we have wanted for a while. I left a few short comments, but we should be able to accept this with minimal changes. Thanks again!
| #[serde(skip_serializing_if = "Option::is_none")] | ||
| pub value: Option<u8>, |
There was a problem hiding this comment.
What is the purpose of this field in decoding hidraw data?
| if hidraw.input_type != "button" { | ||
| log::warn!( | ||
| "Unsupported hidraw input_type '{}' in mapping '{}', skipping", | ||
| hidraw.input_type, | ||
| mapping.name, | ||
| ); | ||
| continue; | ||
| } |
There was a problem hiding this comment.
Since this implementation only supports simple button decoding, it would be nice to add a TODO somewhere so we can ensure that we finish implementing decoding other types of input (e.g. axis info, gyro, etc.)
| const READ_BUF_SIZE: usize = 64; | ||
|
|
||
| /// Generic hidraw button source device driven by a capability map. | ||
| pub struct GenericHidrawButtons { |
There was a problem hiding this comment.
Since this will eventually also support non-button input, we should probably call this simply GenericHidraw.
| Err(format!( | ||
| "No driver for hidraw interface found. VID: {vid:#06x}, PID: {pid:#06x}" | ||
| ) | ||
| .into()) |
There was a problem hiding this comment.
It would be good to further specify in the error here that no driver or capability map was found for this device.
3 participants
Summary
Add a generic hidraw button driver that uses capability map YAML configs to define button mappings, following the same pattern as existing evdev capability maps. This removes the need to write per-device Rust driver modules for simple HID button devices.
Includes GPD Win 5 HID button support (new firmware) as the first use case. Supersedes #558, which implements the same functionality with a dedicated driver.
Approach
The existing evdev source already uses a declarative approach — devices like MSI Claw and GPD define button mappings in YAML capability maps without any device-specific Rust code. This PR extends that pattern to hidraw by:
HidrawConfigwith flexible detection modes (non-zero byte, exact value match, specific bit check)HidrawEventTranslatorto translate raw HID reports based on the capability mapDriverType::Unknownbut a hidraw capability map is presentAdding support for a new simple HID button device now only requires a YAML capability map file — no Rust code or recompilation needed.
Test plan