[PATCHv2] Add name event to xdg-output

[Pekka Paalanen]

On Tue, 10 Apr 2018 08:30:28 -0400
Drew DeVault <sir at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180410/5c4f34a6/attachment.sig>