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@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?