On 8/18/21 11:50 AM, Rémi Bernon wrote:
On 8/18/21 5:52 PM, Zebediah Figura (she/her) wrote:
I have a few questions:
- How will dinput (or winmm) expose these devices?
For dinput, it should enumerate the HID device interface class, so for XInput compatible devices, it will enumerate the bogus "&IG_" devices, in addition to non-XInput compatible devices. Applications are expected to check this marker to de-duplicate the XInput gamepads, as described in [1].
I don't know about winmm, but if it can be implemented on top of HID then it'll be the same.
Both will then be limited by the XInput bogus HID support, like on Windows. And they won't have force-feedback support for them for instance (although XInput, using the internal device, will have it).
We could decide to overcome that limitation by enumerating the XINPUT device interface class, but I don't think it's how it's supposed to work.
- How will we expose composite vs. non-composite devices from winebus?
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.)
Actually, I think I'm missing even more basic context. Is xinput exposing HID devices? Where does hidclass fit in for xinput-compatible gamepads?
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.