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