wl_output ambiguity, xdg_shell fullscreen refresh rate

[Pekka Paalanen]

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.

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. The
presentation timing extension should help with that very much.


Thanks,
pq

> [1] https://summerofcode.withgoogle.com/projects/#4913542374359040
> [2] http://forum.kodi.tv/showthread.php?tid=309254&pid=2552143#pid2552143
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170515/36e5d48c/attachment.sig>