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- > [email protected]] On Behalf Of Matthias Treydte > Sent: Dienstag, 7. Februar 2017 20:58 > To: [email protected] > 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) _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
