[RFC 1/5] Add a fullscreen shell protocol

[Jason Ekstrand]

On Thu, Oct 24, 2013 at 12:33 PM, Jonas Ådahl <jadahl at gmail.com> wrote:

> On Wed, Oct 23, 2013 at 06:08:29PM -0500, Jason Ekstrand wrote:
> > Jonas,
> > Thanks for the review!
> >
> > On Wed, Oct 23, 2013 at 3:56 PM, Jonas Ådahl <jadahl at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Using this protocol, how would the fullscreen shell client turn on and
> > > off outputs? I can see how clone, next-to and modeset by controlling
> > > what surface is presented and what fullscreen method is used, but that
> > > is not enough for turning an output off, isn't it?
> > >
> >
> > I think that would be done by simply calling present_surface with a null
> > surface to remove the surface from the output.  I'm not 100% sure how
> this
> > will interact with KMS surface detection, but hopefully we should be able
> > to make it that simple.
>
> I guess this could be added to the protocol clarifing what presenting a
> null-surface means disabling the output. What "disabling" means, could
> be up to the backend.
>
>
Yeah, I can make that more clear.  I'll send another draft here with things
stated better.


> >
> > > Another question is synchronising. Would a client ever want to change
> > > anything atomically? Do we need something like wl_surface.commit?
> > >
> >
> > I'm not sure what would get changed atomically.  There's only one
> operation
> > and different outputs will probably have different refresh rates so
> changes
> > won't be atomic anyway.  Or are you thinking about trying to future-proof
> > stuff?
> >
>
> Well, yea, atomically is probably not the correct term, and I don't know
> if the KMS backend support any such functionality. What I imagine is one
> might want to, for example, disable one output and enable another with
> minimal time in between, or maybe avoid ending up with no output enabled
> if the client would crash between calls. Might be overkill though, and
> if there is no real world use case right now, maybe even more so.
>

I think I would tend to say that this usually isn't really practical.  For
KMS, for instance, switching stuff around may make monitors turn on and
there's no way to make that atomic.  If the client is worried about being
on no outputs whatsoever, it can just set the one before removing the
other.  Then it will get the surface.enter before the surface.leave.


>
> Jonas
>
> >
> > >
> > > Also, one wording comment below.
> > >
> > > Thanks
> > >
> > > Jonas
> > >
> > >
> > > On Tue, Oct 22, 2013 at 08:48:25PM -0500, Jason Ekstrand wrote:
> > > > ---
> > > >  protocol/fullscreen-shell.xml | 44
> > > +++++++++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 44 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..b696828
> > > > --- /dev/null
> > > > +++ b/protocol/fullscreen-shell.xml
> > > > @@ -0,0 +1,44 @@
> > > > +<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 can only be bound to by one client at a time.
> > > > +    </description>
> > > > +
> > > > +    <enum name="fullscreen_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="scale" value="1" summary="scale, preserve the
> > > surface's aspect ratio and center on output"/>
> > > > +      <entry name="driver" value="2" summary="switch output mode to
> the
> > > smallest mode that can fit the surface, add black borders to compensate
> > > size mismatch"/>
> > > > +      <entry name="fill" value="3" summary="no upscaling, center on
> > > output and add black borders to compensate size mismatch"/>
> > > > +    </enum>
> > > > +
> > > > +    <request name="present_surface">
> > > > +      <description summary="present surface for display">
> > > > +     This requests the system compositor to display surface on
> output.
> > > > +     Each client of the system compositor can have at most one
> surface
> > >
> > > You still use the term 'system compositor' here. Also, it should be
> > > "display a surface" instead of "display surface".
> > >
> >
> > Thanks.  Good catch.  I've fixed it locally.
> >
> >
> > >
> > > > +     per output at any one time. Subsequent requests with the same
> > > > +     output replace the surface bound to that output.  The same
> surface
> > > > +     may be presented on multiple outputs.
> > > > +
> > > > +     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 specifies how the surface is to be persented.  These
> > > > +     methods are identical to those in
> wl_shell_surface.set_fullscreen.
> > > > +      </description>
> > > > +      <arg name="surface" type="object" interface="wl_surface"/>
> > > > +      <arg name="method" type="uint"/>
> > > > +      <arg name="framerate" type="uint"/>
> > > > +      <arg name="output" type="object" interface="wl_output"
> > > allow-null="true"/>
> > > > +    </request>
> > > > +  </interface>
> > > > +</protocol>
> > > > --
> > > > 1.8.3.1
> > > >
> > > > _______________________________________________
> > > > wayland-devel mailing list
> > > > wayland-devel at lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131024/56b2a572/attachment.html>