In case a user wants to neatly filter those out of their device list.

Axis components report a weird default input on the first update call.

The code is basically already there, and a full HID manager could offer good basis for eventual direct HID support.

See if it is possible to separate XBONE emulated xinput devices from xb360 devices.

The project contains some hackish design that violates the single responsibility principle. Rework it.

I've never seen a slider component or know what it is, but DirectInput devices can apparently have them, so add support for them, I guess.

Currently throws an exception if XInput load or init fails.
Can't really see it happening, but there's no reason to not be flexible about it since the module "system" is dynamic anyway.

Not sure if the reason is a specific (emulated) device, Windows 10 in general or something that VMware does, but failing to fetch attributes for a single device probably should not cause the entire library to fail. Such a device should simply be skipped over.

For fun and profit

Since it's now more of a generic event monitor.

Currently a Wacom tablet is not detected as an input device at all, yet simple point and click games might be played with a pen.
As it is similar to touch input, maybe take that into account at the same time.

It would be nice to be able to uniquely identify devices between application/OS restarts. This is rather essential for saving per-controller configurations in applications that use such.

Hi!

I'm having an issue when connecting 2 DInput gamepads of the same model simultaniously. Depending on what order I connect them, sometimes only one of them will work. And in that case the working one will be initiated 2 times. So in your test application this means pressing button 0 on joypad #1 causes this output:

Controller button 0 pressed (USB 2A8K GamePad)
Controller button 0 pressed (USB 2A8K GamePad)
Controller button 0 released (USB 2A8K GamePad)
Controller button 0 released (USB 2A8K GamePad)

But pressing the same button on joypad #2 doesn't render any output at all.

This problem traces back to the way DInput genrates GUID's. There seems to be a bug when connecting several gamepads of the same model, so that depending on the order of connection sometimes DInput will actually change GUID of certain controllers. I've tried really hard to find a workaround for this but havn't come up with something. Do you have any ideas? :-)

Like non-static runtime linking, and maybe even x86.

Many "shadow devices" lack a real name in the drivers/APIs/OS, so generate something for those.

Presumably due to XInput versioning fuckups by Microsoft. Looking into it.

See testbed for problem

Add support for all the additional features offered for Logitech devices by the GKey-, LED- & LCD SDKs.

See if it is possible to separate DS3 emulated xinput devices from official xinput devices.

Currently only the VK codes are passed to listeners, and are unsuitable for text input.

It's rather ugly for now, although usable.

Constant multi-listener support might be somewhat taxing both for the implementer and for the callbacks. Actually utilising multiple listeners per device seems like a rather exceptional use case, which the end-application could then implement themselves.
To be investigates or at least thought about.

Some methods in the project that could be const aren't.

After completing the HID manager, implement direct mouse & keyboard support by HID communication. This way the precision and speed limitations of going through the OS & DirectInput layer are easily surpassed.

...since we ended up implementing all input as global, not window-specific anyway.

See if it is possible to separate DS4 emulated xinput devices from official xinput devices.