Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report device id on Windows #21

Open
boppreh opened this issue Nov 14, 2016 · 9 comments
Open

Report device id on Windows #21

boppreh opened this issue Nov 14, 2016 · 9 comments

Comments

@boppreh
Copy link
Owner

boppreh commented Nov 14, 2016

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
Copy link
Owner Author

boppreh commented Nov 27, 2016

boppreh added a commit that referenced this issue Aug 6, 2017
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.

Unforutnately 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.
Please enter the commit message for your changes. Lines starting
with '#' will be ignored, and an empty message aborts the commit.
@boppreh
Copy link
Owner Author

boppreh commented Aug 6, 2017

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
Copy link
Owner Author

boppreh commented Aug 17, 2017

@kg-2
Copy link

kg-2 commented Aug 22, 2018

any progress on this?

@cobrce
Copy link

cobrce commented Jan 27, 2019

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
Copy link

DomML commented Mar 23, 2022

Is this issue still relevant ?

@boppreh
Copy link
Owner Author

boppreh commented Mar 23, 2022

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

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

@zys5945
Copy link

zys5945 commented Jun 18, 2022

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants