Hmm grab and listen at the same time should go in a specific order, as as I understand it, the latter gets placed on top of the other. That's why there are sleeps in the grab test.

• I'm sure it behaves that way on Mac because the doc says so.
• On windows, cancelling and event required to return some code, which I could not find a documentation for, and they are not specific as to how callbacks are placed relative to each other, but I think it behaved like Mac in my various tests and I could not find an issue with that on Windows.

As I can see the error seems to be that the KeyRelease of Tab gets captured, and I think in the test I only grabbed the keypress. Because you now send a KeyReleasethat's why it gets captured by listen (on Windows).

PS: just checked out your branch to check how it worked, it behaves the same way that my tries did, which is that as long as you are grabbing , no events ever reaches the rest of the OS, which means I have to reboot, I don't have access to a terminal anymore (just reallized I didn't check if TTY still worked).

I'm using Ubuntu 18.04 with Awesome window manager, maybe that's the problem ?

which means I have to reboot, I don't have access to a terminal anymore

I included an escape hatch (that will be removed before shipping) - just press escape to stop grabbing. Furthermore, on Linux, ctrl-alt-F3 brings you to the linux terminal emulator, regardless of anything the X server is doing. There are actually multiple virtual terminals - usually one is used for login, one for the main graphical environment and the rest (by default 6 total) for plain virtual terminals. So ctrl-alt-{F3-F6} all work. From a virtual terminal I used htop to stop the rdev process multiple times.

as long as you are grabbing , no events ever reaches the rest of the OS

It's a bit embarrassing to admit, but I missed this in testing. There are a few methods I'm investigating, including sending events to focused windows instead of the root window, ungrabbing before simulating and looking through all of XCB's documentation for other options...

I created a separate crate - gel-o, which is a bunch of ceremony around running a rust closure on evdev_rs::InputEvents. I pulled it in as a dependency for this crate, and it seems to work, although interacts poorly with simulate (can't see simulated events). Let me know what you think.

Seems reasonable.

I will probably pull gel-o into rdev so it depends directly on evdev, I feel it's a bit more appropriate to not add layers of dependencies if possible. Event evdev dependency would probably be behind the grab feature flag. I could do that after your PR is ready to merge,

Done in #52