Re: [AD] EVDEV mouse driver

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> As you suggested, i've re-written the mouse detection in the setup using
> select (I didn't use it at first because i didn't thought of it).

Thanks. Applied with one modification: contrary to what I suggested, one 
can't use a NULL timeout in the data reading loop because the blocking call 
to select() prevents the loop from being interrupted by a keypress 
(multi-threaded version of the library). So I put a zero timeout there too.

> I simply described what I saw, I didn't understand what happened. I still
> don't, but I can describe more precisely: it seems that no data can be
> read during the flushing loop, even when there are data to be read (i.e.
> select returns 0).  But data is correctly read during the next loop (for
> (count = 0; ...).
>
> Noting that one of the functions called between the two loops is vsync,
> I've tried some poke and hope programing.  It seems that calling vsync
> before the flush loop makes this loop able to read the devices, sometimes,
> apparently depending on the exact place of the vsync. Is the problem due
> to some subtle interaction between timer and select ? (I'm using Allegro
> 4.1.9 with sigalarm and fbcon without vsync, glibc 2.2.4)

Weird. I don't know what happens at all.

> Either that, or I've made a very stupid bug somewhere: it's the first time
> I use select.

I don't see any.

> Anyway, the flush loop doesn't usually discard much data (when it works):
> at most a few bytes for my lps2 mouse and at most two events (32 bytes)
> for the tablet.

Yep, I experience a similar problem: when I click on the 'Detect' button 
while still moving the mouse, the progress bar is already partially filled 
when it shows up. Moving the line

   popup(uconvert_ascii("Move your mouse around", tmp1),
	uconvert_ascii("Press any key to cancel", tmp2));

before the flush loop seems to solve the problem. Is it the case for you too?

-- 
Eric Botcazou