Hi,
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,
xf86VTSwitch()).
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.
Tiago
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
