[protocol PATCH v3 1/2] add parameters to fullscreen
juan.j.zhao at linux.intel.com
Mon Jan 16 21:25:27 PST 2012
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, and I removed this sentence. Not send that configure for now in the
other 3 cases for now.
> 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.
If the full-screen window is not top-most, the compositor won't change
> >> "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.
If the client ignores or disobeys the configure event, the compositor
will use this FILL method.
And please ignore v4 version, I will send v5 version later soon. :)
More information about the wayland-devel