[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