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

[Rémi Bernon]

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).
-- 
Rémi Bernon <rbernon at codeweavers.com>