[PATCHv3] Add name event to xdg-output

Submitted by Drew DeVault on April 11, 2018, 12:27 a.m.

Details

Message ID 20180411002755.30678-1-sir@cmpwn.com
State Superseded
Headers show
Series "Add name event to xdg-output" ( rev: 4 ) in Wayland

Not browsing as part of any series.

Commit Message

Drew DeVault April 11, 2018, 12:27 a.m.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
---
This version clarifies the uniqueness constraint, mapping of names to
wl_outputs, and persistence between sessions.

 .../xdg-output/xdg-output-unstable-v1.xml     | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml
index 0c0c481..b46c9df 100644
--- a/unstable/xdg-output/xdg-output-unstable-v1.xml
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -77,7 +77,7 @@ 
     </request>
   </interface>
 
-  <interface name="zxdg_output_v1" version="1">
+  <interface name="zxdg_output_v1" version="2">
     <description summary="compositor logical output region">
       An xdg_output describes part of the compositor geometry.
 
@@ -157,5 +157,22 @@ 
       </description>
     </event>
 
+    <event name="name" since="2">
+      <description summary="name of this output">
+    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 naming convention is compositor defined. Each name is unique among all
+    wl_output globals, but if a wl_output global is destroyed the same name may
+    be reused later. The names will also remain consistent across sessions with
+    the same hardware and software configuration.
+
+    The name event is sent after creating an xdg_output (see
+    xdg_output_manager.get_xdg_output).
+      </description>
+      <arg name="name" type="string" summary="output name"/>
+    </event>
+
   </interface>
 </protocol>

Comments

Hi,

maybe I missed it at some point in the discussion (sorry if that is the
case), but what is your use case for the "name?" What are clients
expected to use it for?
The description mentions "similar behaviors", but it is unclear to me
what you are referring to.

Regards,
Philipp

2018-04-10 (火) の 20:27 -0400 に Drew DeVault さんは書きました:
> Signed-off-by: Drew DeVault <sir@cmpwn.com>
> Reviewed-by: Simon Ser <contact@emersion.fr>
> ---
> This version clarifies the uniqueness constraint, mapping of names to
> wl_outputs, and persistence between sessions.
> 
>  .../xdg-output/xdg-output-unstable-v1.xml     | 19
> ++++++++++++++++++-
>  1 file changed, 18 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..b46c9df 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -77,7 +77,7 @@
>      </request>
>    </interface>
>  
> -  <interface name="zxdg_output_v1" version="1">
> +  <interface name="zxdg_output_v1" version="2">
>      <description summary="compositor logical output region">
>        An xdg_output describes part of the compositor geometry.
>  
> @@ -157,5 +157,22 @@
>        </description>
>      </event>
>  
> +    <event name="name" since="2">
> +      <description summary="name of this output">
> +    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 naming convention is compositor defined. Each name is unique
> among all
> +    wl_output globals, but if a wl_output global is destroyed the
> same name may
> +    be reused later. The names will also remain consistent across
> sessions with
> +    the same hardware and software configuration.
> +
> +    The name event is sent after creating an xdg_output (see
> +    xdg_output_manager.get_xdg_output).
> +      </description>
> +      <arg name="name" type="string" summary="output name"/>
> +    </event>
> +
>    </interface>
>  </protocol>
On Tue, 10 Apr 2018 20:27:55 -0400
Drew DeVault <sir@cmpwn.com> wrote:

> Signed-off-by: Drew DeVault <sir@cmpwn.com>
> Reviewed-by: Simon Ser <contact@emersion.fr>
> ---
> This version clarifies the uniqueness constraint, mapping of names to
> wl_outputs, and persistence between sessions.
> 
>  .../xdg-output/xdg-output-unstable-v1.xml     | 19 ++++++++++++++++++-
>  1 file changed, 18 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..b46c9df 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -77,7 +77,7 @@
>      </request>
>    </interface>
>  
> -  <interface name="zxdg_output_v1" version="1">
> +  <interface name="zxdg_output_v1" version="2">
>      <description summary="compositor logical output region">
>        An xdg_output describes part of the compositor geometry.
>  
> @@ -157,5 +157,22 @@
>        </description>
>      </event>
>  
> +    <event name="name" since="2">
> +      <description summary="name of this output">
> +    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.

