`persist=reopen` does not prevent evsieve from exiting

[callegar]

Hi, trying to use evsieve with a 2-in-one tablet/laptop with a detachable keyboard/touchpad combo. On this machine evsieve is needed when the keybord is attached because the keyboard/touchpad controller incorrectly maps mouse gestures to windows key sequences in a way that makes the machine unpleasant to use in linux.

I have come down with the following script:

evsieve \
    --input \
        /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-event-kbd \
        domain=kb grab persist=reopen \
    --input \
        /dev/input/by-id/usb-HS-C109S-US-01-00-_USB_Keyboard-if01-event-mouse \
        domain=ms grab persist=reopen \
    --hook key:leftmeta key:s sequential period=0.001 send-key=btn:middle@ms \
    --hook key:leftmeta key:d sequential period=0.001 \
    --hook key:leftmeta key:a sequential period=0.001 \
    --hook key:leftmeta key:b sequential period=0.001 \
    --hook key:leftmeta key:tab sequential period=0.001 \
    --withhold \
    --output @kb name="Evsieve virtual keyboard" \
    --output @ms name="Evsieve virtual mouse"

However, when I detach the keyboard evsieve exits notwithstanding the persist=reopen. Am I using the option wrong? Is it because all the devices disappear?

[KarsMulder]

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 8bcd4b8097d1d4f8a64e6f48eb18c81b0bf58507) 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.)

[callegar]

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.

[callegar]

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?

[KarsMulder]

(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 cea39d9c9ae906a8c6137c55e66182bef97adb57) 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?)

[callegar]

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.

[callegar]

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...

[KarsMulder]

Based on the posted output, I think that two things are happening:

1. Inotify isn't informing evsieve that the device is available.
2. 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:

1. Which version of which Linux distribution you're using?
2. The output of the command uname -r?
3. The output of the command mount -l | grep "on /dev"?