[PATCHv2] Add name event to xdg-output

[Drew DeVault]

On 2018-04-10  5:09 PM, Pekka Paalanen wrote:
> 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?

Yes, I mean one wl_output as in one global on the registry.

> 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.

Not necessarily. Uniqueness is only consistent across all of the
wl_output globals currently in existence. Once one goes away, a new
wl_output can utilize the same name.

> - 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.

Again, the only uniqueness constraint is across the current list of
living wl_output globals. Nothing prevents the names from being the same
across sessions, in fact it's strongly suggested that they are.

> 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.

I'd do HDMI-A-1-1, DP-1-2, etc, if subdividing one output into several
logical wl_outputs. The specification is deliberately left vague on how
the compositor comes up with the name. Do it however you feel is useful.

> - 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?

Up to your compositor. I'm just going to use the connector but this is
again deliberately vague.

> 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.

I don't want to specify the degree to which the compositor embues the
name with meaning, just that it does so somewhat consistently. The
constraint is: at a bare minimum the same configuration of hardware and
software produces the same names across settings.

I do not want to bring into this already nicely generic API any
underlying details of the output's hardware, like an EDID - whether or
not we abstract it into some more generic sounding event name. "Name" is
a nice vague term that compositors can give any meaning they like.

Will it address your concerns if I:

1. Add a statement clarifying that the names are unique across all
   living wl_outputs and may be reused if the corresponding wl_output
   global is removed
2. Add a statement clarifying that persistence of names between sessions
   is only guaranteed for the same hardware & software configuration

--
Drew DeVault