Adding RID_TYPEHID RawInput support to user32

[Nathan Schulte]

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