[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.
Anyways.
I've made a little progress with xwayland, testing on both -intel and
-wlshm drivers. Here are the WIP trees:
http://cgit.freedesktop.org/~vignatti/xserver/log/?h=xwayland-1.12
http://cgit.freedesktop.org/~vignatti/weston/log/?h=xserver
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!
Tiago
More information about the wayland-devel
mailing list