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

[Ucan, Emre (ADITG/SW1)]

Hi Matthias,

We also need this feature in IVI use-case. The HMI control should choose which applications will be shown in which output.
It needs information about outputs to do so.

I have some inline comments below.

> -----Original Message-----
> From: wayland-devel [mailto:wayland-devel-
> bounces at lists.freedesktop.org] On Behalf Of Matthias Treydte
> Sent: Dienstag, 7. Februar 2017 20:58
> To: wayland-devel at lists.freedesktop.org
> Subject: [RFC wayland, weston] Expose an output's connector name
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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).
> 
> 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

I think "connector" is not the right name for it. Connector is a specific resource of linux drm driver.
Therefore, it only exists for drm-backend. I think it should be called "name" event. Then, sent names would be, e.g.: LVDS1, HDM1 etc.

> 
>    * stable (across restarts)
>    * unique (there are no two outputs per connector)
>    * optional (some implementations may not have this information
> available)

How will you achieve that the connector names are stable across restarts ? Even drm connector ids can be changed, if you change kernel or dtb.
What will happen in hotplug events ?

> 
> 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
>    * 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
>    * if the proposed way of making the information accessible to clients
> is not acceptable, what else should be done

I think it can be a part of wayland protocol. But we have to define the behavior very well for above mentioned cases.

> 
> 
> Kind regards,
> -Matthias
> 
> --
> For a successful technology, reality must take precedence over public
> relations, for nature cannot be fooled. (R.P. Feynman)

Best regards

Emre Ucan
Software Group I (ADITG/SW1)