wl_output ambiguity, xdg_shell fullscreen refresh rate

[Pekka Paalanen]

On Mon, 15 May 2017 17:51:16 +0200
Philipp Kerling <pkerling at casix.org> wrote:

> 2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました:
> > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:  
> > > On Sun, 14 May 2017 14:43:44 +0200
> > > Philipp Kerling <pkerling at casix.org> wrote:  
> > > >  * Am I correct in that if I use zxdg_toplevel (i.e. give this
> > > > role to
> > > >    a surface), I cannot also use wl_shell_surface? If so, this
> > > > would be  
> > > 
> > > Yes. wl_shell and xdg_shell suites of protocol extensions are
> > > mutually
> > > exclusive, you cannot use both for the same wl_surface. wl_shell is
> > > the
> > > deprecated one, and xdg_shell suite is the replacement waiting to
> > > be
> > > decleared stable.
> > >   
> > > >    quite a problem. I can see that zxdg_toplevel functionality is
> > > >    mostly superior to that of wl_shell_surface, but it has one
> > > > omission
> > > >    that is crucial for Kodi: the ability to request a specific
> > > > refresh
> > > >    rate for fullscreen display. This is needed for closely
> > > > matching the
> > > >    display and video FPS so duplicated and skipped frames are
> > > > kept to a
> > > >    minimum. Is this an intentional omission and/or is there
> > > > anything
> > > >    that provides this functionality?  
> > > 
> > > Hopefully the xdg_shell designers would answer that, but I believe
> > > it
> > > has been omitted for now to make it easier to declare the first
> > > fundamental parts of xdg_shell stable. It is missing a lot, but the
> > > foundation must agreed upon first before building more on top.  
> > 
> > Rather than combining the FPS request with fullscreening, wouldn't it
> > be
> > better to let applications set FPS as a property of the surface?
> > 
> > That way the client would make a promise that is is going to update
> > surface contents with periodic commits of the specified rate,
> > completely
> > independent of the actual output hardware or fullscreen state.
> > 
> > The server could use that information to choose the best display
> > refresh
> > rate even if not in fullscreen mode.  
> I would not want my compositor to do that, since changing the refresh
> rate means that the monitor will go blank for a while while resyncing
> on most hardware.

Hi,

I get the feeling that you are assuming the server would always obey the
client refresh rate. The protocol should not be designed like that.

Wayland protocol design principle for the desktops is that clients
describe what they would want to do (and why), and the server
implements the policy on when and how that actually happens - if at
all. This is very much the opposite from X11. A typical example is
input grabs: a client has to provide both the reason (the input event
they are acting on) and the context (the surface a grab will be tied
to). The server decides if it grants a grab or not, and if yes, it can
also revoke the grab at any time.

The reason the framerate was in the fullscreen request in wl_shell is
that fullscreen offers fairly clear conditions on when the server
should or could switch the video mode:
- when the fullscreen window becomes top-most and active, switch video
  mode to the client requested one
- when the fullscreen window becomes inactive, is hidden, or some other
  top-level window comes on top of it; a condition that is not just
  transient; switch video mode back to the default one
- do not switch back to default one for insignificant actions, e.g. a
  notification window appearing, window switcher starter but not yet
  chosen the next active window

If a custom video mode request can be made on any kind of window, it
becomes more hard to figure out the right situations when to switch -
if switching at all. The server always has to have the choice to not
switch at all, ever, e.g. if the hardware is incapable, would make the
screen blank for too long that it's annoying, or simply a policy set by
the user.

> Doing this on a regular basis would be very
> disturbing. Kodi can get away with it since
>  * it only does it when starting to play a video,
>  * it only does it in full-screen mode when nothing else is on the
>    screen anyway, and
>  * it has the option to wait a configurable amount of time before
>    starting playback to ensure that the mode switch is complete.

Those are the kind of things the display server could do, and often
things the client cannot do.

> But I can see how this is the more general solution and also supports
> the video playback use case. If this operation would include a
> recommendation that the compositor should try to closely match the
> requested framerate of currently displayed full-screen surfaces to the
> vertical refresh rate of the corresponding output, I guess it would be
> fine.

Yes, the server is required to be smart about it, or just plain
ignorant.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170516/e93b1d79/attachment.sig>