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

[Juan Zhao]

On Mon, 2012-01-16 at 11:38 -0800, Bill Spitzak wrote:
> 
> Pekka Paalanen 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 assume these other three do *not* send configure events, but that the 
> compositor is expected to deal with the current size of the surface?
Yes, for now the other 3 method do not send configure events but the
compositor scale or change mode or fill the fullscreen surface.
> 
> Any ideas about synchronization of the change to full screen and the 
> clients setting of the window size? 
This won't be a problem for "driver" and "fill". But for the compositor
scale the surface, the draw surface size and the real surface is not the
same. If the client want to scale it by itself, it should use "default"
method.

> The compositor must not show either 
> the previous size of the window with the fullscreen scaling, or show the 
> new size of the window without the fullscreen scaling. 
By "default","driver" and "fill" method, the compositor will show the
surface size.
By "scale" method, the compositor will show the fullscreen surface
according to the output mode and with aspect ratio.

> This is the main 
> reason I believe this will not work without the clients knowing the size 
> of the monitors. 
Only by when "scale" method, the clients do not know the draw size which
I did not implemented in v1 version. But after discussion, I think, yes,
the client may have such requirement, we need it. And then I add this
method.

> However perhaps "default" can actually defer the 
> fullscreen until the client responds to the configure request?
> 
> >> "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.
> 
> I think this should also allow the compositor to do scaling if it thinks 
> it is fast enough, and to choose other scales (such as integers only) 
> that will make the window bigger but not fill the screen.
> 
> If the window is not top-most then the compositor should fake the 
> appearance it would have as closely as possible, while allowing 
> overlapping windows to be shown in the native mode.
> 
> >> "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.
> 
> I think this should be defined as the behavior for "default" if the 
> client ignores or disobeys the configure event. The reason is so that 
> the behavior is as similar as possible to normal windows when clents 
> ignore the configure event.
In the default method, if the client ignore or disobeys the configure
event, the compositor will use "fill" method to draw this fullscreen
surface.

Please ignore my v4 version, I will send updated v5 version soon:)

Thanks,
Juan