Adding RID_TYPEHID RawInput support to user32

[Vincent Povirk]

>> 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?

Xbox controllers, for example, are USB devices but communicate using a
nonstandard protocol rather than USB HID. The Linux driver creates an
evdev device for them, and this process does not involve HID at all.

However, we can make up our own HID reports/descriptors based on the
evdev device.

I haven't tested, but I don't think xbox controllers go through
HIDClass on Windows. My understanding is that not all controllers
necessarily do. I think Aric has decided (and I agree) that we should
use HIDClass for all controllers because it simplifies things.

> 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?

At least based on the work Aric's been doing, all hid.dll does is
communicate with hidclass.sys through ioctls and work with the type of
data hidclass.sys uses. Maybe user32.dll on Windows communicates with
hidclass.sys independently, but we don't care about this, and in order
to be a truly independent implementation, we'd prefer not to know.

We only care about what we need to provide to applications for
compatibility with the Windows API. If we can implement RawInput API's
for controllers in user32 by going through hid.dll, we should probably
do that because it's a cleaner design.

>> 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 suspect that we will eventually want to support hiddev at least, for
specialized devices like the Oculus Rift. I don't think hiddev or
hidraw will ever be useful for game controllers, though.

I don't know if there's a reason to support joydev if we have evdev.

> 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?

That's still an open question, I think.

On Linux, the default permissions for joystick devices force us to use
evdev/joydev which prevents us from letting Windows programs see the
real devices.

However, HID devices that are not joysticks, mice, or keyboards will
probably require direct access from Windows programs to function
correctly.

I'm also unsure how XInput layout remapping, if we have it, will work.
That is, Xbox controllers on Windows provide a very specific button
and axis configuration, which is different from what we're likely to
get from controllers that we'd want to access through XInput
(including, from what I've heard, what the Linux drivers give us for
Xbox controllers), and we'll have to remap them. Some programs use
DInput but expect the XInput layout, so we should remap things for
DInput as well. I think that remapping should happen inside
hidclass.sys, but I'm not sure if it can be done cleanly.