So the name needs to be human-friendly, good.

> +
> +    The naming convention is compositor defined. Each name is unique among all
> +    wl_output globals, but if a wl_output global is destroyed the same name may
> +    be reused later. The names will also remain consistent across sessions with
> +    the same hardware and software configuration.

Excellent, you already took care of what I just wrote in the previous
email.

> +
> +    The name event is sent after creating an xdg_output (see
> +    xdg_output_manager.get_xdg_output).

Specifying when the event can be sent or expected, good. It is also
mandatory to send in interface version 2, and consistency rule above
implies that a compositor cannot suddenly change the name.

There is still the corner-case of: can removing wl_output global A
cause the name for wl_output global B to change, but I suppose that
falls to common sense to not do so strange things.

I do wonder, if I used a naming scheme like this:

	on top: Intel GMA: DVI-D-1: Viewsonic VP171B (S/N: 8764358365)
	on bottom: GeForce 8800: HDMI-2: HP ZDisplay K99 (S/N: 98728462)

and then the user reconfigures the output layout, can the compositor
send updated names to all clients that already have an xdg-output object?

> +      </description>
> +      <arg name="name" type="string" summary="output name"/>
> +    </event>
> +
>    </interface>
>  </protocol>


Thanks,
pq
On 2018-04-11  9:17 AM, Philipp Kerling wrote:
> maybe I missed it at some point in the discussion (sorry if that is the
> case), but what is your use case for the "name?" What are clients
> expected to use it for?

This is ideally combined with other protocols. Some example use-cases:

- A client using fullscreen-shell could offer the user a list of outputs
  by name to fullscreen on
- A client using wlroot's new layer-shell protocol (which will be
  submitted for standardization once we finish proving it with our
  implementation) can do something similar
- Xwayland can name the X11 outputs based on their genuine names rather
  than assigning e.g. XWAYLAND0

--
Drew DeVault
More good questions.

On 2018-04-11 11:02 AM, Pekka Paalanen wrote:
> There is still the corner-case of: can removing wl_output global A
> cause the name for wl_output global B to change, but I suppose that
> falls to common sense to not do so strange things.

I suppose I can add a note about this if another protocol revision is
required for other reasons.

> I do wonder, if I used a naming scheme like this:
> 
> 	on top: Intel GMA: DVI-D-1: Viewsonic VP171B (S/N: 8764358365)
> 	on bottom: GeForce 8800: HDMI-2: HP ZDisplay K99 (S/N: 98728462)
> 
> and then the user reconfigures the output layout, can the compositor
> send updated names to all clients that already have an xdg-output object?

You could do this but it would be exceedingly silly of you considering
that the other xdg_output requests furnish the client with layout
information anyway.

--
Drew DeVault
On Tue, 10 Apr 2018 20:27:55 -0400
Drew DeVault <sir@cmpwn.com> wrote:

> Signed-off-by: Drew DeVault <sir@cmpwn.com>
> Reviewed-by: Simon Ser <contact@emersion.fr>
> ---
> This version clarifies the uniqueness constraint, mapping of names to
> wl_outputs, and persistence between sessions.
> 
>  .../xdg-output/xdg-output-unstable-v1.xml     | 19 ++++++++++++++++++-
>  1 file changed, 18 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..b46c9df 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -77,7 +77,7 @@
>      </request>
>    </interface>
>  
> -  <interface name="zxdg_output_v1" version="1">
> +  <interface name="zxdg_output_v1" version="2">
>      <description summary="compositor logical output region">
>        An xdg_output describes part of the compositor geometry.
>  

Hi,

the version bump on zxdg_output_manager_v1 seems to be missing.

> @@ -157,5 +157,22 @@
>        </description>
>      </event>
>  
> +    <event name="name" since="2">
> +      <description summary="name of this output">
> +    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 naming convention is compositor defined. Each name is unique among all
> +    wl_output globals, but if a wl_output global is destroyed the same name may
> +    be reused later. The names will also remain consistent across sessions with
> +    the same hardware and software configuration.
> +
> +    The name event is sent after creating an xdg_output (see
> +    xdg_output_manager.get_xdg_output).

