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

Fri Mar 7 15:05:54 PST 2014

On Mar 7, 2014 1:14 PM, "Bryce W. Harrington" <b.harrington at samsung.com>
wrote:
>
> 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.

I think there's some confusion as to the target clientel here.  I don't
intend for games of other "normal" apps to be running on this protocol.
The modesetting part in particular is inteded mainly for running a
compositor embedded inside another one.  Take another look at the 0'th
patch in the series.  I cover the use-cases in detail there.

Really, the question here isn't about turning scaling on/off, it's about
what to do with the wl_surface.buffer_scale that we already have.  If
wl_surface.buffer_scale == wl_output.scale then it's obvious.  If this is
not the case, it's not 100% clear what the right thing to do is here.

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

Yeah, I need to reword this.  I'll get it patched up.

>
> Bryce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140307/c8c0b220/attachment-0001.html>