XInput: Comments on core and further steps

[Aric Stewart]

Hi Juan,

On 2/15/16 2:37 AM, Juan Jose Gonzalez wrote:
>>>    - 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?
> 

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 am poking at the RegisterDeviceNotification parts, I would love to have more forward progress on the whole of the plug and play architecture before adding more bit to it, but it is an important part to the user level stuff, like this, and so having an idea of how to approach it is good.

>> 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.
> 

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 would wonder if someone had one of the more modern Logitech controllers with the X<->D switch on it, what the reports would be in the D mode or the X mode. My logitech controllers here are all too old for that, they don't even have Z axis sliders on them so they would not qualify as Xbox compatibly controllers anyway. 

-aric