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

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.

For fun and profit

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

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

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.

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.

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

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

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

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

It's rather ugly for now, although usable.

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.

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.

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

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

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

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.

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

See testbed for problem

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.

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

...since we ended up implementing all input as global, not window-specific 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.

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