The other events have more precise wording here, allowing the event to
be sent again if the information changes.

> +      </description>
> +      <arg name="name" type="string" summary="output name"/>
> +    </event>
> +
>    </interface>
>  </protocol>

Otherwise looks good to me, judging from our past discussions.


Thanks,
pq
On Wed, Apr 11, 2018 at 08:35:34AM -0400, Drew DeVault wrote:
> On 2018-04-11  9:17 AM, Philipp Kerling wrote:
> > maybe I missed it at some point in the discussion (sorry if that is the
> > case), but what is your use case for the "name?" What are clients
> > expected to use it for?
> 
> This is ideally combined with other protocols. Some example use-cases:
> 
> - A client using fullscreen-shell could offer the user a list of outputs
>   by name to fullscreen on

I think this would need something different, an actual "human friendly"
name, like 'Dell 24"' or 'Builtin monitor'. If you'd have strings like
"DP-1", they are hardly helpful for selecting where to fullscreen.

> - Xwayland can name the X11 outputs based on their genuine names rather
>   than assigning e.g. XWAYLAND0

If the protocol is loosly specified as in it's not known what format
you'll get, I don't think Xwayland can make any use of this.


Jonas

> 
> --
> Drew DeVault
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On 2018-04-13  4:02 PM, Jonas Ådahl wrote:
> > - A client using fullscreen-shell could offer the user a list of outputs
> >   by name to fullscreen on
> 
> I think this would need something different, an actual "human friendly"
> name, like 'Dell 24"' or 'Builtin monitor'. If you'd have strings like
> "DP-1", they are hardly helpful for selecting where to fullscreen.

In sway, we have a slightly more savvy base user than the general
population, and we've educated them to understand connectors. However,
this is exactly why the field is vague - other compositors can name them
anything they like, including "Dell 24".

> > - Xwayland can name the X11 outputs based on their genuine names rather
> >   than assigning e.g. XWAYLAND0
> 
> If the protocol is loosly specified as in it's not known what format
> you'll get, I don't think Xwayland can make any use of this.

Can you elaborate on what expectations Xwayland would have? I am open to
restricting the format a bit, e.g. to ASCII characters or so.

--
Drew DeVault
On Fri, Apr 13, 2018 at 10:05:39AM -0400, Drew DeVault wrote:
> On 2018-04-13  4:02 PM, Jonas Ådahl wrote:
> > > - A client using fullscreen-shell could offer the user a list of outputs
> > >   by name to fullscreen on
> > 
> > I think this would need something different, an actual "human friendly"
> > name, like 'Dell 24"' or 'Builtin monitor'. If you'd have strings like
> > "DP-1", they are hardly helpful for selecting where to fullscreen.
> 
> In sway, we have a slightly more savvy base user than the general
> population, and we've educated them to understand connectors. However,
> this is exactly why the field is vague - other compositors can name them
> anything they like, including "Dell 24".

If that is the case, I'd rather we introduced data that has actual
meaning, like something similar to "connector" (even though connector is
the wrong thing here since an "xdg_output" might not have one, maybe,
something that doesn't identify the monitor itself, but how it is
connected, if that is what you want) and then a different thing that is
more meaningful to a user interface. Then whether the "this is string is
user interface facing" should have anything to do with where the wire is
plugged in or what is actually plugged in can be up to the software that
is responsible for generating that string, but it should be clear what
its purpose is.

> 
> > > - Xwayland can name the X11 outputs based on their genuine names rather
> > >   than assigning e.g. XWAYLAND0
> > 
> > If the protocol is loosly specified as in it's not known what format
> > you'll get, I don't think Xwayland can make any use of this.
> 
> Can you elaborate on what expectations Xwayland would have? I am open to
> restricting the format a bit, e.g. to ASCII characters or so.

If we'd add quotation marks, spaces etc I'm sure many things would break
here and there. If we start adding such restrictions, it'd hardly be
suitable as a "human readable" kind of thing.


Jonas

