-
Notifications
You must be signed in to change notification settings - Fork 474
I recently bought another modern high-end keyboard and once again ran into the growing mismatch between modern HID-class peripherals and the assumptions the original Linux HID stack was designed around.
The original HID model worked extremely well for decades because most devices were simple:
- keyboards
- mice
- gamepads
- low-bandwidth input devices
hidraw was also a very successful design decision. It enabled:
- vendor experimentation
- rapid device support
- userspace protocol handling
- reverse engineering
- avoiding giant vendor-specific kernel drivers
That flexibility remains valuable.
However, many modern HID devices now behave less like simple peripherals and more like embedded systems. Current devices often combine:
- firmware management
- RGB streaming
- telemetry
- browser/WebHID access
- runtime configuration
- macro systems
- wireless pairing
- analog key telemetry
- vendor RPC protocols
All of these workloads are frequently multiplexed through a single hidraw interface.
The problem is not vendor semantics. Linux already handles generic HID transport and parsing extremely well.
The growing pressure point appears to be capability separation.
Today, very different workloads often share:
- one file descriptor
- one permission model
- one report stream
- one opaque transport channel
This becomes increasingly awkward for:
- sandboxing
- firmware safety
- browser mediation
- multi-client coexistence
- userspace arbitration
- lifecycle isolation
- observability
- security boundaries
The core idea of this RFC is intentionally narrow:
Should Linux eventually expose optional capability-oriented HID access planes alongside existing hidraw interfaces?
Very rough conceptual examples:
/dev/hid/0/ctl/dev/hid/0/aio/dev/hid/0/fw/dev/hid/0/telemetry/dev/hid/0/observe/dev/hid/0/raw
The goal is NOT:
- replacing hidraw
- replacing evdev
- standardizing vendor behavior
- moving policy into the kernel
- forcing migration away from existing tooling
hidraw would remain:
- valid
- flexible
- backwards-compatible
- and available as the unrestricted escape hatch
The proposal is instead asking whether modern HID ecosystems are beginning to benefit from:
- capability factoring
- lifecycle separation
- transport mediation boundaries
- and structured multi-client access
Linux already uses similar separation models elsewhere:
- DRM/KMS
- VFIO
- io_uring
- AF_XDP
- NVMe admin vs I/O queues
HID-BPF also appears highly relevant here and may already provide part of the evolutionary path.
This is mainly intended as a discussion starter around long-term HID architecture pressure, not a request for giant subsystem redesigns.
If it takes, I will take it to the linux-input mailing group.
1 vote ·
All reactions
Replies: 2 comments 2 replies
Thatks for reaching out.
I see your points, and lets start with the most important one. This is HIDAPI library and developers/community around it are mostly users of a it, which is a cross-platform thin abstraction around HID devices available via OS API (I'd call libusb backend an exceptino here, but that's not the point). None of us have direct relation to hidraw implementatoin in linux kernel nor abstractions around it.
Even if there was something like that - it would be unusable by this library, unless it is available/usable by a majority of other platforms (Windows/macOS/bsd/etc.).
My personal opinion: the "capability-oriented HID" would require one of:
- vendor-specific knowledge about these device capabilities inside the kernel (which kind-of defeats the ideologi of HID in a first place)
- some kind of new standard that device manufactures should follow (which I highly doubt)
What you conceptually want - already possible by vendor implementation, e.g. vendor may define different usb interfaces with different HID devices on it for specific purposes (and they don't do it for obvious reasons).
It is also possible to make a user-space driver with libusb backend (so the original device is no longer accessible by hidraw/other clients) and expose each "capability devie" by a new abstraction, yet to be introduced. Again this requies vendor-specific knowledge about each specific device (and often even about the FW versions of the same device).
All reactions
-
👍 1
Not so sure if the above is similar to the "Vendor Supplied Upper Level Driver"
https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/hid-client-drivers
zzhgdrs
All reactions
I wouldn't say so. What you shown here is how Windows can expose some non-standard-compliant device as a HID device thru a dedicated Windows driver.
What author suggests above - is to have another layer of abstraction on top of HID device, wrap with permissions, etc., and use HID more like a transport for it.
All reactions
Actually the lower mini-driver has the function you mentioned, "expose some non-standard-compliant device as a HID device", or do more.
The upper level driver (above hidclass.sys) can do the things the OP wants to do.
Some of the things can be done using application (using hid.dll), like HIDAPI.