[PATCH 2/2] evdev: open in nonblocking mode
tiago.vignatti at linux.intel.com
Fri Mar 16 13:29:20 PDT 2012
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
>> 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,
>> 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
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.
More information about the wayland-devel