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

[Matthias Treydte]

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

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

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


Kind regards,
-Matthias

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. (R.P. Feynman)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-protocol-Add-connector_name-event-to-wl_output.patch
Type: text/x-diff
Size: 1095 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170207/957d8ec5/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libweston-Initial-stab-for-connector-name.patch
Type: text/x-diff
Size: 1075 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170207/957d8ec5/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-weston-info-Show-output-s-connector-name.patch
Type: text/x-diff
Size: 1952 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170207/957d8ec5/attachment-0002.patch>