Bug regarding evdev input and compositor focus
tiago.vignatti at linux.intel.com
Tue Dec 13 10:03:30 PST 2011
On 12/13/2011 07:30 PM, Ran Benita wrote:
> I was writing some input handling code for a separate program, when I
> stumbled into an issue and eventually decided to look at how wayland
> does it for inspiration. Unfortunately, wayland has a similar issue ;(
> The bug can be reproduced easily:
> - Start compositor-drm on some VT.
> - Switch to another VT.
> - Watch the CPU utilization go to 100%.
right, I see this :/
> In order to stop receiving input events when we VT switch out of wayland
> (i.e compositor->focus = false), the function evdev_input_device_data
> has a simple check:
> ec = device->master->base.compositor;
> if (!ec->focus)
> return 1;
> This check goes *before* the read(), the device fd always has data in
> it, the event loop keeps dispatching it, and we get into an endless
> loop until we get focus again.
> I guess there are a few ways to solve it:
> - Move the check after the read (not very nice).
> - Remove the fd from event loop when losing focus.
> - Close the fd altogether and re-open() when we get focus again.
> The latter is how X does it (see hw/xfree86/common/xf86Events.c,
The most favorable option is the last one probably. We don't want
Wayland owning any device (for safety reasons) and udev has to be free
to give them away to any other listener when performed a VT switched.
More information about the wayland-devel