swhkd: `swhkd` does not process hotkeys of newly connected devices

Version Information:

Linux arch-dktp-alexis 5.19.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 31 Aug 2022 22:09:40 +0000 x86_64 GNU/Linux
swhkd 1.2.1 (installed from the swhkd-git AUR package)

Describe the bug: swhkd does not register hotkeys from a newly connected keyboard (or disconnected then reconnected).

Expected behavior: swhkd should be able to register hotkeys on a newly connected keyboard.

Actual behavior: swhkd does not grab newly connected devices and thus cannot handle their keypresses events.

To Reproduce: Start swhkd. Connect a keyboard (or disconnect yours before reconnecting it). Hotkeys will not work.

Additional information: This can probably be solved using udev, with either the udev crate or tokio-udev crate.

My attempts at implementing this (the same content is also in the [wip] commits of each branch):

Using the tokio-udev crate (udev_async branch):

This does not work as-is. Unfortunately, sometimes udev events get ‘stuck’ and only processed after another batch of events comes in. In practice, this translates to e.g. a batch of ‘Add’ events (after connecting a device) only passed to the application loop after a batch of ‘Remove’ events (after disconnecting the same device for instance).
Using the udev crate iterators wrapped in a tokio stream (udev_sync branch):

This does not work as-is, as the MonitorSocket Iterator may return None when no udev events are available. tokio stops listening after the first None received from the stream, which means that events are not listened to at all.
Using the udev crate with a busy loop (udev_sync_busy branch):

At the cost of an always busy thread, this does receive all udev events in a timely manner.

The busy loop is the only one which is working, but also the worst performance-wise. See this one more as a proof of concept.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 42 (27 by maintainers)

Most upvoted comments

@ConcurrentCrab were you able to claim the bounty?

I thought it best not to take any actions on my side yet in case you had actually intended to split it.

Unfortunately there’s no way to split it. The one who creates the PR is eligible for the bounty. So you can go ahead and claim it since you were the one that created the PR.

@Shinyzenith I released the fixes for tokio-udev but who fixed it was @sjoerdsimons, so I don’t actually deserve any bounty but him

@sjoerdsimons here’s the bounty for tokio-udev: https://app.bountysource.com/issues/121368069-events-were-blocked-while-poll-next

I have no need for a bounty; I’m happy for @jeandudey to pick it up as thanks for maintaining tokio-udev or for the funding to be re-used for another issue that seems worthwhile.

sjoerdsimons on Jul 28, 2023

Sadly I was warned about BountySource before but there isn’t that many sites that offer bounties with escrow. Rysolv is one that I have used before. I was debating switching to it but decided against it which was my mistake I guess.

I’m really sorry about this @ConcurrentCrab. Please send me a DM with your PayPal email on Matrix (@cluelesstechnologist:matrix.org) or email me. (email in my GitHub profile)

Another option is to enable Github Sponsors on your profile.

CluelessTechnologist on Aug 29, 2023

Unfortunately there’s no way to split it. The one who creates the PR is eligible for the bounty. So you can go ahead and claim it since you were the one that created the PR.

To be completely fair, alexis created the initial fix, just in a branch. I opened the PR. I obviously don’t want any part of the bounty, I’m just stating the facts. The next PR fixing the index out of bounds issue was from ConcurrentCrab.

Shinyzenith on Jul 27, 2023

@Shinyzenith I released the fixes for tokio-udev but who fixed it was @sjoerdsimons, so I don’t actually deserve any bounty but him

jeandudey on Jul 26, 2023

I have merged the pr sent by @ConcurrentCrab. Just to be sure @CluelessTechnologist would you mind testing the latest HEAD of udev branch once more? If all is good to go, I’ll merge.

Sure. Just tested the latest commit from udev branch. Happy to report that it’s still working:

[2023-07-19T22:49:04Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event2' removed
[2023-07-19T22:49:04Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event3' removed
[2023-07-19T22:49:04Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event4' removed
[2023-07-19T22:49:04Z INFO  swhkd] Device 'Logitech Gaming Mouse G502 Keyboard' at '/dev/input/event1' removed
[2023-07-19T22:49:11Z ERROR swhkd] Could not open evdev device at /dev/input/mouse0: Inappropriate ioctl for device (os error 25)
[2023-07-19T22:49:11Z DEBUG swhkd] Keyboard: Gaming keyboard
[2023-07-19T22:49:11Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event2' added.
[2023-07-19T22:49:11Z DEBUG swhkd] Keyboard: Gaming keyboard
[2023-07-19T22:49:11Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event4' added.
[2023-07-19T22:49:11Z DEBUG swhkd] Keyboard: Gaming keyboard
[2023-07-19T22:49:11Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event3' added.
[2023-07-19T22:49:11Z DEBUG swhkd] Keyboard: Logitech Gaming Mouse G502 Keyboard
[2023-07-19T22:49:11Z INFO  swhkd] Device 'Logitech Gaming Mouse G502 Keyboard' at '/dev/input/event1' added.
[2023-07-19T22:49:11Z TRACE swhkd] Other: Logitech Gaming Mouse G502

CluelessTechnologist on Jul 19, 2023

I have merged the pr sent by @ConcurrentCrab. Just to be sure @CluelessTechnologist would you mind testing the latest HEAD of udev branch once more? If all is good to go, I’ll merge.

Shinyzenith on Jul 19, 2023

Still don’t face the issue, but I came up with some theories and made some fixes to obvious problems: https://github.com/ConcurrentCrab/swhkd/tree/udev_async #216

Nice, seems to be working now. Great job!

[2023-07-18T20:11:23Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event2' removed
[2023-07-18T20:11:23Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event3' removed
[2023-07-18T20:11:23Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event4' removed
[2023-07-18T20:11:23Z INFO  swhkd] Device 'Logitech Gaming Mouse G502 Keyboard' at '/dev/input/event1' removed
[2023-07-18T20:11:31Z ERROR swhkd] Could not open evdev device at /dev/input/mouse0: Inappropriate ioctl for device (os error 25)
[2023-07-18T20:11:31Z DEBUG swhkd] Keyboard: Logitech Gaming Mouse G502 Keyboard
[2023-07-18T20:11:31Z INFO  swhkd] Device 'Logitech Gaming Mouse G502 Keyboard' at '/dev/input/event1' added.
[2023-07-18T20:11:31Z DEBUG swhkd] Keyboard: Gaming keyboard
[2023-07-18T20:11:31Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event2' added.
[2023-07-18T20:11:31Z DEBUG swhkd] Keyboard: Gaming keyboard
[2023-07-18T20:11:31Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event3' added.
[2023-07-18T20:11:31Z DEBUG swhkd] Keyboard: Gaming keyboard
[2023-07-18T20:11:31Z INFO  swhkd] Device 'Gaming keyboard' at '/dev/input/event4' added.
[2023-07-18T20:11:31Z TRACE swhkd] Other: Logitech Gaming Mouse G502

CluelessTechnologist on Jul 18, 2023

I have time this weekend to work on the udev problem! I’ll go ahead and start on a patch asap. PS: Cleared up some unnecessary messages.

Shinyzenith on Oct 26, 2022