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

Bill Spitzak spitzak at gmail.com
Mon Jan 16 11:38:13 PST 2012

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?

Any ideas about synchronization of the change to full screen and the 
clients setting of the window size? 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. This is the main 
reason I believe this will not work without the clients knowing the size 
of the monitors. 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.

More information about the wayland-devel mailing list