Hi Aric,
Sorry for the late reply, I don't have too much time lately.
HID is the proper abstraction layer for gamepads, any USB or Bluetooth input device uses it. All the input events map to input reports and LED adjustment / force feedback / rumble map to output reports.
It can be a bit of a challenge though to represent all the buttons, axes properly through HID since HID is quite complex. I'm wondering to what extend we need to report the proper device IDs since recreating the exact descriptors as the real device on Windows is nearly impossible. The concern being that various apps are probably stupid enough to just interpret HID report data without parsing the report descriptors if they detect a certain vendor / device ID. On the other hand not using the exact hardware IDs, may result in apps not working (e.g. app not finding an Xbox controller). I'm not sure what is best, so far I would lean to at least reporting the proper device IDs and see how it goes.
Regarding design, I would not look too much about the old Wine joystick code. There are various things it is not doing correctly and some newer'ish features are missing. Some requirements from my end: - Hardware bus layout needs to be provided to WMI and maybe other system information libraries, so stupid apps mixing dinput + xinput can identify x360 devices. - New HID subsystem needs a mechanism to deal with hotplugging and send corresponding WM_DEVICECHANGE event. Various applications especially xinput ones, are not continuously monitoring if there are devices (especially if there were 0 at app startup). For Linux this would probably need a thread dealing with udev / inotify. - HID backend at least for Linux needs some sort of input thread to prevent lost input. Event queue on Linux has a limited size (typically 64 events) and needs to be drained quickly in order not to get SYN_DROPPED events. Some newer devices like DS4 are very sensitive to this, because they have short poll intervals and sensitive axes.
Thanks, Roderick
On Thu, Apr 23, 2015 at 5:03 AM, Aric Stewart aric@codeweavers.com wrote:
On 4/16/15 2:12 PM, Ken Thomases wrote:
On Apr 16, 2015, at 9:46 AM, Andrew Eikum aeikum@codeweavers.com wrote:
On Thu, Apr 16, 2015 at 08:11:39AM -0500, Aric Stewart wrote:
Now completely unresearched but it may be possible to make a single joystick driver, maybe replacing winejoystick.drv that would build only the platform code that is relevant.
This makes sense to me, and is how dinput already works. Make some sane API for it and build dinput/winmm/xinput on top of that.
Makes sense to me, too.
-Ken
Thanks to the great leads that Vincent gave me about Raw Input and such I ended up on a path reading about the HID minidrivers and the whole HID class.
I bounced the idea that the Joystick support should be in HID and Alexandre seemed warm to the idea. So I will do work to implement and update our hid.dll to see about putting joystick code in there.
Then, all the other joystick areas can be build off of the HID code. It is already clearly stated in the HID documentation that dinput is a client of the HID code.
The main trick is going to see if all the special functionality (such as forcefeedback or rumble) has a path through HID or not.
-aric