XInput: Comments on core and further steps

Juan Jose Gonzalez juanj.gh at gmail.com
Tue Feb 16 08:06:53 CST 2016


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



More information about the wine-devel mailing list