[PATCH] src/shell.c: set black_surface->width and height

[Kristian Høgsberg]

On Fri, Nov 29, 2013 at 10:10:00AM +0200, Pekka Paalanen wrote:
> On Fri, 29 Nov 2013 11:18:14 +0800
> Xiong Zhang <xiong.y.zhang at intel.com> wrote:
> 
> > From: XiongZhang <xiong.y.zhang at intel.com>
> > 
> > full screen black_surface doesn't have associated wl_buffer, so
> > black_surface->width and height can't get value through
> > weston_surface_commit(). then weston_surface_damage(black_surface)
> > will be wrong in shell_stack_fullscreen(), the result is that we 
> > can't see a full screen view whe APP window's size isn't equal to 
> > output's size like running weston-gears
> > 
> > Signed-off-by: Xiong Zhang <xiong.y.zhang at intel.com>
> > ---
> >  src/shell.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/src/shell.c b/src/shell.c
> > index 605f090..ebcf3e2 100644
> > --- a/src/shell.c
> > +++ b/src/shell.c
> > @@ -2254,6 +2254,8 @@ create_black_surface(struct weston_compositor
> > *ec, pixman_region32_init_rect(&surface->opaque, 0, 0, w, h);
> >  	pixman_region32_fini(&surface->input);
> >  	pixman_region32_init_rect(&surface->input, 0, 0, w, h);
> > +	surface->width = w;
> > +	surface->height = h;
> >  
> >  	weston_view_configure(view, x, y, w, h);
> >  
> 
> I wonder if the surface size should be given as arguments to
> weston_surface_set_color() with a possibly more descriptive function
> name. A function, that would imitate committing a solid color
> buffer to a weston_surface.
> 
> OTOH, solid color surfaces do not go through the configure hook either,
> so I'm not sure that makes sense.
> 
> Actually I once tried to clean up these things, among the attempts
> there is
> http://cgit.collabora.com/git/user/pq/weston.git/commit/?h=clipscale-wip&id=a1f3c20a0dfcbcf30e96a99928c923a7a2ab396c
> I never proposed that patch on the list, because the whole series was
> quickly going down the rabbit hole, and particularly I wasn't sure
> whose responsibility it is to call weston_view_geometry_dirty().
> 
> But maybe it would give some ideas. I think simply setting
> surface->width,height like you propose is prone to forgetting updating
> some dependent state.
> 
> Also, IIRC jekstrand was working on removing weston_view::width,height,
> which means that this weston_surface::width,height issue would be fixed
> in the process.
> 
> As a stop-gap measure, I guess your patch is fine, though. It certainly
> looks needed.

Indeed, patch committed.

Kristian