wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

Hi,

Am Dienstag, den 16.05.2017, 11:30 +0300 schrieb 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.
I actually don't and I think I explicitly stated that in an earlier
email. I know that Wayland has nothing like RANDR (i.e. where every
application can mess around with the output modes as it pleases) on
purpose. Sorry if I gave the impression that this or something similar
is what I'd want.

> 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.
That's perfectly OK. I don't think it necessarily becomes more
difficult by attaching the information to all surfaces as opposed to
only full-screen surfaces though. As you said, the compositor should
not be obligated to do anything at all and the arguably most common use
case which is the old set_fullscreen behaviour that only considers
fullscreen surfaces is still possible and reasonably easy to implement.
It would be a great improvement to have *any* chance of influencing the
output refresh rate decision since at the moment it's just not really
possible at all - if you use wl_shell_surface you lose a lot of other
functionality since you cannot also use xdg_shell.


- Philipp