XInput and HID - architecture

[Juan Jose Gonzalez]

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

- Juan