Repository navigation
Device.read_loop() misses button presses #101
Description
I'm using a Griffin PowerMate plugged into a Raspberry Pi running Stretch. I wrote a Python3 script using python-evdev to listen for events and print the categorized version. After starting the program, pressing the button multiple times and seeing the "up" and "down" events, it will randomly stop detecting events. It seems as though there is a timing or buffer issue. How can I prevent it from missing button presses?
from evdev import InputDevice, categorize, ecodes
dev = InputDevice('/dev/input/event0')
print(dev)
dev.grab()
for event in dev.read_loop():
if event.type == ecodes.EV_KEY:
cat = categorize(event)
print(cat)Reacted by Markus Ressel
Activity
gvalkov commentedon Oct 14, 2018
Hi @nicholsonjf . Very interesting - it shouldn't do that :). Could you please check if events are dropped when using a tool like evtest?
siikamiika commentedon Nov 3, 2018
I had a similar issue in the past when I tried to handle events from a 1000 Hz mouse and a keyboard at the same time. I can't reproduce it now, but I remember that for example when I was moving the mouse and clicked at the same time, the click event would sometimes get lost. The situation improved a lot when I added a 0.5 ms sleep after each
select()in a loop like this example https://python-evdev.readthedocs.io/en/latest/tutorial.html#reading-events-from-multiple-devices-using-selectbiblicabeebli commentedon Mar 31, 2019
Similar experience here, I eventually had to build my own loop. I found that using device_read_many inside a loop works.
Worryingly though, my use-case is just regular keyboard processes, and it doesn't take much to trigger.
How to replicate:
Code structure:
(Note that the code will crash if there was an up event without a preceding down event. Don't forget that you may be holding down a key when you start running the script. Failing to realize that will drive you mad while trying to debug it. :b)
(And sorry, I don't have the snippet I used to prove there were dropped events anymore. It was a truncated version of a larger program I was/am working on, it only processes keyboard input.)
Physical actions:
Was able to replicate on Ubuntu 18.04. Ubuntu 18.10, and Fedora 29.
Let me know if I can help or if you would like me to run a test on that thinkpad....
gvalkov commentedon Apr 7, 2019
Hi @biblicabeebli. Thanks for the thorough analysis. Just wanted to let you know that I'm really low on bandwidth these days and I haven't been able to troubleshoot this :(
DanielJoyce commentedon Dec 28, 2019
You were probably forgetting to handle SYN_DROPPED properly. The kernel will inject one if the buffer is overflowed.
markusressel commentedon Oct 16, 2020
I am facing a similar issue with the asyncio variant:
I am trying to read key events from a USB barcode scanner, which spits out key events really fast when scanning a barcode. While most of the time the barcodes go though fine, sometimes they are just chopped off. Interestingly it seems to always happen at the same location, f.ex:
When scanning a barcode that is supposed to look like this:
when it is chopped off it is always looking like this:
so only the last three digits survive.
cmantaras commentedon Apr 13, 2021
HI! I am getting the same issue with a QR reader.
Any solution?
Thanks a lot
cmantaras commentedon Apr 13, 2021
I have another question, after getting the whole string from de qr. how can i stop getting more events for 5 seconds. I could nt do this, I tried time.sleep(5), sync methods, global variables, and always the loop still listening the port.
markusressel commentedon Apr 13, 2021
No solution, but I am actually using the sync api variant inside of an async executor instead of the async api since it has a much higher success rate. Its also not perfect though.
The commit diff is here: markusressel/barcode-server@20bc3f1
Your other question is off topic and should be a different/new issue.