On 8/18/21 11:51 PM, Zebediah Figura (she/her) wrote:
Ah, I see what I was missing. So it's kind of a poor man's filter DO, I guess. That is, it effectively inserts itself into the device stack between winebus and winehid, and exposes the HID interface from winebus directly using an internal GUID, while reporting a different HID descriptor (and report data, etc.) to winehid?
Yes. I quickly looked at filter drivers but didn't find anything explicit and it looked like we don't have the necessary bricks to make it work. And I really don't think it's worth the trouble for something as simple as this driver.
I must still be missing something, though, because if that's the case I don't see why you would need to touch hidclass at all.
I guess the only reason we can't do this all from winehid.sys is because hidclass doesn't let anyone open the device directly, right?
Well I don't know how to tell hidclass.sys not register the device on the HID GUID, and register it instead on another GUID without changing hidclass.sys.
And yes, opening any HID device goes through hidclass.sys and we really want it to be on top and handle all the ugly HID details (and it also guarantees that we will only ever have a single read request at a time, which will be handy).