[protocol PATCH v2 1/2] add parameters for set_fullscreen

[Pekka Paalanen]

On Mon,  9 Jan 2012 22:50:20 +0800
juan.j.zhao at linux.intel.com wrote:

> From: Alex Wu <zhiwen.wu at linux.intel.com>
> 
> framerate: the expected framerate which will be used as refresh value to choose display mode.
> flags:     indicate how to deal with resolution dismatch.
>   support three methods:
>   "SCALE" means the compositor will scale the surface to the fullscreen.
>   "FORCE" means changing the screen resolution to the mode of the surface.
>     If there is no matched mode, just fallback to FILL mode.
>   "FILL" means changing fill the around of the surface to match the screen's
>     currently, we will put the surface in the center of the screen.
> 
> Signed-off-by: Juan Zhao <juan.j.zhao at linux.intel.com>
> Signed-off-by: Alex Wu <zhiwen.wu at linux.intel.com>
> 
> ---
>  protocol/wayland.xml |   12 +++++++++++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 78d4734..041c607 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -345,7 +345,17 @@
>           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"/>
> +    <request name="set_fullscreen">
> +      <arg name="framerate" type="uint"/>
> +      <arg name="flags" type="uint"/>

Could call it "method" instead of "flags" so the relation to enum
fullscreen_method would be obvious, right?

> +    </request>

I think we should document here, that framerate and flags are only hints
to the compositor, and framerate=0 means that the app does not care
about framerate.

> +
> +    <enum name="fullscreen_mothed">

Typo, should say method.

> +      <entry name="none" value="0"/>
> +      <entry name="scale" value="1"/>
> +      <entry name="force" value="2"/>
> +      <entry name="fill" value="3"/>
> +    </enum>

These could also use commentary on what they mean. My suggestion of them
is the following.

"none" means the application does not care what method a compositor
uses, so the compositor would probably choose either the cheapest
(fill? no-fill?) or the best desktop-integrated user experience (scale?)
method.

"scale" is for preferring scaling in the compositor, the application
really would like to fill the whole screen, even if it renders a buffer
that is too small. The compositor might (be configured to) also switch
the video mode, if it wants to scan out the client surface. Scaling
would always preserve surface's aspect ratio. The surface is centered.

"fill" is for black borders. The application does not want other apps
showing at all, and it does not want to be scaled, because it might
look bad. This would be preferring 1:1 pixel mapping in the monitor
native video mode. The surface is centered.

"force" is like "scale", the application wants to fill the whole
monitor, regardless of what size it renders its buffers in. The
preference is to switch video mode to the smallest mode that can fit
the client buffer. In the optimal case, the buffer size matches a video
mode, and will be scanned out directly. If the sizes do not match,
black borders are added, either by compositing or by the video driver.
The position of the surface on an output is not defined here,
possibly allowing the video driver to scan out a surface smaller than
the video mode. The aim of "force" mode is to be fast to render.

Juan, do these match your ideas?
krh, are we making sense?


- pq