wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

Thanks for your answers! See reply below.

2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました:
> On Sun, 14 May 2017 14:43:44 +0200
> Philipp Kerling <pkerling at casix.org> wrote:
> > 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.
I'm not sure I agree. See further below.

> Also, would you not want to identify the
> monitor rather than which connector it happens to be plugged in? 
I think that it's not quite decided yet what we want the user
experience to be on the Kodi side, i.e. do we want to bind output to
the physical monitor (however it is identified) or the GPU connector?
You can probably find use cases for both, so it's not an easy decision
to make. With X11 it was limited to the latter, so my first approach
was to mimic that. Ideally, both would be possible with Wayland and the
application can decide what is best for its specific use case. I
realize that this might be too much to ask for all at once, so I'll
talk to my mentor to decide which case we want to focus on for Kodi.
There are also two different points involved in this discussion:
   I. How the *user* identifies which output/monitor the fullscreen
      display should be on (e.g. with make+model+connector name, or by
      compositor-specific numbering).
  II. How *Kodi* or any other application then stores this, re-identifies
      this output/monitor and maps it to a wl_output on application start
      and hotplug. Possiblities include saving information pertaining to
      the output, the connector, the physical device, or any combination.

> Would
> a user even know which connector name matches to which monitor?
Yes, I also thought about this. Tech-savvy users might actually be able
to identify the connector name, but you are absolutely right that
usually users should not be expected to. In fact, having make and model
available actually is an improvement in that regard (on X11, Kodi
*only* displays connector since that is what's available via RANDR).
So: How do you suggest to identify a particular monitor then? As I
said, make and model are not sufficient - but serial number will not
help the user in identification. If there are multiple monitors of the
same model, I do not think that they (i.e. the physical devices) can be
reasonably discerned in a way that is transparent to the user. That's
why I suggested the connector name.

> 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?
RANDR output names (which are somewhat close to what I refer to as
connector names - it's a matter of debate whether output or connector
name would be more fitting for the Kodi use case) are specifically
meant to be "presented to the user", but I can see your point. I think
that machine-parseable is doable, also considering that RANDR did have
a "ConnectorType" property which is probably part of what we'd want
here. 

> A simple numbering with a way in the compositor to identify the
> monitors? Maybe.
What exactly do you mean by "a way in the compositor to identify the
monitors"? Like you can tell the compositor to display the output names
(briefly) on the outputs so the user knows which is which?
If so, couldn't this also be done by the application at least with more
or less arbitrarily assigned numbers by mapping a surface to each known
output that displays said number?
I'm beginning to think that something along those lines might be one of
the more user-friendly options of solving I. above.

> > 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.
Also answering the first question above: I don't see how "make" and
"model" (and the mode list for that matter) in wl_output fit with this
statement. They are also limited to traditional physical devices
(monitors), yet are in the core protocol. I don't suppose that it makes
sense to classify an output in another window system with a
manufacturer and model. That said, I also don't see why "connector" (or
something similar) would be fundamentally different from what is
already there.

> 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.
Is this name (which is usually the integer number of the protocol in
enumeration order if I got that right) *guaranteed* to stay the same
(for a given wl_output)
 * when I restart the application?
 * when I restart the compositor?
 * when I restart the computer?
 * when I connect additional monitors?
 * when I rearrange monitors in the compositor?
 * when I start the application with the monitor unplugged and plug it
   in later (while the app is running)?

If not, this would not be useful to Kodi. Whether other clients see the
same "name" or not is not especially relevant here. The specific use
case is to save the monitor/output identifier to the configuration file
and have it persist across both app and device restarts and output
configuration changes. We would especially like to support the last
point of the enumeration above, i.e. starting on a fallback
(unspecified) monitor and then switching fullscreen output to the
preferred monitor once it is connected by the user.

> 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?
I don't see the real benefit in b), it is IMHO too much effort for the
average user. I'm also not sure what I would personally label my
screens as besides "Left screen" and "Right screen", which the
compositor could as well figure out on its own :-)

> But then, do you tie the output identity to the
> connector or the physical device? Or an intelligent mix?
As I said, best is probably if the application has enough information
to be able to do either.

> 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.
If the consensus is that this will, in some form or another, need a
protocol extension, I'll have to discuss with my mentor whether this
can be pursued as part of my GSoC work, especially the reference
implementation part. I think that it is a possibility, but does require
that there is a realistic expectation that at least mutter or KWin will
support the extension in the future. Otherwise it could be very hard to
justify.

> >  * 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.
So is there any realistic chance to have such functionality integrated?
What steps would have to be done?

> FYI, even wl_shell's framerate parameter is not a guarantee, it is a
> wish. The player will have to be able to deal with arbitrary output
> refresh rates in any case and it may dynamically change, too.
That's OK. Obviously Kodi can run with any framerate (the output might
only support 60 Hz anyway, for example). We just want to have the
possiblity of influencing the refresh rate to improve the video
playback experience where possible.
Realistic route seems to be to focus on xdg_shell, since my relatively
uneducated guess is that no real-world desktop compositor honors the
wl_shell framerate parameter anyway. Weston just ignored it last time I
checked.

> The presentation timing extension should help with that very much.
wp_presentation support is on the roadmap.

- Philipp