[protocol PATCH v3 1/2] add parameters to fullscreen

[Pekka Paalanen]

On Mon, 16 Jan 2012 01:20:51 +0800
juan.j.zhao at linux.intel.com wrote:

> From: Juan Zhao <juan.j.zhao at linux.intel.com>
> 
> Map the surface as a fullscreen surface. Four types are supported.
> "default" means the client has no preference on fullscreen
>           behavior, policies are determined by compositor.

>           The compositor will send a configure event to the
>           client.

I think the above sentence applies to set_fullscreen as a whole, not
just the default case.

> "scale"   means the client prefers scaling by the compositor.
>           Scaling would always preserve surface's aspect ratio.
>           And the surface is centered.
> "driver"  means the client wants to switch video mode to the
>           smallest mode that can fit the client buffer. If the
>           sizes do not match, black borders are added.
> "fill"    means the client wants to add blackborders to the
>           surface. This would be preferring 1:1 pixel mapping
>           in the monitor native video mode. The surface is
>           centered.
> 
> Signed-off-by: Juan Zhao <juan.j.zhao at linux.intel.com>
> Signed-off-by: Zhiwen Wu <zhiwen.wu at linux.intel.com>
> ---
>  protocol/wayland.xml |   43 ++++++++++++++++++++++++++++++++++---------
>  1 files changed, 34 insertions(+), 9 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index cdbbfd0..4a87309 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -336,15 +336,40 @@
>        <arg name="flags" type="uint"/>
>      </request>
>  
> -    <!-- Map the surface as a fullscreen surface.  There are a number
> -         of options here: on which output? if the surface size doesn't
> -         match the output size, do we scale, change resolution, or add
> -         black borders? is that something the client controls?  what
> -         about transient surfaces, do they float on top of the
> -         fullscreen? what if there's already a fullscreen surface on
> -         the output, maybe you can only go fullscreen if you're
> -         active?  -->
> -    <request name="set_fullscreen"/>
> +    <!-- Map the surface as a fullscreen surface. On the output the
> +         surface is assigned to. The client can use different fulllscreen
> +         method to fix the size mismatch issue: default, scale, driver
> +         and fill. The surface can only go fullscreen if it is active.

The last sentence above might be confusing, does it mean that I cannot
request set_fullscreen if my surface is not active? I know it does not
mean that, but maybe it could be reworded or removed.

If a fullscreen surface is not active, don't we just render panels and
other always-on-top-like desktop elements on top of it, without
touching the fullscreen surface presentation otherwise?

Maybe we could say that the surface needs to be active (hmm, what does
active mean, if we have multiple input groups?) for the fullscreen mode
to have full effect?

> +         And the framerate parameter is used for "driver" method, to
> +         indicate the preferred framerate. framerate=0 means that the app
> +         does not care about framerate -->
> +    <request name="set_fullscreen">
> +      <arg name="method" type="uint"/>
> +      <arg name="framerate" type="uint"/>
> +    </request>
> +
> +    <!-- Hints to indicate compositor how to deal with this fullscreen
> +         surface.
> +         "default" means the client has no preference on fullscreen
> +                   behavior, policies are determined by compositor.

> +                   The compositor will send a configure event to the
> +                   client.

I think the above sentence applies to set_fullscreen as a whole, not
just the default case.

> +         "scale"   means the client prefers scaling by the compositor.
> +                   Scaling would always preserve surface's aspect ratio.
> +                   And the surface is centered.
> +         "driver"  means the client wants to switch video mode to the
> +                   smallest mode that can fit the client buffer. If the
> +                   sizes do not match, black borders are added.
> +         "fill"    means the client wants to add blackborders to the
> +                   surface. This would be preferring 1:1 pixel mapping
> +                   in the monitor native video mode. The surface is
> +                   centered.-->
> +    <enum name="fullscreen_method">
> +      <entry name="default" value="0"/>
> +      <entry name="scale" value="1"/>
> +      <entry name="driver" value="2"/>
> +      <entry name="fill" value="3"/>
> +    </enum>
>  
>      <!-- Popup surfaces.  Will switch an implicit grab into
>           owner-events mode, and grab will continue after the implicit

Apart from the minor nitpicks above, FWIW I'm ok with this patch.
Good job!

Thanks,
pq