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

[Juan Zhao]

Thank you very much for your review. :)

On Tue, 2012-01-10 at 13:42 +0200, Pekka Paalanen wrote:

> 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.
"None" means no need for the compositor to do any work here,  it is useful 
in case that client want to re-layout  his UI components to fullscreen. 
Re-layout means rearrange the contents of that client other than scaling.

For example, the current terminal demo code. It does the fullscreen
itself.  
Another example, when set the video window to fullscreen, the detailed
operation can be decided by video app, and no need for the compositor to
scale or change mode. For example, the scaling from 720X576 to 1024X768
of a video data is handled by video driver. When they set fullscreen,
they do not hope compositor to do anything. The video driver can make
the decision how to scale it.

For your concern, I think we can add one "auto" to give the decision of
choosing one for the compositor.

> "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. 
Yeah.

> Scaling
> would always preserve surface's aspect ratio. The surface is centered.
Good idea, we need to preserve aspect ratio.  Some following patches are
needed. 


> 
> "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.
Yeah, agree.

> 
> "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.
Agree. Some following patches are needed for size do not match.


> 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. 
I'm not sure I catch your idea here. I would like to make it on the
center jus t like fill mode when the surface size do not match any mode.


> The aim of "force" mode is to be fast to render.
Agree

Thank you so much again!
Juan
> 
> Juan, do these match your ideas?
> krh, are we making sense?
> 
> 
> - pq