[PATCH weston v4 01/15] Add a fullscreen shell protocol
Jason Ekstrand
jason at jlekstrand.net
Fri Mar 7 09:31:16 PST 2014
Hi Bryce,
Thanks for reviewing! I'll get the typo changes made and look into
canceled vs. cancelled. More comments below
On Mar 6, 2014 9:38 PM, "Bryce W. Harrington" <b.harrington at samsung.com>
wrote:
>
> On Tue, Feb 25, 2014 at 07:26:33PM -0600, Jason Ekstrand wrote:
> > Signed-off-by: Jason Ekstrand <jason at jlekstrand.net>
> > ---
> > protocol/fullscreen-shell.xml | 158
++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 158 insertions(+)
> > create mode 100644 protocol/fullscreen-shell.xml
> >
> > diff --git a/protocol/fullscreen-shell.xml
b/protocol/fullscreen-shell.xml
> > new file mode 100644
> > index 0000000..13bdfcf
> > --- /dev/null
> > +++ b/protocol/fullscreen-shell.xml
> > @@ -0,0 +1,158 @@
> > +<protocol name="fullscreen_shell">
> > + <interface name="wl_fullscreen_shell" version="1">
> > + <description summary="Displays a single surface per output">
> > + Displays a single surface per output.
> > +
> > + This interface provides a mechanism for a single client to
display
> > + simple full-screen surfaces. While there technically may be
multiple
> > + clients bound to this interface, only one of those clients
should be
> > + shown at a time.
> > +
> > + To present a surface, the client uses either the present_surface
or
> > + present_surface_for_mode requests. Presenting a surface takes
effect
> > + on the next wl_surface.commit. See the individual requests for
> > + details about scaling and mode switches.
> > +
> > + The client can have at most one surface per output at any time.
> > + Requesting a surface be presented on an output that already has a
> > + surface replaces the previously presented surface. Presenting a
null
> > + surface removes its content and effectively disables the output.
> > + Exactly what happens when an output is "disabled" is
> > + compositor-specific. The same surface may be presented multiple
>
> presented to multiple
>
> > + outputs simultaneously.
> > +
> > + Once a surface is presented on an output, it stays on that output
> > + until either the client removes it or the compositor destroys the
> > + output. This way, the client can update the output's contents by
> > + simply attaching a new buffer.
> > + </description>
> > +
> > + <request name="release" type="destructor">
> > + <description summary="release the wl_fullscreen_shell interface">
> > + Release the binding from the wl_fullscreen_shell interface
> > +
> > + This destroys the server-side object and frees this binding. If
> > + the client binds to wl_fullscreen_shell multiple times, it may
wish
> > + to free some of those bindings.
> > + </description>
> > + </request>
> > +
> > + <enum name="present_method">
> > + <description summary="different method to set the surface
fullscreen">
> > + Hints to indicate to the compositor how to deal with a conflict
> > + between the dimensions of the surface and the dimensions of the
> > + output. The compositor is free to ignore this parameter.
> > + </description>
> > + <entry name="default" value="0" summary="no preference, apply
default policy"/>
> > + <entry name="center" value="1" summary="center the surface on
the output"/>
> > + <entry name="zoom" value="2" summary="scale the surface,
preserving aspect ratio, to the largest size that will fit on the output" />
> > + <entry name="zoom_crop" value="3" summary="scale the surface,
preserving aspect ratio, to fully fill the output cropping if needed" />
> > + <entry name="stretch" value="4" summary="scale the surface to
the size of the output ignoring aspect ratio" />
> > + </enum>
> > +
> > + <request name="present_surface">
> > + <description summary="present surface for display">
> > + Present a surface on the given output.
> > +
> > + If the output is null, the compositor will present the surface on
> > + whatever display (or displays) it thinks best. In particular,
this
> > + may replace any or all surfaces currently presented so it should
> > + not be used in combination with placing surfaces on specific
> > + outputs.
> > +
> > + The method parameter is a hint to the compositor for how the
surface
> > + is to be presented. In particular, it tells the compostior how to
> > + handle a size mismatch between the presented surface and the
> > + output. The compositor is free to ignore this parameter.
> > +
> > + The "zoom", "zoom_crop", and "stretch" methods imply a scaling
> > + operation on the surface. This will override any kind of output
> > + scaling, so the buffer_scale property of the surface is
effectively
> > + ignored.
> > + </description>
> > + <arg name="surface" type="object" interface="wl_surface"
allow-null="true"/>
> > + <arg name="method" type="uint"/>
> > + <arg name="output" type="object" interface="wl_output"
allow-null="true"/>
> > + </request>
> > +
> > + <request name="present_surface_for_mode">
> > + <description summary="present surface for display at a
particular mode">
> > + Presents a surface on the given output for a particular mode.
> > +
> > + If the current size of the output differs from that of the
surface,
> > + the compositor will attempt to change the size of the output to
> > + match the surface. The result of the mode-swith operation will be
>
> mode-switch
>
> > + returned via the provided wl_fullscreen_shell_mode_feedback
object.
> > +
> > + If the current output mode matches the one requested or if the
> > + compositor successfully switches the mode to match the surface,
> > + then the mode_successfull event will be sent and the output will
>
> mode_successful event
>
> > + contain the contents of the given surface. If the compositor
> > + cannot match the output size to the surface size, the mode_failed
> > + will be sent and the output will contain the contents of the
> > + previously presented surface (if any). If another surface is
> > + presented on the given output before either of these has a chance
> > + to happen, the present_canceled event will be sent.
>
> present_cancelled
>
> Grepping weston for 'canceled' vs. 'cancelled' seems to indicate the
> latter spelling is preferred.
>
> > + If the size of the presented surface changes, the resulting output
> > + is undefined. The compositor may attempt to change the output
mode
> > + to compensate. However, there is no guarantee that a suitable
mode
> > + will be found and the client has no way to be notified of success
> > + or failure.
>
> Probably a stupid question but could the presented surface be locked to
> prevent it from changing size?
Not really. The client simply attaches buffers of some size or another and
the server has to take what the client gives it. That patagraph is
intended expressly to address this by telling the client "Don't do that!"
under threat of undefined results.
>
> > + The framerate parameter specifies the target framerate for the
> > + output. The compositor is free to ignore this parameter. A value
> > + of 0 indicates that the client has no preference.
>
> This doesn't actually define what the framerate parameter does. Does it
> do something if the framerate drops too low? Or does it cap it to not
> go above a certain level?
The output mode is given by three parameters: width, height, and
framerate. The framerate should be given in mHz (same as in
wl_output.mode) but maybe I should specify that. If the compositor states
that the given output supports, for instance 1024x768 at 60Hz and 1024x768 at 50Hz,
this lets the client specify which it would like. In most cases, the
client won't care which is why I have the 0 option. However, providing a
framerate option allows the client more-or-less full control over the
output mode.
>
> > + If the surface has a buffer_scale greater than 1, the compositor
> > + may choose a mode that matches either the buffer size or the
> > + surface size. In either case, the surface will fill the output.
>
> This paragraph is a bit confusing. Is buffer_scale a scaling factor?
Wayland provides an integer scale parameter for each output that tells the
client that the given output is actually scaled down. This is for HiDPI
displays where you may want 2 or 3 physical pixels per logical pixel. If
the output has a scale factor of 3, that means that every surface on that
output will be scaled up by a factor of 3. The buffer_scale option allows
the client to compensate in the same way as the buffer_transform option
allows it to compensate for a rotated output. If a surface has a
buffer_scale of 3 and a 600x900 buffer, then the size of the surface is
only 200x300 but it will be pixel-for-pixel exact on the output that's
scaled by 3.
The problem here is what to do with the buffer_scale factor. In the
example above, the client is providing a 600x900 buffer but the surface is
only 200x300. Which size should the compositor make the output? This gets
even stickier because the output modes provided by wl_output are given in
physical pixels without any transform or scale. As given, I chose to
explicitly not solve this problem and let the compositor choose. In
practice, I expect that most compositors won't provide any scale factor on
the output and the client just provides the surface size it wants.
Perhaps this isn't the best option. Would it be better defined if we just
stated that the compositor will try to match the output size to the surface
size? Then warn clients that the wl_output.scale factor may still get
applied. This may be a better option since the client will have to handle
the tramsform in a similar way.
Ultimately, if the client wants to control modesetting it should be either
a) using the same size and transform as the output or b) providing a
surface in output-space (after having transformed the mode from the
compositor) and letting the compositor transform/scale it. I'm not really
sure what's best to do here honestly. Suggestions are appreciated. I'll
think on it more.
>
> > + </description>
> > + <arg name="surface" type="object" interface="wl_surface"/>
> > + <arg name="output" type="object" interface="wl_output"/>
> > + <arg name="framerate" type="int"/>
> > + <arg name="feedback" type="new_id"
interface="wl_fullscreen_shell_mode_feedback"/>
> > + </request>
> > +
> > + <enum name="error">
> > + <description summary="wl_fullscreen_shell error values">
> > + These errors can be emitted in response to wl_fullscreen_shell
requests
> > + </description>
> > + <entry name="invalid_method" value="0" summary="present_method
is not known"/>
> > + </enum>
> > + </interface>
> > +
> > + <interface name="wl_fullscreen_shell_mode_feedback" version="1">
> > + <event name="mode_successful">
> > + <description summary="mode switch succeeded">
> > + This event indicates that the attempted mode switch operation was
> > + successful. A surface of the size requested in the mode switch
> > + will fill the output without scaling.
> > +
> > + Upon recieving this event, the client should destroy the
> receiving
>
> > + wl_fullscreen_shell_mode_feedback object.
> > + </description>
> > + </event>
> > + <event name="mode_failed">
> > + <description summary="mode switch failed">
> > + This event indicates that the attempted mode switch operation
> > + failed. This may be because the requested output mode is not
> > + possible or it may mean that the compositor does not want to allow
> > + mode switches at this time.
>
> Would it be worth returning these two failure modes as distinct events?
> Might help client developers in debugging if nothing else.
>
> If lets say a game client wanted to do a mode change, would it make
> sense for them to do a series of present_surface_for_mode calls and
> keep trying different modes while they receive mode_failed events?
> Or is there a way for them to query for allowed modes that they can
> select from?
Ok, first off games aren't really the intended clientel. I don't think
this is really an issue. Allow me to elaborate. I expect that the
compositor will have one of two basic modes of operation. First, is to
allow you to set any mode at all. This is likely to be the case for
streaming/recording compositors where there is no physical output. Second
is that it has some list of modes and allows you to select one. In the
first case, it should always succeed unless the compositor has some rule
such as "you can only set this once". In the second case, you can go ahead
and try to set whatever you want, but it might not work. However, if it's
an advertised mode and the transform and scale match (see above) you should
expect it to work.
If a client wants to run at some exotic resolution, I expect it to try that
and, if it fails, pick the best resolution from the advertised modes and
then try that.
I still want to leave the compositor a bit of a way out if there's a
problem. Perhaps "does not allow mode switches at this time" is a bad way
to put it.
Thanks,
-- Jason Ekstrand
>
> > +
> > + Upon recieving this event, the client should destroy the
> receiving
>
> > + wl_fullscreen_shell_mode_feedback object.
> > + </description>
> > + </event>
> > + <event name="present_canceled">
> present_cancelled
>
> > + <description summary="mode switch canceled">
> mode switch cancelled
>
> > + This event indicates that the attempted mode switch operation was
> > + canceled. Most likely this is because the client requested a
> cancelled
>
> > + second mode switch before the first one completed.
> > +
> > + Upon recieving this event, the client should destroy the
> receiving
>
> > + wl_fullscreen_shell_mode_feedback object.
> > + </description>
> > + </event>
> > + </interface>
> > +</protocol>
> > --
> > 1.8.5.3
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
> Apart from a few typos here and there, the docs are very coherent and
> understandable.
>
> Reviewed-by: Bryce Harrington <b.harrington at samsung.com>
>
> Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140307/60b7ff98/attachment-0001.html>
More information about the wayland-devel
mailing list