[PATCH 0/8] surface_attach() vfuncs

[Pekka Paalanen]

On Tue, 27 Mar 2012 17:36:34 +0300
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira at intel.com> wrote:

> Hi,
> 
> This series implements a vfunc for configuring a surface after an
> attach. The idea is that we don't want the shell to meddle with
> some surfaces such as drag surfaces, so the shell map() and
> configure() code is moved into shell and it sets the appropriate
> vfunc for a surface in wl_shell_get_shell_surface().
> 
> In order to do that, we need to provide a way for the shell to
> know whether a surface is mapped or not and also to be able to
> get float global coordinates for a surface. Hence the first two
> weston patches.
> 
> The third patch changes how es->pitch is set, making it depend
> only on the buffer size and not on the surface width. We can get
> rid of this once we start using GL_EXT_unpack_subimage for
> uploading textures for shm buffers.
> 
> The drag surface listener stuff is necessary to not break
> functionality once the vfuncs are implemented in the second to
> last patch.
> 
> wayland changes:
> 
> Ander Conselvan de Oliveira (1):
>   data-device: notify the compositor about new drag icons
> 
> weston changes:
> 
> Ander Conselvan de Oliveira (7):
>   compositor: add a weston_surface_is_mapped() helper
>   compositor: add weston_surface_to_global_float helper
>   compositor: make es->pitch consistent between shm and drm
> surfaces compositor: use new drag icon listener for setting up
> drag surfaces compositor: refactor surface_attach()
>   compositor: make surface_configure() a vfunc
>   compositor: move force_configure field to shell_surface

Hi,

I read through the series once, and could not find anything
obviously wrong, so looks good to me. :-)

In my opinion, we can't really rely on
surface->output <=> surface is mapped,
because screen lock takes the output away, but the surface
is still logically mapped. Would not make sense to compute
a new position for a mapped surface on attach, for instance.
But that might need fixing anyway, later.

The error messages in patch 7 could be more user friendly,
telling what happened in the protocol point of view. People
reading the error message probably do not know what
surface->configure is.


Thanks,
pq