[PATCH v2] xwayland: Fix infinite loop on quick movement through menus

Tiago Vignatti tiago.vignatti at linux.intel.com
Fri Apr 27 10:47:28 PDT 2012

On 04/25/2012 05:34 PM, Kristian Hoegsberg wrote:
> On Wed, Apr 25, 2012 at 03:06:57PM +0200, Tomasz Borowik wrote:
>>  From 3abf39489deb3eb048174630dc7d41908674408b Mon Sep 17 00:00:00 2001
>> From: timon37<timon37 at lavabit.com>
>> Date: Wed, 25 Apr 2012 13:28:35 +0200
>> Subject: [PATCH] Fix infinite loop in xwl_screen_post_damage
>> Happens when first two windows are damaged, then later one is damaged and
>> the other is unrealized. It makes the damaged windows next point to itself.
> Ah, yes, good catch.
> The way we should fix this is that we just
>      xorg_list_init(&xwl_window->damage_link);
> in xwl_screen_post_damage() as we iterate list.  That way we can
> unconditional call xorg_list_del(&xwl_window->link_damage); as we do
> now.  If it's on the list, we take it out, if it's not on the list,
> it's a no-op.

yep, this seems cool. I'm facing issues while implementing popup menu 
now as well, but I'm not seeing any "infinite loop" as you described. 

I've made a little progress with xwayland, testing on both -intel and 
-wlshm drivers. Here are the WIP trees:


For tooltips, I took the Firefox's as example, and assumed that would 
always have a parent window. But now I'm seeing this's wrong, because 
for instance gnome-help have tooltips without parent. And that was a 
really lame assumption of mine, because tooltips even don't need a 
parent at all -- it follows the cursor. So what's the plan here? Do you 
think we need to add set_tooltip for wl_shell_surface interface? I'm 
interested also in hearing where we'll put UTILITY type of windows then.

have nice weekend all!


More information about the wayland-devel mailing list