Closed mutwilligekartoffel closed 3 years ago
Thanks for the detailed report!
I just tested out evdev_rs::ReadFlag::BLOCKING
on my machine, and it seems to be working fine. Personally, I can't tell the difference between the two, but then again, I've never actually tested this code on any "underpowered" devices (such as a Raspi).
... I have no knowledge of evdev and do not know whether the change may break stuff elsewhere.
Me and you both! I kinda just hacked this code together over the course of a week or two, so my knowledge of evdev (and surrounding libraries) is pretty surface-level (pardon the pun).
That said, I did quick once-over through the code that would be impacted by this change, and it looks like there shouldn't be any problems by switching to BLOCKING
. I'll push up the change and close this issue.
Almost immediately after starting the service, input from the dial starts lagging behind.
Events are processed immediately whenever I turn the dial, but they do not match my inputs. Instead they are delayed, so rotating the dial 90° cw, then inverting direction will continue to output clockwise rotation values for a short while.
Still events will only be thrown as long as I keep turning in either direction. So there is no time delay but rather some kind of event flow impediment.
The delay is strongly noticable on a Raspberry Pi 4 and slightly less pronounced on my desktop machine.
This issue is fixed when fetching events using
evdev_rs::ReadFlag::BLOCKING
instead ofevdev_rs::ReadFlag::NORMAL
in dial_device/events.rs.I would like to propose switching to
evdev_rs::ReadFlag::BLOCKING
but I have no knowledge of evdev and do not know whether the change may break stuff elsewhere.First encountered on Raspberry Pi 4:
Less pronounced reproducable on Zen3 Desktop:
Edit: I almost forgot: You are absolutely awesome! Thank you for creating this!