[RFC wayland, weston] Expose an output's connector name

[Pekka Paalanen]

On Tue, 07 Feb 2017 20:51:32 +0100
Matthias Treydte <mt at waldheinz.de> wrote:

> I already brought this up on IRC before and finally started to work on 
> it. The goal is to give an Wayland client some identifier which allows 
> it to recognize the physical connector which corresponds to some Wayland 
> output.

Hi,

the idea seems good to me, but as always, the devil is in the details.

> The rationale why such an API is useful is that a client might want to 
> ensure that it's content is available on some well-known connector. 
> Imagine, for example, a video player which "knows" that the projector is 
> connected to the second HDMI port.

Since this will presumably be an addition to wl_output interface, we
need to be careful to keep it generic rather than fall into something
that would be specific to desktops. Even more so it cannot be specific
to e.g. DRM, it must be equally workable on any compositor platform, be
it DRM, X11, Wayland, Mir, headless, Android, etc., that is, even on
platforms that do not have physical connectors themselves but something
beneath might, or the outputs are otherwise still identifiable.

That poses the question of what then if the platform beneath makes
identification practically impossible or unreliable? I suppose there
needs to be some optionality, as you suggest.

> Our use case is like that: We have an Wayland application which, running 
> under the fullscreen shell, presents one surface per output. That 
> application can be configured to display windows showing variety of 
> video sources via a network API (by the means of sub-surfaces, though 
> that doesn't matter here). Given this, a "master" application can talk 
> to a number of computers running said application to create a video wall 
> of arbitrary size. A problem arises when more than one physical display 
> is connected to any "client" computer: There is currently no way for a 
> Wayland client to uniquely identify more than one display (or output) 
> across reboots or connector plug/unplug events. Because of this it is 
> not possible to reliably use more than one display per client computer 
> while having a sane way to configure the physical arrangement of all 
> connected displays. That's not so nice.

Right. This seems a good use case.

> The attached patches establish a minimal API which allows clients to 
> know the (DRM) connector name of outputs, thus enabling our use case 
> (and possibly others, at least one came up on IRC which I unfortunately 
> do not remember).

Please send patches inline in separate emails so that they can be
replied to with review comments.

As Emre pointed out, we shouldn't use DRM terminology to define it, but
we can and should use it to give an example on how it should be
implemented on a DRM platform to ensure consistent implementations.

If we did use only DRM definition for this, then it should not be an
addition to wl_output, but an independent extension that only DRM-based
compositors would expose. I do think a general solution would be better
instead.

> The first patch extends the "wl_output" interface by a new "connector" 
> event, providing a string to the client which can be used as a stable 
> identifier for that output. I'm unsure if this version bump to the core 
> Wayland protocol is acceptable, but to me this seems the obvious place 
> where this information should be published. A lot of monitor related 
> information (resolution(s), physical size, maker, model, ...) is already 
> published there, so it seems natural. The documentation is missing 
> there, but I imagine it would state that this identifier is
> 
>    * stable (across restarts)

I wonder, does DRM guarantee stability of connector names? I guess it
should, otherwise it would be a bit useless. I agree that stability is
an important property, but how far should it go? E.g. is a kernel
upgrade allowed to change the names? I'd recon yes, it just needs some
wording to spell out something about when it may and must not change.

>    * unique (there are no two outputs per connector)

Yes.

>    * optional (some implementations may not have this information 
> available)

I'd rather have it mandatory, if we can come up with a way to create
names for systems that do not inherently have them already, but I also
understand it might be impossible to do reliably in some cases.

There is one portion of optionality already, in that implementations
may be left on an old wl_output version without this new event. This
cannot be a primary mechanism for optionality though, as if yet another
feature is added to wl_output then one cannot implement that without
implementing also this.


One thing that must be taken into account is multi-GPU systems. If
there are multiple display devices, each having a set of connectors,
something has to guarantee the stability and uniqueness of the names.
This must work regardless of the display driver initialization order. I
do not know off-hand how this would work with DRM.

There could also exist virtual outputs, e.g. Miracast. Even on a
compositor running on DRM otherwise, these would need names that cannot
be derived from DRM properties as they are likely implemented outside
of DRM or even the kernel. It becomes a very good question, what to use
as the name? The receiver network address? Some sort of GUID? TV model
and serial number? The server network port?

Can the name change at runtime? I think not. What a compositor would do
instead is delete the old wl_output and create a new one, if the stream
target changes in a way that needs to be communicated to applications.

> The other two patches are a rudimentary implementation of this protocol 
> extension in Weston, taking advantage of the fact that Weston's internal 
> output struct already has the connector name available.
> 
> I'd like to know if
> 
>    * extending the Wayland protocol for this is acceptable or if this 
> should go into a separate protocol

In my opinion this depends on whether it is written as a generic one or
specific to DRM.

>    * calling the exposed information "connector name" (hinting that we're 
> talking about a physical plug) or something more generic like "output 
> identifier" seems a better idea

Also generic vs. DRM, but also it needs to specify if this identifies a
monitor or a "slot" (connector).

You want to identify connectors. An orthogonal feature would be to
identify monitors, e.g. by serial number in addition to make/model.
Should we also consider monitor identification as another event?

A wl_output represents both a connector and a particular monitor
connected to it... except when it might not... clone mode? MST?

Now that clone mode was mentioned, I realize I may have missed a point.
I think the intention is that even cloned monitors would each still
expose its own wl_output via the protocol. Maybe clarifying that could
offer a solution to several problems with the identification too?

I wonder what applications have accustomed to expect.

What about Multi-Stream Transport (MST)? There you have a single
connector on a machine, but there can be multiple independent monitors
connected to the same connector. I suppose DRM handles that somehow, I
just don't know how.

Some monitors require several connectors: they are too high resolution
to receive the picture with just one connector. A Wayland compositor
would expose such an output as a single wl_output, but it would use
multiple connectors.

>    * if the proposed way of making the information accessible to clients 
> is not acceptable, what else should be done

Mechanically it's fine, I assume.

The big questions are related to what exactly a name should be, and
what does it represent.

I have not looked at the patches, as I believe that these comments
already are giving you some headache. ;-)


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170210/21dec52a/attachment.sig>