[PATCH] evdev: fix input lag when processing input from output repaint

[Kristian Hoegsberg]

On Tue, Mar 20, 2012 at 09:36:33PM -0700, Chase Douglas wrote:
> On 03/20/2012 05:02 PM, Kristian Hoegsberg wrote:
> > On Tue, Mar 20, 2012 at 11:54:56AM +0200, Ander Conselvan de Oliveira wrote:
> >> When the compositor is in a repaint cycle, input is processed only once
> >> per frame. However, a call to evdev_input_device_data() would handle at
> >> most 8 events at time. When there was more than 8 events pending for a
> >> given frame, input lag would occur. This was most visible with multi
> >> touch input.
> >>
> >> This patch changes the evdev_input_device_data() so that it will handle
> >> all the events available in the fd. In order to do that, the fd is put
> >> in non-blocking mode, so that it is possible to loop on read and stop
> >> on EAGAIN instead of blocking.
> > 
> > Yikes, ok.  I think the patch is ok, though I'd prefer to make
> > wl_event_loop_dispatch() return "number of events dispatched" or maybe
> > just 1 if it dispatched any events, and then iterate until it returns
> > 0.  Since we already have to do O_NONBLOCK for mtdev, lets just go
> > with this (but I'll note for the record that I really don't like that
> > aspect of mtdev, and it doesn't have to do that).
> 
> I haven't really followed the discussion, but mtdev is fairly small. It
> probably wouldn't take too much to fix mtdev to behave correctly,
> however that is.

Yeah, it's a pretty small library, and it looks like it wouldn't be
too hard to change.  On the other hand, using O_NONBLOCK also works
and gets us the same result in the end.

Kristian