[PATCH weston v4 01/15] Add a fullscreen shell protocol

[Bryce W. Harrington]

On Fri, Mar 07, 2014 at 11:31:16AM -0600, Jason Ekstrand wrote:
> > > +     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.

Guess I'm thinking more from the user perspective of having downloaded
some random client app off the internet that ignores this advice.

Presumably at least the damage is limited to the client's window.  I
guess that's my main concern - that some random app doesn't leave the
user's system borked up.

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

Ah, that's clearer.  Think I was confused by the word target; 'desired
framerate' would maybe be clearer.

So for your examples, if 50Hz was desired, then you'd pass
framerate="50000"?

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

Are the use cases here just HiDPI and fullscreen games?  If there are
other use cases they might shed light on the scope of the problem.
Would video players use it?

In particular is there any use case for having 1 physical pixel per N
logical pixels?  If there is, then perhaps let buffer_scale just be the
scaling factor, and have a separate parameter for toggling scaling on or
off?  Documentation-wise, having two parameters is going to be easier to
explain I think.

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

Right, or invalid modes...  -1x-1, 1000000x1000000, etc.

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

Gotcha, yeah so long as there's a list available then we can expect the
client to constrain itself to those.  How does the client request this
list?

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

It suggests the client could sleep(N) and try again.  If that is an
appropriate way to handle it then the wording's fine.  If it's not going
to be allowed for the given client, window, or surface at all, then
perhaps a more definitive wording would help the client.

Bryce