[PATCH 1/5] winebus.sys: Report WINEBUS\WINE_COMP_HID compatible id.

[Zebediah Figura (she/her)]

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?