Re: [PATCHv2] Add name event to xdg-output

[Pekka Paalanen]

On Tue, 10 Apr 2018 10:27:40 -0400
Drew DeVault  wrote:

> 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

Hi Drew,

yes, these statements would be very good. Make sure you refer to
wl_output globals and not just wl_outputs, because the wl_output
protocol objects (wl_proxy) can be, even if should not, left lingering
by a client even when the global has been removed.

I was going to propose that you would actually leave the persistence
explicitly unreliable with a sentence something like this:

"Persistence of the name delivered by an xdg-output is only
guaranteed for the lifetime of the corresponding wl_output
global."

This would imply to clients that if they save the name e.g. in a config
file, they cannot really rely on the same appearing on the next launch.
The reason I'm worrying about this is that otherwise someone is bound
to use the xdg-output name as part of session state restoration.

But your point 2 is good too. I think it is sufficient even for the
session restoration, should anyone (ab)use it for such. It also implies
answers to all the questions I posed, I believe.

Thank you for your effort in perfecting this.


Thanks,
pq


pgp32PsXdmchz.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] Add name event to xdg-output

[Pekka Paalanen]

On Tue, 10 Apr 2018 08:30:28 -0400
Drew DeVault  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

Re: [PATCHv2] Add name event to xdg-output

[Drew DeVault]

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.

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.

> 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.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] Add name event to xdg-output

[Pekka Paalanen]

On Mon, 09 Apr 2018 16:00:35 +0200
Philipp Kerling  wrote:

> Hey,
> 
> I'll just reiterate one point from the prior discussion.
> 
> > On Mon, 9 Apr 2018 08:13:15 -0400
> > Drew DeVault  wrote:
> >   
> > > Good feedback.
> > > 
> > > On 2018-04-09 11:09 AM, Pekka Paalanen wrote:  
> > > > Does this name correspond to the physical connector or to the
> > > > specific
> > > > monitor connected? Or some abstract "output" concept, see the
> > > > next
> > > > paragraph about clone mode.
> > > 
> > > Doesn't matter, whatever the compositor wants. Should be unique to
> > > each
> > > wl_output.  
> > 
> > If it is unique to each wl_output, then it is referring to either a
> > connector or a monitor, ok.
> >   
> > > > [...] Would xdg_outputs for the cloned wl_outputs report
> > > > identical
> > > > names to signify they in fact always show the exact same image?
> > > 
> > > No.  
> > 
> > This is consistent with the above, good.
> >   
> > > > Is this name intended to be stable and persistent, so that
> > > > applications
> > > > can expect to save it in a config and find the same one later,
> > > > after a
> > > > machine reboot, at least if the configuration of that output has
> > > > not
> > > > changed and the compositor is still the same version?
> > > 
> > > Yes.  
> > 
> > But if it is undefined whether the name refers to a connector or a
> > monitor, would that not cause problems for apps to decide how to use
> > it?
> > 
> > If a user unplugs one monitor and then plugs in a different monitor
> > to
> > the same connector, should the name change or stay the same?
> > 
> > If the name is defined to stay the same, the app can look at
> > wl_output
> > make/model to see if the monitor is different.  

> No, this does not work. Having multiple instances of the same make and
> model is common in desktop multi-monitor setups. The app has no option
> to recognize specific ones as long as there is no serial number or
> other additional identifier involved that is not currently part of the
> wl_output and xdg_output info.

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 feel that we should have both a connector name and a monitor name
separately and explicitly defined, so that applications that care about
the identity can pick which one they want to match to.

I would hesitate to simply add a "monitor serial" event because I don't
think it's always available and there might be other ways to identify a
unit if it even is a physical monitor to begin with. Hence I'd go with
"monitor name" which could simply be the serial plus maybe make+model
when those are available and something else at other times. Then there
is the special case of what to do when you just cannot identify the
unit uniquely at all.

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.


Thanks,
pq


pgp1AK0HcaqgC.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] Add name event to xdg-output

[Philipp Kerling]

Hey,

I'll just reiterate one point from the prior discussion.

