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.