[PATCHv2] Add name event to xdg-output
sir at cmpwn.com
Tue Apr 10 14:27:40 UTC 2018
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
More information about the wayland-devel