XInput and HID - architecture

[Aric Stewart]

On 3/23/16 12:37 AM, Roderick Colenbrander wrote:
> On Tue, Mar 22, 2016 at 12:18 PM, Juan Jose Gonzalez <juanj.gh at gmail.com> wrote:
>> On 03/22/2016 01:27 AM, Roderick Colenbrander wrote:
>>>
>>>>> As you have seen the xbox controller lacks proper HID descriptors and
>>>>> on Windows the drivers fake descriptors to allow DirectInput to work
>>>>> as well. We would be doing something not to different. For the
>>>>> DirectInput I would report the real device name and the real ranges,
>>>>> similar if games use raw input (not sure if there are games which do
>>>>> this).
>>>> On Wine, this would work the other way around. We would have raw (HID)
>>>> devices as a base, and create DInput and XInput devices from those.
>>> I understand that part. What I meant is that Windows reports 2
>>> different devices one with HID and one without. I was suggesting this
>>> as a way to potentially handle non-native xinput devices, e.g. the
>>> non-native device is made to appear like the xbox one on windows with
>>> the missing descriptors etcetera.
>> I'm not sure I understand what you mean.
>   The currently planned wine
>> architecture uses the HID subsystem as a common base, allowing us to
>> create a single minidriver per backend (evdev, hidraw, etc.), and then
>> lets DInput and XInput access that. Are you suggesting putting all the
>> XInput code (gamepad matching, control mapping) into the HID subsystem?
> 
> I suggested maybe following the Windows 2 device approach for maybe
> dealing with xinput for non-native devices (the mapping is pretty much
> the same for steam / ds3 / ds4 / wii u gamepad, just slightly
> different ranges and button names). For such devices it could make
> sense to map them to a fixed mapping to simplify handling for xinput.
> Also I'm not sure how important remapping is normally for users since
> many games have configurable input.
> 
>>> Though this still wouldn't handle
>>> the enumeration situation for apps using wmi.
>> Sorry, as you may have noticed, I'm not too savvy about Windows APIs.
>> What is wmi?
> 
> WMI is a subsystem let's say a bit comparable to /proc & /sys on Linux
> providing all sorts of information about the system. Through WMI you
> can provide information on e.g. CPU, USB devices, PCIe devices,
> network information etcetera. As a developer you provide an SQL-like
> query to request certain type of information.
> 
> For xinput, Microsoft directly provided the xbox API without really
> considering enumeration well (except for naive polling). One mechanism
> Microsoft recommended as a bit of an oversight in my opinion was to
> use WMI to enumerate input devices.
> 

I will have to investigate this. I will add it to my list of surrounding pieces to try to make work. Right now setupapi enumeration works and all my current test applications use that. I have not run into an application trying to use WMI yet. Dinput enumeration also happens but that should be able to be made to work easily. 

> Also before I forget one other important thing for xinput are window
> messages. I forgot the exact message name but something like
> WM_DEVICECHANGED or something is important. Various applications
> listen for the message to detect hotplugging of input devices and then
> triggering a new device enumeration. For Linux this would require us
> to tap into udev (SDL2 does this too, the code can give some
> inspiration).

Yes, WM_DEVICECHANGED and many of the device addition messages are missing. This is affecting any ability for the Plug and Play functionality to trick up to applications. It is on my list of things to work on along with IoRegisterPlugPlayNotifications and our plug and play facility comes into place. 

-aric

> 
>>
>> - Juan