On Sun, Mar 22, 2015 at 4:26 PM, Charles Davis cdavis5x@gmail.com wrote:
On Mar 22, 2015, at 7:12 AM, Stefan Dösinger stefandoesinger@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