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

[Pekka Paalanen]

On Mon, 16 Jan 2012 11:38:13 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen wrote:

Odd, there are no quotes from me...

> >> 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?

No, set_fullscreen should *always* send the configure event, it will
make the protocol more uniform, and it lets the client know what the
expected size would be for 1:1 pixels in full screen.

The scaling mode is only a *hint*, it should not affect the protocol
flow.

> 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?

There is no synchronization issue that I see, I already sketched the
deferring you mention in my earlier post, and it must apply to all
scaling modes:

When the compositor receives set_fullscreen, it does nothing visible to
the user. The surface is and behaves just like it was. The compositor
will send the configure event, telling the client in what size it
should render to cover the full screen with 1:1 pixel relation.

A sane client, after calling set_fullscreen, will not render anything
immediately. It will wait for the configure event, so it can check e.g.
the expected aspect ratio. Only then it decides the size of its buffer,
creates the new buffer, renders into it, and attaches it to the surface.

Only at the buffer attach time the compositor will visibly act on the
fullscreen mode.

The client will know the "size of the monitor" via the configure event.
So far, it does not know which output it is. I do not know if we ever
need such information, especially if we can solve the
compositor-internal problem of selecting the output for a surface that
starts as fullscreen or maximised.

If a client does not wait for the configure event, but already renders
a buffer and attaches it right after set_fullscreen, that is no problem
for the compositor, it just works as it always does. If the client
reacts to the configure event after the first frame and causes flicker,
that's the client's problem (bug).

> >> "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.

Sure, after all, it is only a hint with the aim for performance, with
the downsides of possible delays in setting it up (e.g. video mode
switching) and visual artifacts (the black borders, video mode
switching flicker).

> 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.

Yes, that is what I tried to say, I mixed up the terms "active"
and "top-most".

> >> "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.

Thinking about it again, that does make sense. I guess I don't have a
strong opinion about it, since it is about clients not knowing what
they want, if they don't obey the configure event.

My idea for "default" was that it can be a user preference in the
compositor settings. Is there no need for such thing? Maybe not.

User preferences in the compositor settings could also be used to
modify the actions on the other modes, for instance if a user
never wants to switch video modes even if it was more performant.

Unlike the X server, a Wayland compositor can and will contain policy,
that may override clients' wishes, because the compositor is not only
the graphics presentation server but also the window manager, and
possibly even more of the DE components.


Thanks,
pq