wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

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

- Philipp