Weston under X crashes

Kristian Høgsberg krh at bitplanet.net
Tue Oct 23 07:56:21 PDT 2012


On Tue, Oct 23, 2012 at 6:35 AM, John Kåre Alsaker
<john.kare.alsaker at gmail.com> wrote:
> I also submitted a patch for this[1], although Kristian argued that it
> wouldn't happen in practice. It probably shouldn't trigger if nothing
> happened to the outputs. If just moving the cursor around triggers
> this, it may be a bug elsewhere.

No, I didn't say it wouldn't happen in practice, I know it does.  What
I said is that it's a bug else where.  Your example of hotplugging is
a valid case, but that's not what happening currently...  Actually, I
think I know what's happening.  I've only heard about this bug under
tiliing wms, which all typically force a window to be a different size
than what the app wants/suggests.  I case of weston, that means that
we may get input events outside the area of the wayland output.  So
the fix in this case would be to just discard enter and motion events
until the pointer is actually inside the output rectangle, and then
synthesize the enter once it really enters and only send motion events
from that point on.

Kristian

> [1] http://lists.freedesktop.org/archives/wayland-devel/2012-October/005916.html
>
> On Thu, Oct 11, 2012 at 4:14 PM, Niklas Hambüchen <mail at nh2.me> wrote:
>> Running src/weston and moving around the weston window with my tiling
>> window manager (i3) while moving the mouse sometimes makes it segfault
>> for me.
>>
>> The patch below seems to fix it for me; what breaks is the line
>>
>>         if (!valid && prev != NULL) {
>>                 if (x < prev->x)
>>
>> in clip_pointer_motion() because none of the
>>
>>                 if (pixman_region32_contains_point(&output->region,
>>                                                    x, y, NULL)) ...
>>                 if (pixman_region32_contains_point(&output->region,
>>                                                    old_x, old_y, NULL))
>>
>> actually matches so that prev == NULL.
>>
>> I don't really know the hidden assumption behind this (no comments, yay
>> ;)) - I guess it assumes that either the current or the old x/y are
>> within the region, which doesn't seem to be the case for me.
>>
>> Niklas
>>
>>
>> PS: Once again, I have no clue if the patch is actually the right thing
>> to do.
>>
>> From 9a595282ba798ad388576bcbbc53ab970983c956 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?Niklas=20Hamb=C3=BCchen?= <mail at nh2.me>
>> Date: Thu, 11 Oct 2012 15:04:57 +0100
>> Subject: [PATCH] clip_pointer_motion: Cope for old_x/y not being in the
>>  output region either
>>
>> ---
>>  src/compositor.c |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/compositor.c b/src/compositor.c
>> index eac805d..991ecdd 100644
>> --- a/src/compositor.c
>> +++ b/src/compositor.c
>> @@ -1433,7 +1433,7 @@ clip_pointer_motion(struct weston_seat *seat,
>> wl_fixed_t *fx, wl_fixed_t *fy)
>>                         prev = output;
>>         }
>>
>> -       if (!valid) {
>> +       if (!valid && prev != NULL) {
>>                 if (x < prev->x)
>>                         *fx = wl_fixed_from_int(prev->x);
>>                 else if (x >= prev->x + prev->width)
>> --
>> 1.7.9.5
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel


More information about the wayland-devel mailing list