I don't like it but, sure, it shouldn't break anything much further. --Jason
On Mon, Jun 30, 2014 at 2:10 AM, Pekka Paalanen <[email protected]> wrote: > From: Pekka Paalanen <[email protected]> > > If a client does this: > 1. create a main window and map it > 2. create a wl_surface, and make it a sub-surface of the main window > 3. set the sub-surface to desync > 4. commit content to the sub-surface to map it > > Then step 4 should cause the sub-surface to become mapped. However, > Weston fails to schedule a repaint in that case, so the sub-surface will > not appear until something else causes a repaint on that output, e.g. > the main window. > > A quick and dirty fix is to set the output mask for the surface in > Weston, which allows the repaint to be scheduled. This patch implements > that, and might only work right on single-output systems. > > A proper fix would involve rewriting the whole "is surface mapped" > mechanism in Weston, to not rely on output assignments but to have a > separate flag for "mapped", and figuring out how to schedule repaints > for the right outputs. > > Following is the actual protocol sequence used to trigger the problem: > > [3224648.125] -> [email protected]_surface(new id wl_surface@3) > [3224648.206] -> [email protected]_xdg_surface(new id xdg_surface@8, > wl_surface@3) > [3224648.311] -> [email protected]_title("simple-shm") > [3224648.378] -> [email protected](0, 0, 250, 250) > [3224649.888] -> [email protected]_pool(new id wl_shm_pool@9, fd 6, 250000) > [3224650.031] -> [email protected]_buffer(new id wl_buffer@10, 0, > 250, 250, 1000, 1) > [3224650.244] -> [email protected]() > [3224651.975] -> [email protected](wl_buffer@10, 0, 0) > [3224652.100] -> [email protected](20, 20, 210, 210) > [3224652.243] -> [email protected](new id wl_callback@11) > [3224652.317] -> [email protected]() > [3228652.535] -> [email protected]_surface(new id wl_surface@12) > [3228652.610] -> [email protected]_subsurface(new id > wl_subsurface@13, wl_surface@12, wl_surface@3) > [3228652.644] -> [email protected]_desync() > [3228652.659] -> [email protected]_position(100, 100) > [3228654.090] -> [email protected]_pool(new id wl_shm_pool@14, fd 6, > 250000) > [3228654.140] -> [email protected]_buffer(new id wl_buffer@15, 0, > 250, 250, 1000, 1) > [3228654.180] -> [email protected]() > [3228654.408] -> [email protected](wl_buffer@15, 0, 0) > [3228654.436] -> [email protected](0, 0, 250, 250) > [3228654.462] -> [email protected]() > > Signed-off-by: Pekka Paalanen <[email protected]> > Cc: George Kiagiadakis <[email protected]> > Cc: Jason Ekstrand <[email protected]> > > --- > > Do we want this patch in Weston upstream master or even 1.5 stable? > I am not sure when I would have time for the proper fix. > --- > src/compositor.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/src/compositor.c b/src/compositor.c > index fa8730f..d78314a 100644 > --- a/src/compositor.c > +++ b/src/compositor.c > @@ -2512,6 +2512,8 @@ subsurface_configure(struct weston_surface *surface, > int32_t dx, int32_t dy) > * will not be drawn either. > */ > if (!weston_surface_is_mapped(surface)) { > + struct weston_output *output; > + > /* Cannot call weston_surface_update_transform(), > * because that would call it also for the parent surface, > * which might not be mapped yet. That would lead to > @@ -2521,11 +2523,14 @@ subsurface_configure(struct weston_surface > *surface, int32_t dx, int32_t dy) > * Instead just assing any output, to make > * weston_surface_is_mapped() return true, so that when the > * parent surface does get mapped, this one will get > - * included, too. See surface_list_add(). > + * included, too. See view_list_add(). > */ > assert(!wl_list_empty(&compositor->output_list)); > - surface->output = > container_of(compositor->output_list.next, > - struct weston_output, link); > + output = container_of(compositor->output_list.next, > + struct weston_output, link); > + > + surface->output = output; > + weston_surface_update_output_mask(surface, 1 << > output->id); > } > } > > -- > 1.8.5.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
