Adding RID_TYPEHID RawInput support to user32

[Aric Stewart]

On 7/9/15 2:04 PM, Nathan Schulte wrote:
> 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?
> 

So, on windows. HID is not USB specific. Any device can be a HID device. However much of the language HIDClass and HID speak are the USB standard. If you are writing a hid minidriver that is NOT a USB device on windows, then you will still need to build a USB HID Report Descriptor to report up to HIDClass, and when you generate reports those reports are in USB report standards. 


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

I am pretty positive RawInput has to be a client of Hid.dll. Have not investigated but the connection between the two are too close to not be interrelated.  

As for enumeration. hid.dll gives you no method to enumerate. That is all done through setupapi.  Here is a very rough overview:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731%28v=vs.85%29.aspx

I have specific code that does this that I can share later also. 


-aric