> On Mon, 9 Apr 2018 08:13:15 -0400
> Drew DeVault  wrote:
> 
> > Good feedback.
> > 
> > On 2018-04-09 11:09 AM, Pekka Paalanen wrote:
> > > Does this name correspond to the physical connector or to the
> > > specific
> > > monitor connected? Or some abstract "output" concept, see the
> > > next
> > > paragraph about clone mode.  
> > 
> > Doesn't matter, whatever the compositor wants. Should be unique to
> > each
> > wl_output.
> 
> If it is unique to each wl_output, then it is referring to either a
> connector or a monitor, ok.
> 
> > > [...] Would xdg_outputs for the cloned wl_outputs report
> > > identical
> > > names to signify they in fact always show the exact same image?  
> > 
> > No.
> 
> This is consistent with the above, good.
> 
> > > Is this name intended to be stable and persistent, so that
> > > applications
> > > can expect to save it in a config and find the same one later,
> > > after a
> > > machine reboot, at least if the configuration of that output has
> > > not
> > > changed and the compositor is still the same version?  
> > 
> > Yes.
> 
> But if it is undefined whether the name refers to a connector or a
> monitor, would that not cause problems for apps to decide how to use
> it?
> 
> If a user unplugs one monitor and then plugs in a different monitor
> to
> the same connector, should the name change or stay the same?
> 
> If the name is defined to stay the same, the app can look at
> wl_output
> make/model to see if the monitor is different.
No, this does not work. Having multiple instances of the same make and
model is common in desktop multi-monitor setups. The app has no option
to recognize specific ones as long as there is no serial number or
other additional identifier involved that is not currently part of the
wl_output and xdg_output info.

> If the name is defined
> to change, then apps cannot target a specific connector. It obviously
> depends on apps or even users what they actually want.
> 
> If it is undefined, or if the name is defined to change in that case,
> then there is no way to reliably target a connector. Is this
> acceptable?
> 
> I would be interested too hear if you can think of why it should not
> be
> specified to refer to a connector specifically, because off-hand I
> can't imagine any reason.
> 
> Even if the name refers to a connector, a compositor could name it as
> it wishes.
> 
> > > The name is arbitrary, right? No standardization is inteneded?
> > > I.e.
> > > switching compositors will likely result in different names.  
> > 
> > Aye. Some compositors might find it useful to follow an informal
> > standard, though, like all wlroots-based compositors use consistent
> > names (e.g. DP-1).
> 
> Yeah, standardising on names would be difficult to write down right
> now.
> 
> > > Is the name enough, would you perhaps want to have a human-
> > > readable
> > > description string as well? Perhaps something for a user to
> > > totally
> > > customize and more verbose than just a name?  
> > 
> > Eh, I'm not a fan of this idea.
> 
> Very good.
> 
> > 
> > > I think it would be good to explicitly answer most of these
> > > questions
> > > in the spec, even if "configured by name" does imply some
> > > answers.  
> > 
> > Yep, will send a v3 answering some of these.
> 
> Cool.
> 
> 
> Thanks,
> pq
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] Add name event to xdg-output

[Pekka Paalanen]

On Mon, 9 Apr 2018 08:13:15 -0400
Drew DeVault  wrote:

> Good feedback.
> 
> On 2018-04-09 11:09 AM, Pekka Paalanen wrote:
> > Does this name correspond to the physical connector or to the specific
> > monitor connected? Or some abstract "output" concept, see the next
> > paragraph about clone mode.  
> 
> Doesn't matter, whatever the compositor wants. Should be unique to each
> wl_output.

If it is unique to each wl_output, then it is referring to either a
connector or a monitor, ok.

> > [...] Would xdg_outputs for the cloned wl_outputs report identical
> > names to signify they in fact always show the exact same image?  
> 
> No.

This is consistent with the above, good.

> > Is this name intended to be stable and persistent, so that applications
> > can expect to save it in a config and find the same one later, after a
> > machine reboot, at least if the configuration of that output has not
> > changed and the compositor is still the same version?  
> 
> Yes.

But if it is undefined whether the name refers to a connector or a
monitor, would that not cause problems for apps to decide how to use it?

If a user unplugs one monitor and then plugs in a different monitor to
the same connector, should the name change or stay the same?

If the name is defined to stay the same, the app can look at wl_output
make/model to see if the monitor is different. If the name is defined
to change, then apps cannot target a specific connector. It obviously
depends on apps or even users what they actually want.

If it is undefined, or if the name is defined to change in that case,
then there is no way to reliably target a connector. Is this acceptable?

I would be interested too hear if you can think of why it should not be
specified to refer to a connector specifically, because off-hand I
can't imagine any reason.

