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.