[PATCH 2/2] evdev: open in nonblocking mode

[Tiago Vignatti]

On 03/15/2012 05:26 AM, Ander Conselvan de Oliveira wrote:
> On 03/14/2012 08:29 PM, Tiago Vignatti wrote:
>> mtdev exposed an issue in which device fd blocks inside the library
>> freezing
>> Weston:
>>
>> 0x004d696e in mtdev_fetch_event (dev=0x9fe64a8, fd=19, ev=0xbfda3438)
>> 0x004d6a77 in mtdev_get (dev=0x9fe64a8, fd=19, ev=0xbfda3478, ev_max=8)
>> 0x0097720b in evdev_input_device_data (fd=19, mask=1, data=0xa1ca9c8)
>> 0x00182e89 in wl_event_source_fd_dispatch (source=0xa2087b0,
>> ep=0xbfda3560)
>> 0x001838ea in wl_event_loop_dispatch (loop=0xa218768, timeout=0)
>
> That's weird. wl_event_loop_dispatch() uses epoll to check if there is
> something to read on the fd, so evdev_input_device_data() should not be
> called if the read would block.
>
> I saw the NUM_EVENTS define on the previous patch and it looks to me
> that you're trying to read more events than there are available in the
> fd. If that is correct, then this problem was actually introduced by the
> use of mtdev, not exposed by it. In that case, I guess that there should
> be a comment on the code and the commit message stating that in order to
> use mtdev, the fd needs to be on non-blocking mode. And maybe it would
> make sense to squash this to the previous patch.

"read() attempts to read up to count bytes", where in Weston, count is 
precisely 128 and in practice I see it returning random amounts between 
32-128. OTOH, in mtdev_get() when O_NONBLOCK is not set, it tries to 
fill exactly all 128 bytes otherwise it blocks. So there's nothing wrong 
really.

But in fact the issue wasn't _exposed_ by mtdev, but it's just the way 
the library works. I'll merge both patches and make a note about it.

Thanks for checking Ander.

   Tiago