Weston under X crashes

[Niklas Hambüchen]

Can we make X Weston test-wise draw some fancy stuff into regions it is 
forced to fill up in tiling WMs? That would make reproducing this a 
little bit easier.

On Tue 23 Oct 2012 15:56:21 BST, Kristian Høgsberg wrote:
> 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