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

[Zebediah Figura (she/her)]

On 8/18/21 2:31 AM, Rémi Bernon wrote:
> And match it in winehid.sys instead of individual bus ids.
> 
> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
> ---
> 
> This series should apply smoothly with the previous winebus.sys. I'm
> also sending it now because it may need a bit more consideration. The
> rationale of the design is described below:
> 
> 
> The idea here is to create a new xinput.sys driver, which will match
> xinput-compatible winebus.sys devices, and create two device nodes on
> top of the underlying device.
> 
> The first one will be the public "&IG_00" XInput bogus HID gamepad, as
> native has, and as Win32 SDL expects to see.
> 
> The other will be a pass-through to the underlying device, but although
> it's going to be an HID compatible device too, it will need to be
> exposed on a different interface class GUID in order to be used only
> by Wine XInput.
> 
> The second node will filter its read requests, and then translate them
> into the corresponding bogus XInput HID report, passing them to the
> first one for its read request completion.
> 
> This design removes the need to really care about XInput gamepad compat
> in winebus.sys, making it possible to extend the HID reports there to
> include the full capabilities of the unix devices:
> 
> * It will allow the user-space XInput implementation to have access to
> the full capabilities of the underlying device, and not be limited by
> the bogus HID compatibility anymore.
> 
> * It also removes an eventual need to duplicate the winebus devices, as
> the two nodes will only need one underlying device (the bogus XInput
> node will never actually request reads to its underlying PDO).
> 
> * And finally it makes it possible to have XInput compatibility with any
> underlying device, not just with SDL or evdev where we handle the report
> creation. Even hidraw or iohid device reports can be translated to the
> XInput HID reports.

I have a few questions:

* How will dinput (or winmm) expose these devices?

* How will we expose composite vs. non-composite devices from winebus?

* What potential need is there to duplicate winebus devices that you 
refer to? As far as I understand we don't currently duplicate anything.

* And perhaps more generally: from my time working on Proton, although I 
haven't worked on controller support recently, I vaguely 
understand/remember that some games are very picky about what is and 
isn't reported as an xinput device, and also whether the same device is 
reported via dinput. Would it be possible for you to summarize the 
relevant problems there, so that we have that additional context?

* In this patch specifically, is there any reason to keep the old 
hardware IDs around?