XInput: Comments on core and further steps
Hi, I just published a patch with my xinput core implementation. If anyone is interested in an evdev (linux) backend I could publish that too, but I guess it won't make it into wine due to the tendency towards the HID architecture. A rough overview on how it's supposed to be used can be read in the README file from the second patch. Let me know what you think. The next step would be to implement a backend that uses hid.dll. Using HID devices should be fairly straightforward. There are, however, two parts that I haven't figured out yet: - How can we find new devices? The current work for the HID architecture seems to have tackled the hotplugging problem. Can the XInput HID backend get notified when a new controller gets plugged in? Should it just poll for new devices using SetupDi functions or something similar? - How do we map a controller's buttons and axes to the corresponding XInput ones? This has to be done per controller model. My evdev backend has a lookup list that matches controllers to a certain mapping using some selection criteria (Name, Vendor ID, etc.). My idea was to load the mappings from the registry, but for this to be usable by regular users, a GUI would have to be implemented to create those registry entries. Any ideas are welcome. Juan
I'll CC Aric to this thread. Cheers, Aaryaman On Sun, Feb 14, 2016 at 6:52 PM, Juan Jose Gonzalez <juanj.gh(a)gmail.com> wrote:
Hi,
I just published a patch with my xinput core implementation. If anyone is interested in an evdev (linux) backend I could publish that too, but I guess it won't make it into wine due to the tendency towards the HID architecture.
A rough overview on how it's supposed to be used can be read in the README file from the second patch. Let me know what you think.
The next step would be to implement a backend that uses hid.dll. Using HID devices should be fairly straightforward. There are, however, two parts that I haven't figured out yet:
- How can we find new devices? The current work for the HID architecture seems to have tackled the hotplugging problem. Can the XInput HID backend get notified when a new controller gets plugged in? Should it just poll for new devices using SetupDi functions or something similar?
- How do we map a controller's buttons and axes to the corresponding XInput ones? This has to be done per controller model. My evdev backend has a lookup list that matches controllers to a certain mapping using some selection criteria (Name, Vendor ID, etc.). My idea was to load the mappings from the registry, but for this to be usable by regular users, a GUI would have to be implemented to create those registry entries.
Any ideas are welcome.
Juan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-02-14 um 13:22 schrieb Juan Jose Gonzalez:
- How do we map a controller's buttons and axes to the corresponding XInput ones? Is the idea of xinput.dll still to talk to Xbox gamepads only, or did Microsoft change that at some point? If it's Xbox only you have the option to just do the same thing and keep our implementation limited to one piece of hardware. This approach has obvious drawbacks, but it might be easier to get an implementation started this way.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWwLjlAAoJEN0/YqbEcdMwJP4P/i8od4/MtnA5KsCxOLMA7+2q s6EqnhX3i7ZPcNkS/xAPY4gdxx7XNntKVMuV7BY7ojMJuL6JZJ+xlgBARcE+fvqn +IWtP3y10RLOS9Q7zMj+uBJWytd0dsEryblwM0wndM1+F+gnTnmBEHeXCMv9D4EB id9BU/TXjUg0KilbeMr1n4Gm8/Q5y5bYroZ5AekeZUrvN8/ijFhpNiKRA4YvnIy1 oCH6iXdo6ih3LkntquTX2y/NwSFalvfGOtE01XxEezTxa8KI09IjLbAJJnFr3CJf 7Q5WpJSJwLL+KXMy+/ZN2WiTrPF89aoPhoZrMKBTHRlRdzblij9MLcI8FDiHokmX 1coq/ZnOn0hKJrBMeLTDqSH2IZ6Wu0P6+OWmCfx0fhCY1Ntf48BJWz8mso3Vu6DP R8EeC6W4vfe1gvZacjnu5pbejFwiyncc1liBUUJE5NA8vnS91QtPcOz5vsFBjKVU C38XrKdpEnNQ1WEX7H5mjxl4F2iUIRJC868CVGXw+XE+5roiRPQhgEqvwA1YXeOl 4y8avIBJbJ3Ql4qCE5w8d1pb2ovXRaC1y0klTyqx/gzbNBuBzmqZZSZ6d6lVHzc4 ZNbHobteh1j0k8WOosesfwLFp5dLiz47Qqm+IxxVa/Kvr25KpQKelHJh1Aosatb+ GP1acmGANLJA2uNUdhPt =x/z8 -----END PGP SIGNATURE-----
On 02/14/2016 06:27 PM, Stefan Dösinger wrote:
Is the idea of xinput.dll still to talk to Xbox gamepads only, or did Microsoft change that at some point? If it's Xbox only you have the option to just do the same thing and keep our implementation limited to one piece of hardware. This approach has obvious drawbacks, but it might be easier to get an implementation started this way.
No, as far as I know Microsoft didn't change anything, although there are several pieces of software that implement the XInput interface, replacing the xinput dlls, while mapping inputs from HID or other devices. When it comes to drivers, Xbox controllers aren't HID devices, but use their own protocol. Under linux, the evdev interface (ie. standard input interface) for Xbox controllers is implemented via the xpad module in kernel space or the xboxdrv daemon in userspace, *not* the usbhid module. If we were to limit wine's XInput support to Xbox controllers, then the proper way would be to implement something similar to the xboxdrv project (https://github.com/xboxdrv/xboxdrv) as an XInput backend to directly access the controllers. Due to the nature of WINE, I believe that limiting ourselves to Xbox controllers is not acceptable, even if Microsoft's XInput only accepts those. I think we should allow mapping any controller to XInput to improve the usability. Nevertheless, we could start by providing mappings for XBox controllers and other popular controllers and, after that is solid, implement a GUI to allow the user to add additional mappings. This is actually what I've done for the evdev backend (not the GUI part, but the predefined list of mappings for Xbox controllers).
Hi Juan, Awesome thanks for this work. Know I am sure that to get this into wine will require a bit of work so hopefully you are will to go through the process of revisions with us to see things through. On 2/14/16 7:22 AM, Juan Jose Gonzalez wrote:
Hi,
I just published a patch with my xinput core implementation. If anyone is interested in an evdev (linux) backend I could publish that too, but I guess it won't make it into wine due to the tendency towards the HID architecture.
Yeah, we will want to target the HID architecture and I can totally help you on that. I think it should be pretty straight forward. Looking at your back end interface code it all looks really pretty easy. There are parts you have around the mapping that I almost wonder if we want to move into that back end, or maybe a middle layer. I will have to spend more time reading the code before I can come up with anything concrete there.
A rough overview on how it's supposed to be used can be read in the README file from the second patch. Let me know what you think.
The next step would be to implement a backend that uses hid.dll. Using HID devices should be fairly straightforward. There are, however, two parts that I haven't figured out yet:
- How can we find new devices? The current work for the HID architecture seems to have tackled the hotplugging problem. Can the XInput HID backend get notified when a new controller gets plugged in? Should it just poll for new devices using SetupDi functions or something similar?
There are 2 bits here, hotplugging and device detection. They are 2 separate processes. Speaking on device detection, I think the best thing for us to do would be the process of enumerating the devices via setupapi and selecting the appropriate ones, as you have pointed out with the SetupDi functions. I have code that does this for winejoystick.dev implementation of HID that I have been working on, not sent anywhere yet, and it is not a difficult process. I will attach my winejoystick.drv module for inspiration/example but it is clearly not ready to actually be submitted as a patch, if for no other reason that all the supporting HID work is not in place yet. As for hot plugging that will come through plug and play processes that are still on the drawing board. Probably something eventually involving RegisterDeviceNotification once that gets some love.
- How do we map a controller's buttons and axes to the corresponding XInput ones? This has to be done per controller model. My evdev backend has a lookup list that matches controllers to a certain mapping using some selection criteria (Name, Vendor ID, etc.). My idea was to load the mappings from the registry, but for this to be usable by regular users, a GUI would have to be implemented to create those registry entries.
I agree that mapping should be allowed for any appropriate controller and not restricting us to particular vendors. (Microsoft) With HID we get Usages for all our elements. So what we will want to do is probably figure out what usages map to what control elements on an Xbox controller and have that be default mappings. (Here is the HID USB spec for usages http://www.usb.org/developers/hidpage/Hut1_12v2.pdf, windows HID matches these) so if the A button is page 0x9 Usage 0x1 then by default the element of 0x9 0x1 would be the A button. We would then want to be able to have a way to map other controllers. I am sure that existing controller maps exist, it would be nice if we could load/use them. -aric
Hi Aric, thanks for your reply. On 02/15/2016 03:09 AM, Aric Stewart wrote:
Hi Juan,
Awesome thanks for this work. Know I am sure that to get this into wine will require a bit of work so hopefully you are will to go through the process of revisions with us to see things through.
Sure, I was expecting that, and I'll gladly help getting this through. One thing that should help is the fact that, as long as you don't add any backends, the code behaves like the previous stubs, so there's little risk for regressions.
Yeah, we will want to target the HID architecture and I can totally help you on that. I think it should be pretty straight forward. Looking at your back end interface code it all looks really pretty easy. There are parts you have around the mapping that I almost wonder if we want to move into that back end, or maybe a middle layer. I will have to spend more time reading the code before I can come up with anything concrete there. I was thinking of two different stages for mappings. The first one maps whatever devices a backend speaks to to xinput buttons and axes and transforms the values to a common value range. That stage is backend-specific and should be embedded there. This is the type of mapping I was talking about below. The second stage is where the common value ranges are transformed to the value range of the target xinput button or axis. That is common to all backends, which is why I put it in the core. But we could look into moving that out of the core if you think that it doesn't belong there.
A rough overview on how it's supposed to be used can be read in the README file from the second patch. Let me know what you think.
The next step would be to implement a backend that uses hid.dll. Using HID devices should be fairly straightforward. There are, however, two parts that I haven't figured out yet:
- How can we find new devices? The current work for the HID architecture seems to have tackled the hotplugging problem. Can the XInput HID backend get notified when a new controller gets plugged in? Should it just poll for new devices using SetupDi functions or something similar?
There are 2 bits here, hotplugging and device detection. They are 2 separate processes. Speaking on device detection, I think the best thing for us to do would be the process of enumerating the devices via setupapi and selecting the appropriate ones, as you have pointed out with the SetupDi functions. I have code that does this for winejoystick.dev implementation of HID that I have been working on, not sent anywhere yet, and it is not a difficult process. I will attach my winejoystick.drv module for inspiration/example but it is clearly not ready to actually be submitted as a patch, if for no other reason that all the supporting HID work is not in place yet. Thanks for the attachment. In your code you seem to enumerate the available devices only once when you load the driver. XInput does not have any methods to open and close devices, it just provides methods to listen for key events and to poll the state of individial device slots. Therefore, the detection of newly connected controllers must be done by the backend continuously in order to be able to "connect" new slots as soon as devices become available. In the evdev backend I was listening for newly connected input devices, so RegisterDeviceNotification is, as you said, the way to go for the HID backend. Until that is ready, what do you think of running your detection code periodically in a separate thread, for example every 2s? Do you think that would cause a lot of overhead?
As for hot plugging that will come through plug and play processes that are still on the drawing board. Probably something eventually involving RegisterDeviceNotification once that gets some love.
I agree that mapping should be allowed for any appropriate controller and not restricting us to particular vendors. (Microsoft)
With HID we get Usages for all our elements. So what we will want to do is probably figure out what usages map to what control elements on an Xbox controller and have that be default mappings. (Here is the HID USB spec for usages http://www.usb.org/developers/hidpage/Hut1_12v2.pdf, windows HID matches these) so if the A button is page 0x9 Usage 0x1 then by default the element of 0x9 0x1 would be the A button. We would then want to be able to have a way to map other controllers. I am sure that existing controller maps exist, it would be nice if we could load/use them. Xbox controllers aren't HID devices (bInterfaceClass = 0xff, vendor specific), so you probably won't find a HID usage map. We'll have to emulate the descriptors in the corresponding HID minidriver, so we are going to have to define mappings there as well. As a linux user I'd be inclined to use the codes from the uapi/linux/input-event-codes.h header (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/in...), where for example BTN_A is 0x130, as the usages for emulated HID devices. However, I don't know the input interfaces of other OSs, so that may not be the best idea.
Juan
Hi Juan, On 2/15/16 2:37 AM, Juan Jose Gonzalez wrote:
- How can we find new devices? The current work for the HID architecture seems to have tackled the hotplugging problem. Can the XInput HID backend get notified when a new controller gets plugged in? Should it just poll for new devices using SetupDi functions or something similar?
There are 2 bits here, hotplugging and device detection. They are 2 separate processes. Speaking on device detection, I think the best thing for us to do would be the process of enumerating the devices via setupapi and selecting the appropriate ones, as you have pointed out with the SetupDi functions. I have code that does this for winejoystick.dev implementation of HID that I have been working on, not sent anywhere yet, and it is not a difficult process. I will attach my winejoystick.drv module for inspiration/example but it is clearly not ready to actually be submitted as a patch, if for no other reason that all the supporting HID work is not in place yet. Thanks for the attachment. In your code you seem to enumerate the available devices only once when you load the driver. XInput does not have any methods to open and close devices, it just provides methods to listen for key events and to poll the state of individial device slots. Therefore, the detection of newly connected controllers must be done by the backend continuously in order to be able to "connect" new slots as soon as devices become available. In the evdev backend I was listening for newly connected input devices, so RegisterDeviceNotification is, as you said, the way to go for the HID backend. Until that is ready, what do you think of running your detection code periodically in a separate thread, for example every 2s? Do you think that would cause a lot of overhead?
Maybe on DLL initialization? (DllMain) That will catch all the devices that are plugged in at wine startup, just like all the other current gamepad implementations. I don't know if we want to have a detection thread, it just feels messy to me. I am poking at the RegisterDeviceNotification parts, I would love to have more forward progress on the whole of the plug and play architecture before adding more bit to it, but it is an important part to the user level stuff, like this, and so having an idea of how to approach it is good.
As for hot plugging that will come through plug and play processes that are still on the drawing board. Probably something eventually involving RegisterDeviceNotification once that gets some love.
I agree that mapping should be allowed for any appropriate controller and not restricting us to particular vendors. (Microsoft)
With HID we get Usages for all our elements. So what we will want to do is probably figure out what usages map to what control elements on an Xbox controller and have that be default mappings. (Here is the HID USB spec for usages http://www.usb.org/developers/hidpage/Hut1_12v2.pdf, windows HID matches these) so if the A button is page 0x9 Usage 0x1 then by default the element of 0x9 0x1 would be the A button. We would then want to be able to have a way to map other controllers. I am sure that existing controller maps exist, it would be nice if we could load/use them. Xbox controllers aren't HID devices (bInterfaceClass = 0xff, vendor specific), so you probably won't find a HID usage map. We'll have to emulate the descriptors in the corresponding HID minidriver, so we are going to have to define mappings there as well. As a linux user I'd be inclined to use the codes from the uapi/linux/input-event-codes.h header (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/in...), where for example BTN_A is 0x130, as the usages for emulated HID devices. However, I don't know the input interfaces of other OSs, so that may not be the best idea.
True, But anyone who is going to use an Xbox controller has installed some sort of a driver for it. A driver that very likely makes is look like a HID device to the operating system. I plug in my Xbox 360 controller into my mac, with the 3rd party driver for it, and I get a HID device that reports 15 buttons (Usages 0x1 - 0xf) and 6 of Axes(Z, Rz, X, Y, Rx, Ry) . Interestingly the dpad is reported as 4 buttons and not a hatswitch. The A buttons is usage 0x1, B is 0x2, X is 0x3, Y is 0x4 and so on... I could dump the HID descriptor for it but the question becomes is that just this drivers interpretation? On linux if you install the xbox driver what elements does that report? I know the Linux Input does not give you access to lower level things like usage pages and the like, but we will need to tackle all that with the wine HID minidriver for Linux Input for any controller. I would wonder if someone had one of the more modern Logitech controllers with the X<->D switch on it, what the reports would be in the D mode or the X mode. My logitech controllers here are all too old for that, they don't even have Z axis sliders on them so they would not qualify as Xbox compatibly controllers anyway. -aric
On 02/15/2016 03:29 PM, Aric Stewart wrote:
Hi Juan,
On 2/15/16 2:37 AM, Juan Jose Gonzalez wrote:
Thanks for the attachment. In your code you seem to enumerate the available devices only once when you load the driver. XInput does not have any methods to open and close devices, it just provides methods to listen for key events and to poll the state of individial device slots. Therefore, the detection of newly connected controllers must be done by the backend continuously in order to be able to "connect" new slots as soon as devices become available. In the evdev backend I was listening for newly connected input devices, so RegisterDeviceNotification is, as you said, the way to go for the HID backend. Until that is ready, what do you think of running your detection code periodically in a separate thread, for example every 2s? Do you think that would cause a lot of overhead?
Maybe on DLL initialization? (DllMain) That will catch all the devices that are plugged in at wine startup, just like all the other current gamepad implementations. I don't know if we want to have a detection thread, it just feels messy to me. I didn't know the other gamepad implementations only enumerated the gamepads at startup. We could go with that for XInput until RegisterDeviceNotification is ready. Is DllMain a good idea? I'm not very savvy about windows (or wine) internals, but my understanding was that DllMain should only do very basic initialization. I think the enumeration should happen when the API is first accessed. That's what my implementation is currently doing. True, But anyone who is going to use an Xbox controller has installed some sort of a driver for it. A driver that very likely makes is look like a HID device to the operating system. I plug in my Xbox 360 controller into my mac, with the 3rd party driver for it, and I get a HID device that reports 15 buttons (Usages 0x1 - 0xf) and 6 of Axes(Z, Rz, X, Y, Rx, Ry) . Interestingly the dpad is reported as 4 buttons and not a hatswitch. The A buttons is usage 0x1, B is 0x2, X is 0x3, Y is 0x4 and so on... I could dump the HID descriptor for it but the question becomes is that just this drivers interpretation? On linux if you install the xbox driver what elements does that report? I know the Linux Input does not give you access to lower level things like usage pages and the like, but we will need to tackle all that with the wine HID minidriver for Linux Input for any controller. I've attached the output of a small program I created to implement the mappings in the XInput evdev backend. It shows the available event types and codes for my wireless Xbox 360 controller. I'm using xboxdrv with the --mimic-xpad option, so I guess the xpad module would yield the same results.
In the hid minidriver, we could inject some custom usage page, with info about the current minidriver, into the descriptors of devices emulated from evdev and similar non-hid interfaces. This would allow us to differentiate between different sources in the XInput code, allowing for different mappings per hid minidriver.
Hi there, Sorry for the delay in my response. On 2/15/16 10:31 AM, Juan Jose Gonzalez wrote:
On 02/15/2016 03:29 PM, Aric Stewart wrote:
Hi Juan,
On 2/15/16 2:37 AM, Juan Jose Gonzalez wrote:
Thanks for the attachment. In your code you seem to enumerate the available devices only once when you load the driver. XInput does not have any methods to open and close devices, it just provides methods to listen for key events and to poll the state of individial device slots. Therefore, the detection of newly connected controllers must be done by the backend continuously in order to be able to "connect" new slots as soon as devices become available. In the evdev backend I was listening for newly connected input devices, so RegisterDeviceNotification is, as you said, the way to go for the HID backend. Until that is ready, what do you think of running your detection code periodically in a separate thread, for example every 2s? Do you think that would cause a lot of overhead?
Maybe on DLL initialization? (DllMain) That will catch all the devices that are plugged in at wine startup, just like all the other current gamepad implementations. I don't know if we want to have a detection thread, it just feels messy to me. I didn't know the other gamepad implementations only enumerated the gamepads at startup. We could go with that for XInput until RegisterDeviceNotification is ready. Is DllMain a good idea? I'm not very savvy about windows (or wine) internals, but my understanding was that DllMain should only do very basic initialization. I think the enumeration should happen when the API is first accessed. That's what my implementation is currently doing.
API first access is ideal! You gave me the impression that was not possible. But if it is, then that is where we would want it for sure.
True, But anyone who is going to use an Xbox controller has installed some sort of a driver for it. A driver that very likely makes is look like a HID device to the operating system. I plug in my Xbox 360 controller into my mac, with the 3rd party driver for it, and I get a HID device that reports 15 buttons (Usages 0x1 - 0xf) and 6 of Axes(Z, Rz, X, Y, Rx, Ry) . Interestingly the dpad is reported as 4 buttons and not a hatswitch. The A buttons is usage 0x1, B is 0x2, X is 0x3, Y is 0x4 and so on... I could dump the HID descriptor for it but the question becomes is that just this drivers interpretation? On linux if you install the xbox driver what elements does that report? I know the Linux Input does not give you access to lower level things like usage pages and the like, but we will need to tackle all that with the wine HID minidriver for Linux Input for any controller. I've attached the output of a small program I created to implement the mappings in the XInput evdev backend. It shows the available event types and codes for my wireless Xbox 360 controller. I'm using xboxdrv with the --mimic-xpad option, so I guess the xpad module would yield the same results.
Interesting, I know very little about the evdev backend. I keep hoping someone with more knowledge and the desire would step up to help write the HID minidriver backend for it. But I bet I am going to need to eventually train myself in it and write it myself.
In the hid minidriver, we could inject some custom usage page, with info about the current minidriver, into the descriptors of devices emulated from evdev and similar non-hid interfaces. This would allow us to differentiate between different sources in the XInput code, allowing for different mappings per hid minidriver.
This part confuses me a bit. I dont think we want to write a custom minidriver for XInput if we can avoid it. A given device will have an identifier that should, ideally, be unique to that device. I would probably not be a bad thing to have a nice configuration tool to allow someone to setup mappings for their device, but i feel like that is a few more big steps down the road. I feel like the first step is to get your front end code working with a hid back end. I can really help test that since I have a full HID stack here in developement. I can also send you all the pending patchs needed to get that into your machines, It on linux it would use hidraw not linux input so the Xbox controller will not work, but all the logitech controllers we have here work through hidraw. We also will want expand the tests to try to cover all this stuff. -aric
On 02/16/2016 02:16 PM, Aric Stewart wrote:
Interesting, I know very little about the evdev backend. I keep hoping someone with more knowledge and the desire would step up to help write the HID minidriver backend for it. But I bet I am going to need to eventually train myself in it and write it myself. I could do that or help you with it, but as I said before, right now I have very limited free time, so it would have to wait a bit.
In the hid minidriver, we could inject some custom usage page, with info about the current minidriver, into the descriptors of devices emulated from evdev and similar non-hid interfaces. This would allow us to differentiate between different sources in the XInput code, allowing for different mappings per hid minidriver. This part confuses me a bit. I dont think we want to write a custom minidriver for XInput if we can avoid it. A given device will have an identifier that should, ideally, be unique to that device. I would probably not be a bad thing to have a nice configuration tool to allow someone to setup mappings for their device, but i feel like that is a few more big steps down the road. Sorry, I realize that my text was a bit confusing... I didn't mean writing a custom minidriver for XInput. I meant adding an identifier to the descriptors generated by the evdev minidriver. Since those descriptors are merely emulated, i.e. don't come from the real device anyway, we wouldn't be changing any original descriptors. Another way of putting it is that devices wouldn't look like the original devices anyway, so why not add some info that says the equivalent of "Generated by the evdev minidriver". That way, we could have a mapping in XInput that assigns the page and usage (0x09, 0x01) to BTN_A for *actual* HID gamepads, and another mapping that assigns (0x09, 0x130) to BTN_A for psudo-HID devices coming from the evdev minidriver. The selection of such mappings could be accomplished by checking whether that specific info exists in the descriptors.
I feel like the first step is to get your front end code working with a hid back end. I can really help test that since I have a full HID stack here in developement. I can also send you all the pending patchs needed to get that into your machines, It on linux it would use hidraw not linux input so the Xbox controller will not work, but all the logitech controllers we have here work through hidraw. It would be great if you could send me the patches bundled in one email, since by searching though the wine-patches list I might miss something. I have a few USB HID controllers here, so the hidraw minidriver should work. We also will want expand the tests to try to cover all this stuff. How would you test it? I would like a "testing backend" for XInput to do unit tests, but I don't know how to inject it into the backends list only during testing. Is wine compiled with an extra defined flag for testing? Would it have to be permamently added to the list and enabled/disabled during runtime?
Juan
On 2/16/16 8:06 AM, Juan Jose Gonzalez wrote:
On 02/16/2016 02:16 PM, Aric Stewart wrote:
Interesting, I know very little about the evdev backend. I keep hoping someone with more knowledge and the desire would step up to help write the HID minidriver backend for it. But I bet I am going to need to eventually train myself in it and write it myself. I could do that or help you with it, but as I said before, right now I have very limited free time, so it would have to wait a bit.
No worries, this process is slow so we have time to work it out as we can.
In the hid minidriver, we could inject some custom usage page, with info about the current minidriver, into the descriptors of devices emulated from evdev and similar non-hid interfaces. This would allow us to differentiate between different sources in the XInput code, allowing for different mappings per hid minidriver. This part confuses me a bit. I dont think we want to write a custom minidriver for XInput if we can avoid it. A given device will have an identifier that should, ideally, be unique to that device. I would probably not be a bad thing to have a nice configuration tool to allow someone to setup mappings for their device, but i feel like that is a few more big steps down the road. Sorry, I realize that my text was a bit confusing... I didn't mean writing a custom minidriver for XInput. I meant adding an identifier to the descriptors generated by the evdev minidriver. Since those descriptors are merely emulated, i.e. don't come from the real device anyway, we wouldn't be changing any original descriptors. Another way of putting it is that devices wouldn't look like the original devices anyway, so why not add some info that says the equivalent of "Generated by the evdev minidriver". That way, we could have a mapping in XInput that assigns the page and usage (0x09, 0x01) to BTN_A for *actual* HID gamepads, and another mapping that assigns (0x09, 0x130) to BTN_A for psudo-HID devices coming from the evdev minidriver. The selection of such mappings could be accomplished by checking whether that specific info exists in the descriptors.
Ok that makes more sense. I am sure we can figure out those details as we work more on implementation.
I feel like the first step is to get your front end code working with a hid back end. I can really help test that since I have a full HID stack here in developement. I can also send you all the pending patchs needed to get that into your machines, It on linux it would use hidraw not linux input so the Xbox controller will not work, but all the logitech controllers we have here work through hidraw.
It would be great if you could send me the patches bundled in one email, since by searching though the wine-patches list I might miss something. I have a few USB HID controllers here, so the hidraw minidriver should work.
We also will want expand the tests to try to cover all this stuff. How would you test it? I would like a "testing backend" for XInput to do unit tests, but I don't know how to inject it into the backends list only during testing. Is wine compiled with an extra defined flag for testing? Would it have to be permamently added to the list and enabled/disabled during runtime?
Wine has a great test suite. What would be nice is to have something like the dinput tests where if run in interactive mode dump gamepad events and such. Something where you can test the Xinput is working as expected. Take a look at dlls/dinput/tests/joystick.c The tests would all be directed at XInput, you could write tests like that using your current back end, since the back end should not affect that level of tests at all. -aric
participants (4)
-
Aaryaman Vasishta -
Aric Stewart -
Juan Jose Gonzalez -
Stefan Dösinger