On Mon, 03 Feb 2014 16:16:29 +0200 Ander Conselvan de Oliveira <[email protected]> wrote:
> On 02/01/2014 10:00 AM, Pekka Paalanen wrote: > > On Fri, 31 Jan 2014 16:07:51 +0200 > > Ander Conselvan de Oliveira <[email protected]> > > wrote: > > > >> The input region of the cursor surface is set to empty in > >> pointer_cursor_surface_configure(). Since during the commit > >> process this function is called before the pending input region > >> is made current, it empties surface->pending.input instead of > >> surface->input. > >> > >> But pointer_cursor_surface_configure() is also called from > >> pointer_set_cursor() in order to map the cursor even if there > >> isn't a subsequent attach and commit to the cursor surface. In > >> that case, surface->input is never emptied, since the configure > >> function emptied only the pending input region and there wasn't a > >> commit that made it effective. > >> > >> Fix this by emptying both pending and current input regions. The > >> latter shouldn't cause problems since the surface can't have a > >> role prior to being assigned the cursor role, so it shouldn't be > >> mapped in the first place. > >> > >> Also change toytoolkit so that it triggers the bug. > >> > >> https://bugs.freedesktop.org/show_bug.cgi?id=73711 > >> --- ... > > > > I wonder, do we have a similar problem with drag icon surfaces? > > There isn't a problem because weston_pointer_start_drag() doesn't map > the drag icon. It takes an attach/commit to do it and at that point > emptying the pending input region does the trick. > > The protocol is not clear whether the surface should be > mapped/configured when the request is received. If we change this to > behave similarly to wl_pointer::set_cursor, then we need a similar > fix. > > I'm not sure if that change would make sense though. Since > wl_data_device::start_drag doesn't have a "hotspot" parameter, it is > necessary to set the offset from the pointer on the first attach, > unless that offset would be (0, 0). So if the drag_surface already > has a buffer, the client would have to first attach NULL to be able > to ensure the icon wouldn't be rendered in the wrong position due to > the attach that sets the offset being processed a frame later than > the start_drag request. Ok, your analysis makes perfect sense. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
