Comments (7)
Sorry for the late reply, it appears that emails from Github are not arriving in my inbox anymore for some reason. I'm going to figure out why this is happening.
That said, you are using the persist=reopen
argument correctly and evsieve should not exit in this situation, not even if both devices disappear.
I can't reproduce the issue at my computer; when I run the script, evsieve does properly re-open the closed devices even if I disconnect both the keyboard and the mouse, even if I close both of them at the same time by disconnecting the USB hub that both are attached to.
Does evsieve provide either of the following messages when it quits? If so, which of these two does it provide? Or does it quit with another message or no message at all?
No devices to poll events from. Evsieve will exit now.
No devices remaining that can possibly generate events. Evsieve will exit now.
Does evsieve print anything else? When a device disconnects, it should print a message like
The device /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-event-kbd has been disconnected.
If it prints more than that, then the rest are probably error messages. Could you please post the full output that evsieve writes to the terminal?
Does disconnecting your keyboard happen to close the terminal or trigger some kind of logout event? Evsieve does quit when it receives a SIGHUP signal, which is usually sent when the terminal it is running in closes.
If evsieve does not print a message when quitting, could you try to recompile evsieve from the current main branch (commit 8bcd4b8) and try it with that version? I added a few extra prints to the paths that would in 1.4.0 cause evsieve to quit without message (in particular, it now tells you when it receives a signal.)
from evsieve.
Sorry for the long silence, got catched in too many duties to test.
- currently trying to build from source and test the git tip.
In the meantime I more thoroughly tested 1.4.0 that comes with my distro.
Apparently, the program exiting was completely my fault, since I was not detaching from the terminal in the right way (may I suggest a --daemonize
option?). Now evsieve
is not exiting. However, is not reopening the devices either. When I suspend the tablet or I detach it from the keyboard, I get some output from evsieve saying that the devices are detached. However, when I resume or reattach the keyboard, I find the evsieve process still there, but evsieve not transforming the keys.
from evsieve.
Tested with the git tip. Experiencing the same. When I detach the tablet from the keyboard and reattach it, evsieve is not doing its job anymore... How to debug?
from evsieve.
(may I suggest a --daemonize option?)
The recommended way to daemonize evsieve is by running it as a systemd service, which can be done either by writing a systemd unit file or by wrapping the evsieve command in systemd-run
.
However, is not reopening the devices either.
Hmm...
The first possible culprit that comes to mind is a possible error in how evsieve waits for devices to become available again. It currently relies on Linux' inotify
API, which is intended to monitor for changes in the filesystem: it is expected that when the input device disappears, its device node disappears from the filesystem as well, and this device node will reappear when the device gets reattached. It then uses inotify
to ask the kernel to notify evsieve whenever the contents of the directory containing your input device changes, or whatever directory the symlink representing your input device points to, or the directory the symlink to another symlink points to, etc.
I don't think this is the cleanest way to do this; it's not the intended way to listen for new devices and requires a lot of almost-redundant checks to avoid race conditions, but I haven't been able to find any case wherein this approach failed so far. The "proper" of doing it would be to rely on udev events, but that would require linking to an OS-specific udev library, complicating the build process and making evsieve more OS-dependent.
Anyway, I pushed a new commit to the master branch to help with debugging. Can you obtain a copy of the newest version of the main branch (commit cea39d9) and then recompile evsieve with the debug-persistence feature enabled?
cargo build --release --features debug-persistence
With this feature enabled, two things should happen: first, it will try to reopen the devices every five seconds even if inotify doesn't inform us of any updates, and second it prints additional information to stdout while reopening devices to help with debugging.
Could you try running the latest version of the main branch with the debug-persistence feature, and then post what evsieve prints to stdout? (And even if this periodic check fixes the issue, could you please post the output anyway?)
from evsieve.
Could not run the latest branch yet. However, I have still made an interesting quick discovery. If I invoke evsieve passing the device as \dev\inuput\input11
which is not the recommended way, then persistence works. If I pass the device via the /dev/input/by-id/
entry, which on my system is a link to a \dev\input
device, then persistence does not work.
from evsieve.
Interesting:
The device /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-event-kbd has been disconnected.
Persistence subsystem launched.
Persistence subsystem received command from main thread.
Registering new device to reopen in the future: /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-event-kbd
Directories to monitor: /dev/input/by-id
The path /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-event-kbd does not exist.
Attempted to open the device at /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-event-kbd. Outcome: not opened
Directories to monitor: /dev/input/by-id
Directory monitor status: unchanged
Received ready report from inotify. Checking persistent devices...
The path /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-event-kbd does not exist.
Attempted to open the device at /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-event-kbd. Outcome: not opened
Directories to monitor: /dev/input/by-id
Directory monitor status: unchanged
No report from inotify received. Commencing periodic check of persistent devices...
Attempted to open the device at /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-event-kbd. Outcome: success
Directories to monitor: (none)
Directory monitor status: severe error
In the persistence subsystem:
System error: invalid argument (os error 22)
Internal error: epoll reported a file as broken despite that file not being registered with said epoll.
At this point evsieve is not remapping...
from evsieve.
Based on the posted output, I think that two things are happening:
- Inotify isn't informing evsieve that the device is available.
- After evsieve notices that the device is available due to the once-per-five-seconds check, evsieve tries to tell the inotify instance to stop watching the directories, which fails and subsequently crashes the whole persistence subsystem.
I am still mystified on the question why inotify isn't informing us of the new input device, and especially why removing a watch from the inotify is failing. I'm going to have to dig into this deeper. I think it would be faster if I could replicate this issue myself.
Could you tell me:
- Which version of which Linux distribution you're using?
- The output of the command
uname -r
? - The output of the command
mount -l | grep "on /dev"
?
from evsieve.
Related Issues (20)
- Question re switching 1 kbd between multiple VMs HOT 3
- Possible to block regular key output while pressing a hook keyboard combo? HOT 4
- Multi-touch finger count HOT 1
- Unknown event code mapping/copy issue HOT 2
- Possibility to map undefined keys (EV_KEY 300, 301) HOT 1
- 100% CPU usage when using --control-fifo HOT 2
- Handling of bluetooth input devices (no persistent device name, device may be unavailable at startup) HOT 2
- [RFC] Configuration file HOT 7
- compilation issues on 32 bits boards (+ patch) HOT 1
- Make virtual keyboard acts like "physical" HOT 3
- Is it possible to map a mouse's relative position to a controller's analog stick absolute position? HOT 2
- how to output as a virtual joystick? HOT 3
- will this work with Multi-pointers? HOT 2
- Key repeat request to kernel HOT 2
- Mouse Accelertion Profile & Pointer Speed HOT 1
- Multi bouton support? HOT 1
- Generating scroll event from hook HOT 1
- Question: is realtime scheduling priority needed/advised on underpowered hosts? HOT 2
- Slow vertical mouse movements aren't registered when using "--map rel ::0.5x" to reduce mouse sensitivity HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from evsieve.