XInput: Comments on core and further steps

[Aric Stewart]

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