When the pointer is hovering over a desktop-shell launcher icon, it displays a tooltip. If you leave the pointer in this state and let Weston enter idle, and then wake Weston, the unlock dialog does not respond to user interactions. This does not seem to happen when the pointer is in other positions. I am able to reproduce this on both X11 and DRM backends. This does not happen with Weston 1.3.1, so this is a regression somewhere in master. wayland (master) heads/master-0-g1521c62 drm (master) libdrm-2.4.50-0-g4c5de72 mesa (master) heads/master-0-g0319ea9 libva (master) heads/master-0-g73a11b3 intel-driver (master) heads/master-0-g9d0bd94 weston (master) heads/master-0-g8d344a0
Turns out that when any tooltip or context menu exists during idle or attempting to activate a context menu from the unlock dialog toolbar triggers this issue.
commit a1df7acb78e0fde8eb3165a0e1c1a77da50ea651 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Tue Dec 31 15:01:01 2013 -0800 shell: Set state_changed when we make a surface transient If we don't mark the state as changed, we don't copy over next_state to state and we fail to treat the surface as a transient. In particular, we give it a random intial position instead of mapping it at the given parent relative position. https://bugs.freedesktop.org/show_bug.cgi?id=72532
Oops, wrong bug.
This appears to be fixed now. Tested on weston master 917711bd59b089b9
whoops, reopening... this is still an issue when using mesa master. Works fine with mesa <= 10.0.
There's a mesa part to this which I'll send to the mesa list for review. The weston part is this, but doesn't by itself solve the problem. commit 27d5fa892229ab5cf4203e563eafce41f1bdfa0e Author: Kristian Høgsberg <krh@bitplanet.net> Date: Fri Jan 17 16:22:50 2014 -0800 shell: Cancel popups when triggering screensaver This is part of the fix for bug 72540. We cancel the popup grab when the screensaver kicks in so that the screen unlock dialog can get input events. The bigger problem is in mesa however, where we try to allocate new buffers as cairo-gles2 does a gratuituous (but valid) eglMakeCurrent() as we remove the tooltip or popup-menu. Since we removed the weston_layer with the regular surfaces, EGL blocks waiting for a frame event that never comes. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72540
I pushed this to mesa master, which along with the weston commit in comment 6 fixes this problem. commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Fri Jan 17 16:55:31 2014 -0800 i965: Only update renderbuffers on initial intelMakeCurrent We call intel_prepare_render() in intelMakeCurrent() to make sure we have renderbuffers before calling _mesa_make_current(). The only reason we do this is so that we can have valid defaults for width and height. If we already have buffers for the drawable we're making current, we don't need this step. In itself, this is a small optimization, but it also avoids a round trip that could block on the display server in a unexpected place. https://bugs.freedesktop.org/show_bug.cgi?id=72540 https://bugs.freedesktop.org/show_bug.cgi?id=72612 Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.