XInput: Comments on core and further steps

[Aric Stewart]

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