XInput: Comments on core and further steps

[Juan Jose Gonzalez]

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/include/uapi/linux/input-event-codes.h?id=refs/tags/v4.4.1),
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