Report device id on Windows

[boppreh]

Linux already has this.

Device information is not included in the hook we are using, which complicates things. Raw Input seems to provide this, but it doesn't include the virtual key codes we use to map most of the key names and keypad status.

There should be some kind of device information on event.device.

Note: https://github.com/me2d13/luamacros seems to do this.

[boppreh]

https://www.codeproject.com/articles/716591/combining-raw-input-and-keyboard-hook-to-selective

[boppreh]

The new branch "windows-device-id" now contains a possible solution to this problem.

Low Level Keyboard hooks don't include device information. Raw Input Device
listeners do, but they don't allow for blocking events. To combine both, we
run a listener of each. Low level hook events are processed first (unknown
why), so we put those events into a "deviceless_events" queue. When the
corresponding raw input device events comes (identified by order), we fill
the missing device id and pass it along to the generic keyboard library.
Raw input devices are sometimes buffered, but as long as events are served
in order, this should be ok.

Unfortunately the device id is fetched after the window of opportunity
for blocking events, so we can never block events based on it.
On the other hand, we don't need to wait for the device id before deciding
to block or allow, so events are processed more quickly and with less key
delay.

Still needs more testing.

[boppreh]

Note to self:

https://www.codeproject.com/articles/716591/combining-raw-input-and-keyboard-hook-to-selective (uses DLL, but has interesting ideas on how to pair events)
https://github.com/oblitum/Interception
http://nate.deepcreek.org.au/dev/keyboardredirector.rails

[kg-2]

any progress on this?

[cobrce]

take a look at this, it might help
https://github.com/cobrce/interception_wrapper
This repo is a port (not a wrapper), it works better than the other one, tested only keyboard and it works

[DomML]

Is this issue still relevant ?

[boppreh]

Yes, I still want the feature and it's still not implemented.

It's not my highest priority right now, though.

[zys5945]

take a look at this, it might help https://github.com/cobrce/interception_wrapper This repo is a port (not a wrapper), it works better than the other one, tested only keyboard and it works

Couple things to consider for interception:
The device driver itself is not open source.
I tested it locally and found that it doesn't play very nicely with virtual machines. Namely keyboards will stop working if you disconnect then reconnect (no keystrokes received by the OS).
Some other people also found issues with keyboard switches (KVM): oblitum/Interception#145

I think there's something wrong with the way it handles device reconnect

[SZRabinowitz]

for whatever it's worth, I would also love this feature, but dont know enough about windows development to contribute.