On Tue, 10 Apr 2018 08:30:28 -0400 Drew DeVault <s...@cmpwn.com> wrote:
> On 2018-04-10 12:20 PM, Pekka Paalanen wrote: > > Oh yes, that's a good point. This is actually a good reason to repeat > > the question: > > > > Does the name identify the connector or the monitor? > > I suppose I should repeat the answer, too: one xdg_output maps to one > wl_output and has a unique name. How do you define "one wl_output"? Do you mean it is the wl_output as identified by its global name (int), and gets destroyed when the wl_registry sends the remove event? Unplugging a monitor likely causes the corresponding wl_output global to be destroyed, right? If so, that means a couple of things: - If a user unplugs and re-plugs the same monitor to the same connector, you require the xdg-output name to be chosen different as the wl_output is no longer the same. - When ever a compositor starts, all wl_outputs are new, which means all xdg-output names must be new as well. So if an application saves a name in its config, it will never find a match anymore after the compositor gets restarted. Therefore I don't think it makes sense to tie the xdg-output name to the identity of the wl_output global, and even less to a wl_output protocol object which is created anew every time someone calls wl_registry.bind. You seem to have an intuitive idea of what you mean, but we still need to get into the spec wording so that other people can understand it the same way. Right now I'm not quite sure what exactly identifies an xdg-output for you. > It doesn't always make sense to think about connectors. DRM might have > them, but many compositors also have other backends like X11 or Wayland. > wlroots names those too (X11-1, WL-2, etc), but they aren't connectors > and don't have a monitor model. Right. Outputs in compositors are often named by the connector, not by the monitor. My recent work on Weston introduces the concept of "heads" which essentially refer to connectors and share their names. Weston "outputs" are basically rendering engine instances and in clone mode one weston_output feeds the image into several heads at the same time. Then we have wl_output that represents the monitor, carrying its make and model, and being 1:1 to a "head" when the head is active (but not necessarily connected to a monitor). Given that you say clones will not share the xdg-output name, then in a Weston implementation I would use either the connector name or the monitor info (EDID) as the base for creating xdg-output names. I still don't know which one would be appropriate for the clients, though. > > The very least the current proposal for a "name" should specify whether > > it refers to the connector or the monitor, because if it is ambiguous, > > then we need to add two more events that are not ambiguous when the > > need to make the difference arises. > > I don't think there's any amgibuity. One xdg_output == one wl_output, > this much is already clear by the existing semantics of the protocol and > we needn't go any further than that. I do think it is ambiguous, because I have several options on what to tie the name to, and these options will behave differently towards clients: - If a user unplugs a monitor and replugs it into another connector, do applications expect the xdg-output name for the new situation to be different from the old situation? - If a user unplugs a monitor and replaces it with a different monitor plugged into the same connector, do applications expect the xdg-output name to be different from before? Or, there is a third option: You could require, that the xdg-output name must be the same as long as the same monitor is being connected to the same connector, and compositor restarts alone must not come up with a different the name. IOW, a correct implementation would include both the connector name and the monitor serial number in the xdg-output name. None of these match the lifetime of a wl_output global. Given all the examples above, when do you expect the name to change, and when must it stay the same when you think about things over time and over user actions like unplugging or plugging in a monitor, not just any single time instant? The reason why I am insisting on this is that you said that applications are free to save the name and expect to find it later under some circumstances. We need to establish those circumstances, so that application writers can know what it actually means to find or not find an xdg-output of a certain name they've seen before. If it's all undefined, then it would be better to just specify that applications should not expect to be able to find xdg-outputs with the same name as they have seen some time before. Thanks, pq
pgpJSuEIk1zfX.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel