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 > <[email protected]> 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 <[email protected]> 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?= <[email protected]> >>> 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 >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> _______________________________________________ >> wayland-devel mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
