[PATCH] adding parameter for set_fullscreen

[Juan Zhao]

On Tue, 2012-01-03 at 11:54 -0800, Bill Spitzak wrote:
> 
> juan.j.zhao at linux.intel.com wrote:
> > From: Juan Zhao <juan.j.zhao at linux.intel.com>
> > 
> > support two methods:
> > "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 mode.
> >   currently, we will put the surface in the center of the screen.
> 
> I thought Wayland was going to be capable of scaling surfaces as part of 
> the compositing operation?
This scaling capability on the client side should be ready now. Just
have a look at terminal in clients, it uses scale mode in the client
itself. F11 to set fullscreen.

We are also considering the scaling capability of compositor side. It is
not a hard work to scale the surface, but the handling of input
according to that scale should be considered, which is not a easy task
in my current opinion. Need some suggestion for handling the input
issues for scaling the surface in the server side.

> 
> What I would prefer to see, rather than a special "fullscreen" mode, is 
> the ability to set the rectangle the client's surface is mapped to. 
We add such special "fullscreen" interface here, is to facilitate the
client's work for fullscreen setting. The client can set fullscreen only
by one command to express their preferred way.
For your concern, we can add (x, y) to specify the top-left coordination
for the fill mode. Now we map it on the center directly.
> Normally this will produce scaling, but if it is the only client visible 
> (because it fills a screen and there are none above it) the compositor 
> can then automatically switch the display mode to one that requires less 
> or no scaling.
Whether changing the display mode should be requested by the client but
not decided by the compositor. There are some applications which would
like to change the display mode to make itself fullscreen no matter
whether there is any other application. Like XBMC and Quake 3.
 


> Being able to scale a surface will allow video playback windows to be 
> scaled without bypassing the non-scaling video decompression hardware. I 
> would expect the windows to be scaled to the correct location and put 
> below the normal window where there is a hole of zero alpha so the video 
> shows through.
The multi-plane/overlay supporting should also be supported but not in
fullscreen protocol, we will add some other protocol for video HW
acceleration.

> 
> I would also really like Wayland to dump the idea that "fullscreen" is 
> somehow special. It just means there are no borders and the window edges 
> touch the edge of the monitor. There should be ZERO effect on window 
> stacking, and other windows should be able to be put atop the fullscreen 
> one. Please don't make overlapping windows useless.
Now this patch really did not add any borders for the window(in fact the
borders is added by the client itself), for fullscreen mode, we really
only draw that specific surface, the cursor and panel when necessarily.
So this should be ZERO effect on window stacking. 
Put some window atop the fullscreen one, we can take it into considered
combined with HW overlay/multiplane.

BRs
Juan