Adding HID joystick support to FreeBSD

[Roderick Colenbrander]

On Sun, Mar 22, 2015 at 4:26 PM, Charles Davis <cdavis5x at gmail.com> wrote:
>
>> On Mar 22, 2015, at 7:12 AM, Stefan Dösinger <stefandoesinger at gmail.com> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Am 2015-03-21 um 20:58 schrieb Bruno Jesus:
>>> Thank you very much for all information, I'll try and report back
>>> if I find any problems. I'm working in winmm because it's an easier
>>> starter point.
>> Wouldn't it make sense to have a shared joystick library that winmm,
>> dinput and (later on xinput) talk to rather than have different OS
>> abstraction layers in winmm and dinput?
> I agree. In fact, what I think we should do is implement the HID
> ioctls in ntdll, and perhaps even hid.dll on top of that. Then all
> the input-related stuff would just make HID ioctl calls to ntdll.
>
> But even if we don’t wind up doing that, I definitely think that
> having a common library handling input devices is a good idea.
>
> Chip
>
>
>

Recently I had a look at this area as well due to some xinput work I
did recently, but it again adder per platform backends. In addition
xinput has some nasty behaviour, which really requires dinput and
xinput to have a common base. In a nutshell xinput is all about
polling 'XInputGetState(device_index, ..)' and there is no method
defined by xinput of enumerating a device except for checking if
'XInputGetState' returns an error. Microsoft at the time recommended
to do enumeration using dinput and then mix the dinput enumeration
code with some fun WMI calls to check if a device is xinput capable.
To do this well dinput, xinput and even WMI need to have a similar
view of input devices.

Initially I was looking at win32 raw input, because you can also use
raw input for gamepads (yep, this is a 4th method in addition to
winmm, dinput and xinput). It felt quite suitable and it also handles
device notification (for gamepad devices you want WM_DEVICE_CHANGED
notifications for hotplug notifications). The only thing it was
lacking was some sort of 'SetRawInputData'-like call, which you would
need for sending force feedback / rumble data to a HID device. This
disqualified it for me, but it was really close.

It felt like the raw input API was a thin layer on top of HID anyway,
since a lot of posts refer to HID APIs if you want to understand what
is inside your data blobs. Ultimately it felt that implementing
hid.dll would probably the way to go. The API is not very hard, but it
is all quite low level and we would layer it on top of a higher level
APIs like Linux evdev, which again feels like translating D3D bytecode
back to GLSL or worse. Doing this would be quite a big undertaking and
I'm not sure how easy it is to get right, especially debugging raw HID
packets is no joy.

Roderick