[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] loss of rapidly repeated keypresses (from a barcode gun keyboard)



On Thu, Dec 03, 2009 at 05:04:05PM +0000, René Dudfield wrote:
>    Hi,
> 
>    I think this has to do with SDL and xevents.  It's possible SDL can lose
>    events if they come in too fast.  Since it tries to prevent flooding of
>    the event queue.  Well it does for mouse events anyway.
> 
>    I can't remember if they fixed/changed stuff for the recent 1.2.14
>    release... but it's worth trying out if you haven't already.

Interesting. My main Linux testing box has SDL 1.2.13. I'll give it a 
shot.

>    Also, maybe try out the 'xev' command - which prints x events.  Then you
>    can see if it is printing out all the events at the X level.
>    man xev

I just tried that, and no X events are being lost.

Oh, also, I figured out why I was getting almost universal failure in my 
test app but only the first scan was failing in my production app.

In the production app I was only testing with barcodes, and only the 
first scan would lose repeitious events.

In my simplified test app, I was actually switching between the barcode 
scanner and my regular keyboard. I would scan "22222223333333" and then 
I would type "z" to have a visual delimiter between that and the next 
scan. When I did that, almost every single scan would lose events.

So it seems that SDL actually only loses events from the first scan 
after the main keyboard has been used.

I tested this further, by launching my test.py script, testing it, then 
closing it only using the mouse, then running it again only using the 
mouse. Then the first scan did NOT lose events.

This is very encouraging to me, since it means that solving this problem 
or working around it is no longer a critical issue for me, since this 
barcode application is going to be running on an embedded computer with 
no main keyboard anyway..

But I do still want to solve this mystery from a mystery-solving 
perspective. I just no longer need to solve it from a 
getting-my-work-done perspective :)

---
James