Wine Joysticks, seeking a plan

[Roderick Colenbrander]

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 at codeweavers.com> wrote:
> On 4/16/15 2:12 PM, Ken Thomases wrote:
>> On Apr 16, 2015, at 9:46 AM, Andrew Eikum <aeikum at 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
>
>