> 
> --
> Drew DeVault
On 2018-04-13  4:16 PM, Jonas Ådahl wrote:
> If that is the case, I'd rather we introduced data that has actual
> meaning, like something similar to "connector" (even though connector is
> the wrong thing here since an "xdg_output" might not have one, maybe,
> something that doesn't identify the monitor itself, but how it is
> connected, if that is what you want) and then a different thing that is
> more meaningful to a user interface. Then whether the "this is string is
> user interface facing" should have anything to do with where the wire is
> plugged in or what is actually plugged in can be up to the software that
> is responsible for generating that string, but it should be clear what
> its purpose is.

This has already been discussed in the rest of the thread. We would have
to add meaning that isn't necessarily there. The meaning is deliberately
omitted. There are many cases we can suppose that make it difficult to
add any meaning. Instead of adding meaning, we make guarantees.

We have two audiences we need to communicate with: the client, and the
end-user. They have different needs.

The end-user only needs to be able to select an output using terminology
they will understand. We can trust compositor implementors to embue
these names with the right amount of meaning for this purpose and
to educate their users on their approach. All the client has to do to
fulfill this is faithfully communicate the name the compositor has
provided to the user.

The client needs to:

1. Provide the user a means to select an output in terms they will
   understand
2. Identify outputs across sessions

Any knowledge of the inputs that went into preparing the name are not
among the supported use-cases of this protocol. It's not important for
the client to understand that. They just need these two needs fulfilled.

To that end, rather than making a futile attempt to describe outputs in
terms that won't apply in all cases, the current revision aims only to
secure these two guarantees.

--
Drew DeVault
On 2018-04-13  4:33 PM, Pekka Paalanen wrote:
> The other events have more precise wording here, allowing the event to
> be sent again if the information changes.

This is deliberate - I don't think the name should change. I'll write it
up explicitly.
On Sat, 14 Apr 2018 10:08:35 -0400
Drew DeVault <sir@cmpwn.com> wrote:

> On 2018-04-13  4:33 PM, Pekka Paalanen wrote:
> > The other events have more precise wording here, allowing the event to
> > be sent again if the information changes.  
> 
> This is deliberate - I don't think the name should change. I'll write it
> up explicitly.

Hi,

that's seems contradictory to what you replied here:

On Wed, 11 Apr 2018 08:38:44 -0400
Drew DeVault <sir@cmpwn.com> wrote:

> > I do wonder, if I used a naming scheme like this:
> > 
> > 	on top: Intel GMA: DVI-D-1: Viewsonic VP171B (S/N: 8764358365)
> > 	on bottom: GeForce 8800: HDMI-2: HP ZDisplay K99 (S/N: 98728462)
> > 
> > and then the user reconfigures the output layout, can the compositor
> > send updated names to all clients that already have an xdg-output object?  
> 
> You could do this but it would be exceedingly silly of you considering
> that the other xdg_output requests furnish the client with layout
> information anyway.

So, I really could not do that. Very well.


Thanks,
pq
On Fri, 13 Apr 2018 16:16:34 +0200
Jonas Ådahl <jadahl@gmail.com> wrote:

> On Fri, Apr 13, 2018 at 10:05:39AM -0400, Drew DeVault wrote:
> > On 2018-04-13  4:02 PM, Jonas Ådahl wrote:  
> > > 

> > > > - Xwayland can name the X11 outputs based on their genuine names rather
> > > >   than assigning e.g. XWAYLAND0  
> > > 
> > > If the protocol is loosly specified as in it's not known what format
> > > you'll get, I don't think Xwayland can make any use of this.  
> > 
> > Can you elaborate on what expectations Xwayland would have? I am open to
> > restricting the format a bit, e.g. to ASCII characters or so.  
> 
> If we'd add quotation marks, spaces etc I'm sure many things would break
> here and there. If we start adding such restrictions, it'd hardly be
> suitable as a "human readable" kind of thing.

I believe what Jonas says as well. It could lead to another variant of
https://bugs.freedesktop.org/show_bug.cgi?id=94589
or such. Restricting to a suitable set would pretty much remove the
human-friendlyness from the name.


Thanks,
pq
On 2018-04-16 10:36 AM, Pekka Paalanen wrote:
> that's seems contradictory to what you replied here:

You're right, it does.

> > You could do this but it would be exceedingly silly of you considering
> > that the other xdg_output requests furnish the client with layout
> > information anyway.
> 
> So, I really could not do that. Very well.

Aye, that's my conclusion as well.