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:
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). |
Beta Was this translation helpful? Give feedback.
-
|
Not so sure if the above is similar to the "Vendor Supplied Upper Level Driver" |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
hidraw was also a very successful design decision. It enabled:
That flexibility remains valuable.
However, many modern HID devices now behave less like simple peripherals and more like embedded systems. Current devices often combine:
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:
This becomes increasingly awkward for:
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/rawThe goal is NOT:
hidraw would remain:
The proposal is instead asking whether modern HID ecosystems are beginning to benefit from:
Linux already uses similar separation models elsewhere:
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 ·
Beta Was this translation helpful? Give feedback.
All reactions