wl_output ambiguity, xdg_shell fullscreen refresh rate

[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:
> 
> > Hi Wayland team and community,
> > 
> > allow me to quickly introduce myself first, since this is my first post
> > on this list.
> > I'm Philipp, studying Computer Engineering and currently working on
> > getting Wayland support (back) in Kodi as Google Summer of Code project
> > [1] [2].I might have to ask some questions about specific aspects of
> > Wayland over the next few months. I'll try not to be too annoying
> > though :-)
> > Please tell me if this is not the right place to ask this kind of stuff
> > or if anything is unclear.
> 
> Hi,
> 
> you are exactly in the right place. :-)
> 
> > To start off:
> >  * Kodi should offer the user the opportunity to select inside the
> >    application on which monitor he/she wants to have Kodi displayed on
> >    when in full-screen mode. Now I see that I can do this with either
> >    wl_shell_surface::set_fullscreen and zxdg_toplevel::set_fullscreen,
> >    which expect a wl_output to display the window on. But I am not sure
> >    how I should match the wl_output instance I get from Wayland with
> >    the monitor that the user selected. As far as I can see, I can only
> >    identify the monitor by way of "make" and "model". This seems
> >    reasonable enough at first glance, but I think that in multi-monitor 
> >    configurations it is not so uncommon to buy the same monitor model
> >    multiple times - I personally have done this. Naturally, the "make"
> >    and "model" of both monitors are identical, so I cannot discern
> >    which is which by looking at the wl_output metadata. Am I missing
> >    something here?
> 
> That is all true, you are not missing anything.
> 
> It is a missing piece of protocol - I believe no-one has had both the
> need and the time to work on getting anything better yet.
> 
> > Why isn't e.g. the connector the output is connected
> >    to exported?
> 
> Because connector names are specific to DRM while Wayland (core
> protocol at least) is not. Also, would you not want to identify the
> monitor rather than which connector it happens to be plugged in? Would
> a user even know which connector name matches to which monitor?
> 
> To expose such a name in the protocol, we should define the space or
> meaning of the names. Human-readable? That's not the connector name,
> IMHO. Machine-parseable? Needs a very strict definition to work. Both?
> A simple numbering with a way in the compositor to identify the
> monitors? Maybe.
> 
> > This would allow way better matching and also give the
> >    user a chance to select the right monitor without having to try all
> >    options. Serial number (or anything similar - not sure if the EDID
> >    has this though) could also be OK.
> 
> EDID may have a serial number, yes.
> 
> Physical monitor devices are not the only things though. An output
> could be just a window in another window system. An output could be at
> the end of a streaming network connection. Etc. So aiming for a generic
> solution here would have a really wide scope.
> 
> However, there already is a unique numbering for wl_outputs, even
> though it's not exactly user-friendly. It is the wl_output "name"
> advertised by wl_registry, which you use in wl_registry.bind request to
> create a wl_output instance. This "name" is the same for all clients.
> 
> What we would really need is a new protocol extension designed to cater
> for specific use cases and offering the additional information to help
> make user-friendly UIs. Maybe compositors should a) number of the
> outputs, and b) let the user give them arbitrary names to be shown in
> application UIs? But then, do you tie the output identity to the
> connector or the physical device? Or an intelligent mix?
> 
> Would it be in scope for your work to design such an extension? It's
> relatively easy to write a protocol proposal, but getting it reviewed
> and hopefully ack'd by more than one DE project is often hard and time
> consuming. And then you'd need to provide an implementation on at least
> one compositor, unless you find someone else to collaborate with you.
> 
> >  * 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.

regards
Philipp