On 8/18/21 4:40 PM, Rémi Bernon wrote:
On 8/18/21 11:02 PM, Zebediah Figura (she/her) wrote:
On 8/18/21 11:50 AM, Rémi Bernon wrote:
On 8/18/21 5:52 PM, Zebediah Figura (she/her) wrote: I don't know, is there going to be any?
On winebus.sys I think composite devices are just going to be enumerated on the unix bus level as separate devices, with different "input" numbers. So we should see a "&MI_00", "&MI_01", "&MI_02" winebus.sys device and so on.
If one of those is supposed to be XInput compatible, the xinput.sys driver should match the compatible ID, and take it over instead of winehid.sys, create a corresponding "&IG_00" (or "&IG_01", etc) HID device, and an internal device on the XINPUT\ bus.
I think I need some further clarification, sorry.
By "composite" I rather mean HID devices which comprise a single interface on a composite USB device, as opposed to a HID device which comprises an entire non-composite USB device (or a non-USB device, I guess.)
Well, like I said, I believe the interfaces are exposed by winebus.sys as separate devices.
Actually, I think I'm missing even more basic context. Is xinput exposing HID devices? Where does hidclass fit in for xinput-compatible gamepads?
It exposes the xinput PDO as the same kind of device as winebus.sys devices, and the internal PDO as well.
Both return a WINEBUS\WINE_COMP_HID compatible ID, so winehid.sys will match and handle both.
Then winehid.sys registers with hidclass.sys as usual, which creates the corresponding FDO and PDO, and starts a device thread for each.
However, the internal PDO created from xinput.sys is only an HID device for convenience, and it should not be enumerated as the other HID devices.
So in order to do that, xinput.sys returns a XINPUT\ prefixed device ID for this PDO only, and hidclass.sys knows that it needs to register its HID PDO on the XINPUT device interface class (first 3 hunks of PATCH 4).
As far as I can tell your xinput.sys is attaching to winebus, and it isn't actually exposing any HID devices. It's just exposing the "internal" HID device for xinput, but it's breaking anything else. I.e. it creates a device named e.g. HIDRAW\VID_####&PID_####&IG_##, but it doesn't actually register any interfaces for the device, or handle HID ioctls.
It's working surprisingly very well then ;) (and I made sure it worked on every single patch).
The internal PDO is mostly just a pass-through, and the HID ioctls are still handled by the underlying winebus.sys device.
It has to intercept the read requests through, so we can translate them and complete the corresponding xinput PDO read requests (which doesn't pass them through).
(This description is valid for after PATCH 4, where the internal PDO is created, before it the xinput PDO acts as the pass-through device).
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?
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?