On Tue, 07 Feb 2017 20:51:32 +0100 Matthias Treydte <[email protected]> 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
pgplIeHLYBe0y.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
