On 07/08/2015 04:20 PM, Vincent Povirk wrote:
I looked into this earlier. Devices like /dev/input/js0 and /dev/js0 are an abstraction and do not provide direct access to HID report descriptor or reports (which may not even exist, depending on the type of joystick).
I couldn't find anything about raw HID report [descriptors] in evdev either.
The point you make about the reports/descriptors not existing has me confused: Which parts of the puzzle are USB HID specific, and which parts are not? It looks like HIDClass speaks in terms of USB HID, but is not necessarily USB HID specific? In the same way, one could work with any input device as though it spoke USB HID, as Aric describes in his follow-up (quoted below). Is this correct?
On 07/09/2015 07:04 AM, Aric Stewart wrote:
For a normal windows minidriver you would have to build your own USB HID Report Descriptor and use it. That means hand building the Descriptor and then having hidclass parse that structure to generate the preparse data.
I have added two new ioctls that are WINE specific to end run around that process. That would allow a wine specific minidriver to be able to built its own preparse data directly and pass it into hidclass. Makes things a bit easier.
You would still end up building the reports by hand. But if you have a preparse data, then we can implement all the HidP_ parts around setting values into reports and you can use them to create the report and send them up.
Thinking about enumeration has me confused as well. I was thinking RawInput was operating "below" (or sibling to) hid.dll, meaning GetRawInputDeviceList and such needed to enumerate devices on buses (USB or otherwise) on its own. Is it in fact some other way, and RawInput uses (or could use) hid.dll to enumerate HID devices from its registered minidrivers?
On 07/08/2015 04:20 PM, Vincent Povirk wrote:
Devices like /dev/hidraw0 or /dev/hiddev0 do provide this access, however on a default Ubuntu setup non-root users do not have permission to access these devices.
So we're throwing these (hiddev/hidraw) out then and instead going to prefer custom minidrivers per available input source/system? I'm wondering how many of these input sources we'd support (evdev, joydev (old and new), hiddev/hidraw, usbfs, ...), which I think would depend on how wide each source's support for real hardware is. I'm guessing some of these sources work-around buggy hardware already (e.g. reporting axes as relative when they should be absolute, etc.), and that may conflict with any work-arounds in HIDClass client code?
I guess the question is... are we planning to emulate these input APIs with a fixed (or somehow dynamic) feature-set (via translation from host-attached devices), or expose them un-touched so the clients interact with "real" devices just like they would on Windows?
Apologies for the verbosity of my post... I have a lot of questions.
-- Nate