Even if the name refers to a connector, a compositor could name it as
it wishes.

> > The name is arbitrary, right? No standardization is inteneded? I.e.
> > switching compositors will likely result in different names.  
> 
> Aye. Some compositors might find it useful to follow an informal
> standard, though, like all wlroots-based compositors use consistent
> names (e.g. DP-1).

Yeah, standardising on names would be difficult to write down right now.

> > Is the name enough, would you perhaps want to have a human-readable
> > description string as well? Perhaps something for a user to totally
> > customize and more verbose than just a name?  
> 
> Eh, I'm not a fan of this idea.

Very good.

> 
> > I think it would be good to explicitly answer most of these questions
> > in the spec, even if "configured by name" does imply some answers.  
> 
> Yep, will send a v3 answering some of these.

Cool.


Thanks,
pq


pgpcua_5nXQa9.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] Add name event to xdg-output

[Drew DeVault]

Good feedback.

On 2018-04-09 11:09 AM, Pekka Paalanen wrote:
> Does this name correspond to the physical connector or to the specific
> monitor connected? Or some abstract "output" concept, see the next
> paragraph about clone mode.

Doesn't matter, whatever the compositor wants. Should be unique to each
wl_output.

> [...] Would xdg_outputs for the cloned wl_outputs report identical
> names to signify they in fact always show the exact same image?

No.

> Is this name intended to be stable and persistent, so that applications
> can expect to save it in a config and find the same one later, after a
> machine reboot, at least if the configuration of that output has not
> changed and the compositor is still the same version?

Yes.

> The name is arbitrary, right? No standardization is inteneded? I.e.
> switching compositors will likely result in different names.

Aye. Some compositors might find it useful to follow an informal
standard, though, like all wlroots-based compositors use consistent
names (e.g. DP-1).

> Is the name enough, would you perhaps want to have a human-readable
> description string as well? Perhaps something for a user to totally
> customize and more verbose than just a name?

Eh, I'm not a fan of this idea.

> I think it would be good to explicitly answer most of these questions
> in the spec, even if "configured by name" does imply some answers.

Yep, will send a v3 answering some of these.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] Add name event to xdg-output

[Pekka Paalanen]

On Sun,  8 Apr 2018 10:25:21 -0400
Drew DeVault  wrote:

> Signed-off-by: Drew DeVault 
> Reviewed-by: Simon Ser 
> ---
> Thanks Daniel for pointing out my silly mistakes
> 
>  unstable/xdg-output/xdg-output-unstable-v1.xml | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml 
> b/unstable/xdg-output/xdg-output-unstable-v1.xml
> index 0c0c481..e6ad6fe 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -77,7 +77,7 @@
>  
>
>  
> -  
> +  
>  
>An xdg_output describes part of the compositor geometry.
>  
> @@ -157,5 +157,17 @@
>
>  
>  
> +
> +  
> +Many compositors will assign names to their outputs, show them to the 
> user,
> +allow them to be configured by name, etc. The client may wish to know 
> this
> +name as well to offer the user similar behaviors.
> +
> +The name event is sent after creating an xdg_output (see
> +xdg_output_manager.get_xdg_output).
> +  
> +  
> +
> +
>
>  

Hi,

the naming has been discussed before, below I'm listing some of the
questions that arose back then that I can remember.

Does this name correspond to the physical connector or to the specific
monitor connected? Or some abstract "output" concept, see the next
paragraph about clone mode.

wl_output is pretty much defined to correspond to a monitor, not a
connector, as it carries things like monitor make and model. When in
clone mode, there will be two or more wl_outputs that are driven
identically by a compositor. How is the xdg_output name affectd by
this? Would xdg_outputs for the cloned wl_outputs report identical
names to signify they in fact always show the exact same image?

Is this name intended to be stable and persistent, so that applications
can expect to save it in a config and find the same one later, after a
machine reboot, at least if the configuration of that output has not
changed and the compositor is still the same version?

The name is arbitrary, right? No standardization is inteneded? I.e.
switching compositors will likely result in different names.

Is the name enough, would you perhaps want to have a human-readable
description string as well? Perhaps something for a user to totally
customize and more verbose than just a name?

I think it would be good to explicitly answer most of these questions
in the spec, even if "configured by name" does imply some answers.


Thanks,
pq


pgp5MmwWFZvMa.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel