wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Zabel]

On Mon, 2017-05-15 at 17:51 +0200, Philipp Kerling 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. Doing this on a regular basis would be very
> disturbing.

I agree, non-fullscreen vrefresh rate changes would only be useful for
outputs that are known to change modes quickly without blanking.
For generic desktop compositors this probably should be limited to
fullscreen surfaces. However, there may be other things that could be
done with this information, like using it for compositing decisions, if
it is known in advance that the application will not change buffer until
the next screen update. Or for changing encoder parameters for outputs
that end up being encoded and streamed.

regards
Philipp