Discussion:
[RFC PATCH wayland-protocols] Introduce logical output protocol for Xwayland
(too old to reply)
Olivier Fourdan
2017-06-29 14:44:34 UTC
Permalink
This introduces a new protocol for the compositor to describe outputs
size in a logical way for Xwayland.

This is needed for X11 applications that would want to configure an X11
window based on the size of the output, without knowing the output scale
factor applied by the compositor to the corresponding Xwayland surface.

https://bugs.freedesktop.org/show_bug.cgi?id=101436

Signed-off-by: Olivier Fourdan <***@redhat.com>
---
Note: This is what Jonas called "wp_xwayland_configure_screen"
in https://bugs.freedesktop.org/show_bug.cgi?id=101436#c5

Makefile.am | 1 +
unstable/xwayland-logical-output/README | 5 +
.../xwayland-logical-output-unstable-v1.xml | 101 +++++++++++++++++++++
3 files changed, 107 insertions(+)
create mode 100644 unstable/xwayland-logical-output/README
create mode 100644 unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..e198362 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols = \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
+ unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml \
$(NULL)

stable_protocols = \
diff --git a/unstable/xwayland-logical-output/README b/unstable/xwayland-logical-output/README
new file mode 100644
index 0000000..efcaf69
--- /dev/null
+++ b/unstable/xwayland-logical-output/README
@@ -0,0 +1,5 @@
+Xwayland logical output protocol
+
+Maintainers:
+Olivier Fourdan <***@redhat.com>
+
diff --git a/unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml b/unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml
new file mode 100644
index 0000000..2b1d537
--- /dev/null
+++ b/unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xwayland_logical_output_unstable_v1">
+
+ <copyright>
+ Copyright © 2017 Red Hat Inc.
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="Protocol to describe logical output setup for Xwayland">
+ This optional protocol is application-specific to describe the logical
+ output setup for Xwayland. It provides a way for the compositor to
+ provide Xwayland with a specific pre-computed scaled size of the outputs.
+
+ The core Wayland interface wl_output lists all outputs and their
+ modes in hardware units along with the output scaling properties,
+ but Xwayland surfaces may be treated differently from regular Wayland
+ surfaces by the compositor, making it impossible for Xwayland to
+ reliably and consistently report all outputs to X11 clients via either
+ Xrandr or Xvidmode protocols based solely on the wl_output properties.
+
+ For example, for a compositor who does not scale Xwayland surfaces,
+ the reported output mode can match the hardware units, since the
+ requested size by X11 clients will match the actual size on the output,
+ but for another compositor who will scale the Xwayland surfaces, the
+ reported output size should be scaled down by the output scale factor
+ so that the resulting size matches the expected requested size by the
+ X11 client.
+
+ On top of that, some compositors implementing fractional scaling may
+ chose to report a larger scale factor via wl_output scale factor and
+ then scale the surface down to achieve the expected fractional scale.
+
+ This protocol specifies a way for the compositor to describe the output
+ size to Xwayland in a way that the X11 clients can use when requesting
+ a size or position.
+
+ Compositors are not required to implement this interface which remains
+ optional, however when implementing this interface, compositors are
+ required to restrict access to this application specific protocol to
+ Xwayland alone.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible
+ changes may be added together with the corresponding interface
+ version bump.
+ Backward incompatible changes are done by bumping the version
+ number in the protocol and interface names and resetting the
+ interface version. Once the protocol is to be declared stable,
+ the 'z' prefix and the version number in the protocol and
+ interface names are removed and the interface version number is
+ reset.
+ </description>
+
+ <interface name="zwp_xwayland_logical_output" version="1">
+ <description summary="Compositor logical output region">
+ A zwp_xwayland_logical_output describes part of the output geometry
+ as exposed to X11 clients by Xwayland.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space in scaled units.
+
+ This object is published during start up, when a monitor is hot
+ plugged or when the logical (scaled) size of the output is changed.
+ </description>
+
+ <event name="geometry">
+ <description summary="Logical geometry of the output">
+ The geometry event describes the logical size of a wl_output.
+
+ This event is sent when binding to the xwl_logical_output object
+ and whenever the logical size changes.
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="width" type="int"
+ summary="width of the mode in logical (scaled) units"/>
+ <arg name="height" type="int"
+ summary="height of the mode in logical (scaled) units"/>
+ </event>
+ </interface>
+
+</protocol>
+
--
2.9.4
Jonas Ådahl
2017-06-30 03:31:08 UTC
Permalink
Post by Olivier Fourdan
This introduces a new protocol for the compositor to describe outputs
size in a logical way for Xwayland.
This is needed for X11 applications that would want to configure an X11
window based on the size of the output, without knowing the output scale
factor applied by the compositor to the corresponding Xwayland surface.
So, yes, Xwayland needs this, and I see no way around it. On IRC you
raised the question whether this should really be part of wl_output is a
good question indeed. Would it ever be useful for a regular Wayland
client to know about this?

For fullscreening, we already communicate the expected size (in the
surface coordinate space) via the xdg_toplevel.configure event. Knowing
how much space is available on a work space (i.e. possibly useful for
avoiding too big windows) wouldn't be possible as this wouldn't include
panels, launchers etc, nor would the client know on what output it'll be
started (yet at least).

Adding it to wl_output might be fine anyway, as we could refer to it
when talking about how clients should not rely on calculating its own
"output size" by looking at wl_output::mode, wl_output::transform and
wl_output::scale, but we could just as well clarify that they simply
shouldn't.
Post by Olivier Fourdan
https://bugs.freedesktop.org/show_bug.cgi?id=101436
---
Note: This is what Jonas called "wp_xwayland_configure_screen"
in https://bugs.freedesktop.org/show_bug.cgi?id=101436#c5
Makefile.am | 1 +
unstable/xwayland-logical-output/README | 5 +
.../xwayland-logical-output-unstable-v1.xml | 101 +++++++++++++++++++++
3 files changed, 107 insertions(+)
create mode 100644 unstable/xwayland-logical-output/README
create mode 100644 unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index e693afa..e198362 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols = \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
+ unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/xwayland-logical-output/README b/unstable/xwayland-logical-output/README
new file mode 100644
index 0000000..efcaf69
--- /dev/null
+++ b/unstable/xwayland-logical-output/README
@@ -0,0 +1,5 @@
+Xwayland logical output protocol
+
+
diff --git a/unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml b/unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml
new file mode 100644
index 0000000..2b1d537
--- /dev/null
+++ b/unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xwayland_logical_output_unstable_v1">
+
+ <copyright>
+ Copyright © 2017 Red Hat Inc.
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="Protocol to describe logical output setup for Xwayland">
+ This optional protocol is application-specific to describe the logical
+ output setup for Xwayland. It provides a way for the compositor to
+ provide Xwayland with a specific pre-computed scaled size of the outputs.
+
+ The core Wayland interface wl_output lists all outputs and their
+ modes in hardware units along with the output scaling properties,
+ but Xwayland surfaces may be treated differently from regular Wayland
+ surfaces by the compositor, making it impossible for Xwayland to
+ reliably and consistently report all outputs to X11 clients via either
+ Xrandr or Xvidmode protocols based solely on the wl_output properties.
+
+ For example, for a compositor who does not scale Xwayland surfaces,
+ the reported output mode can match the hardware units, since the
+ requested size by X11 clients will match the actual size on the output,
+ but for another compositor who will scale the Xwayland surfaces, the
+ reported output size should be scaled down by the output scale factor
+ so that the resulting size matches the expected requested size by the
+ X11 client.
+
+ On top of that, some compositors implementing fractional scaling may
+ chose to report a larger scale factor via wl_output scale factor and
chose -> choose
Post by Olivier Fourdan
+ then scale the surface down to achieve the expected fractional scale.
+
+ This protocol specifies a way for the compositor to describe the output
+ size to Xwayland in a way that the X11 clients can use when requesting
+ a size or position.
+
+ Compositors are not required to implement this interface which remains
+ optional, however when implementing this interface, compositors are
+ required to restrict access to this application specific protocol to
+ Xwayland alone.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible
+ changes may be added together with the corresponding interface
+ version bump.
+ Backward incompatible changes are done by bumping the version
+ number in the protocol and interface names and resetting the
+ interface version. Once the protocol is to be declared stable,
+ the 'z' prefix and the version number in the protocol and
+ interface names are removed and the interface version number is
+ reset.
+ </description>
+
+ <interface name="zwp_xwayland_logical_output" version="1">
Food for thought: if we call this just "zwp_xwayland_output" or
something more generic like that we can potentially cramp more stuff
here that should only be available to Xwayand. Would just have to rename
the event to "logical_geometry".
Post by Olivier Fourdan
+ <description summary="Compositor logical output region">
+ A zwp_xwayland_logical_output describes part of the output geometry
+ as exposed to X11 clients by Xwayland.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space in scaled units.
I think we should refer to it as "compositor space" some how,
rather than "scaled". Whether it is "scaled" in some way or another
may or may not be true. Also, documenting it only in the event below
might be better, so we don't have to repeat things.
Post by Olivier Fourdan
+
+ This object is published during start up, when a monitor is hot
+ plugged or when the logical (scaled) size of the output is changed.
Should we maybe maybe make this a single "manager" kind of thing? The
wl_output is part of the event anyway, so we only need of this object.
We'll then emit events on bind or on when wl_output bound before
wl_output.done.
Post by Olivier Fourdan
+ </description>
+
+ <event name="geometry">
+ <description summary="Logical geometry of the output">
+ The geometry event describes the logical size of a wl_output.
+
+ This event is sent when binding to the xwl_logical_output object
+ and whenever the logical size changes.
As mentioned, I'd say not talking about "scaled" is better, but rather
talk about coordinate spaces, and how a surface size is represented in
it. wl_output talks about the "compositor space" which is indeed what we
are communicating here, but having an example about how the size of a
surface normally will have corresponding size in the compositor space
would be good.

For example, a surface with the same size as the size advertised here
will normally have the same size as the monitor when displayed could be
such an example.


Jonas
Post by Olivier Fourdan
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="width" type="int"
+ summary="width of the mode in logical (scaled) units"/>
+ <arg name="height" type="int"
+ summary="height of the mode in logical (scaled) units"/>
+ </event>
+ </interface>
+
+</protocol>
+
--
2.9.4
_______________________________________________
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Olivier Fourdan
2017-06-30 08:38:07 UTC
Permalink
Hi Jonas,
Post by Jonas Ådahl
Post by Olivier Fourdan
This introduces a new protocol for the compositor to describe outputs
size in a logical way for Xwayland.
This is needed for X11 applications that would want to configure an X11
window based on the size of the output, without knowing the output scale
factor applied by the compositor to the corresponding Xwayland surface.
So, yes, Xwayland needs this, and I see no way around it. On IRC you
raised the question whether this should really be part of wl_output is a
good question indeed. Would it ever be useful for a regular Wayland
client to know about this?
For fullscreening, we already communicate the expected size (in the
surface coordinate space) via the xdg_toplevel.configure event. Knowing
how much space is available on a work space (i.e. possibly useful for
avoiding too big windows) wouldn't be possible as this wouldn't include
panels, launchers etc, nor would the client know on what output it'll be
started (yet at least).
Adding it to wl_output might be fine anyway, as we could refer to it
when talking about how clients should not rely on calculating its own
"output size" by looking at wl_output::mode, wl_output::transform and
wl_output::scale, but we could just as well clarify that they simply
shouldn't.
Yes, on further consideration and as we discussed earlier today on irc, this might be of interest to some other clients as well, so adding it to the existing wl_output interface makes sense imho, rather than adding an Xwayland specific interface...
Post by Jonas Ådahl
[...]
As mentioned, I'd say not talking about "scaled" is better, but rather
talk about coordinate spaces, and how a surface size is represented in
it. wl_output talks about the "compositor space" which is indeed what we
are communicating here, but having an example about how the size of a
surface normally will have corresponding size in the compositor space
would be good.
For example, a surface with the same size as the size advertised here
will normally have the same size as the monitor when displayed could be
such an example.
I'll take this as an example in the wl_output addition indeed.

Cheers
Olivier
Pekka Paalanen
2017-06-30 09:04:51 UTC
Permalink
On Fri, 30 Jun 2017 04:38:07 -0400 (EDT)
Post by Olivier Fourdan
Hi Jonas,
Post by Jonas Ådahl
Post by Olivier Fourdan
This introduces a new protocol for the compositor to describe outputs
size in a logical way for Xwayland.
Adding it to wl_output might be fine anyway, as we could refer to it
when talking about how clients should not rely on calculating its own
"output size" by looking at wl_output::mode, wl_output::transform and
wl_output::scale, but we could just as well clarify that they simply
shouldn't.
Yes, on further consideration and as we discussed earlier today on
irc, this might be of interest to some other clients as well, so
adding it to the existing wl_output interface makes sense imho,
rather than adding an Xwayland specific interface...
Hi,

please consider that it is impossible to have a stabilization period
for changes to the wl_output interface. What ever you add will be set
in stone immediately, before a considerable user base has had a chance
to try it. There will be no going back once it's there, AFAICT no way
to have it reasonably tested on the field beforehand.

In hindsight I think the position x,y arguments we already have in
wl_output do not belong there. Only traditional 2D desktops can
meaningfully set them. They already break down completely in IVI
systems, where the outputs may be independent in the sense that there
is no path in the logical coordinate system that you could take to
travel from one output to another in a way that would make sense. Not
all systems have a single connected area created from outputs, that
design is quite specific to desktops.

I would like us to be careful with not adding more desktop assumptions
to core Wayland interfaces. Whether this proposal would add some, I
cannot tell yet.


Thanks,
pq
Olivier Fourdan
2017-07-03 08:42:52 UTC
Permalink
Hi Pekka,
Post by Pekka Paalanen
please consider that it is impossible to have a stabilization period
for changes to the wl_output interface. What ever you add will be set
in stone immediately, before a considerable user base has had a chance
to try it. There will be no going back once it's there, AFAICT no way
to have it reasonably tested on the field beforehand.
In hindsight I think the position x,y arguments we already have in
wl_output do not belong there. Only traditional 2D desktops can
meaningfully set them. They already break down completely in IVI
systems, where the outputs may be independent in the sense that there
is no path in the logical coordinate system that you could take to
travel from one output to another in a way that would make sense. Not
all systems have a single connected area created from outputs, that
design is quite specific to desktops.
I would like us to be careful with not adding more desktop assumptions
to core Wayland interfaces. Whether this proposal would add some, I
cannot tell yet.
Yes, you're right, the fact that it's needed primarily for Xwayland, which is a bit of a corner case in itself, and to avoid issues due to the way compositors treat Xwayland surfaces differently, definitely raises concerns about the relevance in wl_output...

So, 3 possibilities so far:

1. Add the logical output in wl_output
Looked like a good idea initially, not so much on further consideration.
pro: It's just an additional event to a existing Wayland core protocol
cons: It's quite limited in usefulness outside of its indented use for Xwayland and remains fairly desktop centric

2. Add a specific Xwayland protocol
pro: It's just an event for now, but this could be extended in the future, but not sure with what.
cons: might seem a bit overkill to add a new protocol just for that, unless it's extended in the future. Might need to be deprecated again if/when option #3 is chosen. Not necessarily a huge problem though if the protocol is limited to Xwayland.

3. Deprecate most of the desktop centric parts of wl_output and add a new wp_output protocol for this intended use, as discussed on irc (*)
pro: would clean up wl_output from most concepts "desktop-ish". Even if size might be less "desktop-ish" that position, Xwayland need both anyway.
cons: might take some considerable time to get to an agreement to such a protocol, could be seen as a longer term solution.

I, for one, has no preference, other than we shall need this as I see no other way to make Xwayland work reliably with the various Wayland compositors implementations that already exist.

Cheers,
Olivier

(*) incidentally, the login who captured the irc logs probably got kicked off irc, there's no more logs of past discussions:
https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=wayland&date=2017-06-30
Pekka Paalanen
2017-07-03 09:25:02 UTC
Permalink
On Mon, 3 Jul 2017 04:42:52 -0400 (EDT)
Post by Olivier Fourdan
1. Add the logical output in wl_output
Looked like a good idea initially, not so much on further
consideration. pro: It's just an additional event to a existing
Wayland core protocol cons: It's quite limited in usefulness outside
of its indented use for Xwayland and remains fairly desktop centric
Right.
Post by Olivier Fourdan
2. Add a specific Xwayland protocol
pro: It's just an event for now, but this could be extended in
the future, but not sure with what. cons: might seem a bit overkill
to add a new protocol just for that, unless it's extended in the
future. Might need to be deprecated again if/when option #3 is
chosen. Not necessarily a huge problem though if the protocol is
limited to Xwayland.
Yup.
Post by Olivier Fourdan
3. Deprecate most of the desktop centric parts of wl_output and add a
new wp_output protocol for this intended use, as discussed on irc (*)
pro: would clean up wl_output from most concepts "desktop-ish". Even
if size might be less "desktop-ish" that position, Xwayland need both
anyway. cons: might take some considerable time to get to an
agreement to such a protocol, could be seen as a longer term solution.
Maybe more along the lines of xdg_output rather than wp_output. Is
there something else desktops would need about outputs? Identification
(machine-wide unique connector name, output number?) has come up
before, in both human-readable description and persistent
machine-parseable forms. Output type (monitor, projector, ...) maybe?

No need to add everything from the start, but I think it could make
sense. Start with the position and size parameters all desktops use
today, but maybe leave them somehow optional, and don't pack more than
one thing (e.g. logical size) per event.

As for deprecation of existing wl_output bits, it could be as simple
start as changing nothing. Maybe add documentation saying that
extensions offer probably better things to use, or that some particular
parameters are not always reliable.


Thanks,
pq
Post by Olivier Fourdan
I, for one, has no preference, other than we shall need this as I see
no other way to make Xwayland work reliably with the various Wayland
compositors implementations that already exist.
Cheers,
Olivier
(*) incidentally, the login who captured the irc logs probably got
https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=wayland&date=2017-06-30
Olivier Fourdan
2017-07-03 09:42:36 UTC
Permalink
Hi Pekka,
Post by Pekka Paalanen
[...]
Maybe more along the lines of xdg_output rather than wp_output. Is
there something else desktops would need about outputs? Identification
(machine-wide unique connector name, output number?) has come up
before, in both human-readable description and persistent
machine-parseable forms. Output type (monitor, projector, ...) maybe?
No need to add everything from the start, but I think it could make
sense. Start with the position and size parameters all desktops use
today, but maybe leave them somehow optional, and don't pack more than
one thing (e.g. logical size) per event.
As for deprecation of existing wl_output bits, it could be as simple
start as changing nothing. Maybe add documentation saying that
extensions offer probably better things to use, or that some particular
parameters are not always reliable.
Right, sounds like a plan, start with a new, very simple xdg_output protocol that (at least) fulfils the needs for Xwayland at first, and extend that over time as people need more.

Cheers,
Olivier
Olivier Fourdan
2017-07-04 10:04:27 UTC
Permalink
Hi

This is a follow-up on my previous attempts at adding a logical size to
outputs (as required for Xwayland).

This introduces the xdg_output protocol aimed at complementing wl_output
for desktop specific concepts.

For now it just adds a couple of events referring to the corresponding
wl_output, but it should be extended in the future as needs arise.

For reference:

https://lists.freedesktop.org/archives/wayland-devel/2017-June/034360.html
https://lists.freedesktop.org/archives/wayland-devel/2017-June/034385.html

Cheers,
Olivier

Olivier Fourdan (1):
Add xdg-output protocol

Makefile.am | 1 +
unstable/xdg-output/README | 4 +
unstable/xdg-output/xdg-output-unstable-v1.xml | 135 +++++++++++++++++++++++++
3 files changed, 140 insertions(+)
create mode 100644 unstable/xdg-output/README
create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml
--
2.9.4
Olivier Fourdan
2017-07-04 10:04:28 UTC
Permalink
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.

Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.

The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.

For now it just features the position and logical size which describe
the output position and size in the global compositor space.

Signed-off-by: Olivier Fourdan <***@redhat.com>
---
Makefile.am | 1 +
unstable/xdg-output/README | 4 +
unstable/xdg-output/xdg-output-unstable-v1.xml | 135 +++++++++++++++++++++++++
3 files changed, 140 insertions(+)
create mode 100644 unstable/xdg-output/README
create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..6c696aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols = \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
+ unstable/xdg-output/xdg-output-unstable-v1.xml \
$(NULL)

stable_protocols = \
diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
new file mode 100644
index 0000000..e42b711
--- /dev/null
+++ b/unstable/xdg-output/README
@@ -0,0 +1,4 @@
+xdg_output protocol
+
+Maintainers:
+Olivier Fourdan <***@redhat.com>
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml
new file mode 100644
index 0000000..36e2cee
--- /dev/null
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_output_unstable_v1">
+
+ <copyright>
+ Copyright © 2017 Red Hat Inc.
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="Protocol to describe output regions">
+ This protocol aims at describing outputs in way which is more in line
+ with the concept of an output on desktop oriented systems.
+
+ Some information are more specific to the concept of an output for
+ a desktop oriented system and may not make sense in other applications,
+ such as IVI systems for example.
+
+ Some of the information provided in this protocol might be identical
+ to their counterpart already available from wl_output, in which case
+ the information provided by this protocol should be preferred to their
+ equivalent in wl_output. The goal is to move the desktop specific
+ concepts (such as output location within the global compositor space,
+ the connector name and types, etc.) out of the core wl_output protocol.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible
+ changes may be added together with the corresponding interface
+ version bump.
+ Backward incompatible changes are done by bumping the version
+ number in the protocol and interface names and resetting the
+ interface version. Once the protocol is to be declared stable,
+ the 'z' prefix and the version number in the protocol and
+ interface names are removed and the interface version number is
+ reset.
+ </description>
+
+ <interface name="zxdg_output" version="1">
+ <description summary="Compositor logical output region">
+ An xdg_output describes part of the compositor geometry.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space.
+
+ This object is published during start up, when a monitor is hot
+ plugged or when the logical size of a wl_output is changed.
+ </description>
+
+ <event name="position">
+ <description summary="Position of the output within the global compositor space">
+ The position event describes the location of the wl_output within the
+ global compositor space.
+
+ The event is sent when binding to the xdg_output interface and whenever
+ the location of the output changes within the global compositor
+ space.
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="x" type="int"
+ summary="x position within the global compositor space"/>
+ <arg name="y" type="int"
+ summary="y position within the global compositor space"/>
+ </event>
+
+ <event name="logical_size">
+ <description summary="Size of the output in the global compositor space">
+ The logical_size event describes the size of the output in the global
+ compositor space.
+
+ For example, a surface with the size matching the logical_size will
+ have the same size as the corresponding output when displayed.
+
+ Clients such as Xwayland need this to configure their surfaces in
+ the global compositor space as the compositor may apply a different
+ scale from what is advertised by the output scaling property (to
+ achieve fractional scaling, for example).
+
+ The logical size being in global compositor space implies that the
+ client does not need to apply any wl_output.scale or wl_output.rotation
+ to the given logical_size to figure the size of a surface when
+ displayed on the output.
+
+ The event is sent when binding to the xdg_output interface and whenever
+ the logical size of the output changes, either as a result of a
+ change in the applied scale or because of a change in the corresponding
+ output mode (see wl_output.mode) or transform (see wl_output.transform).
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="width" type="int"
+ summary="width of the mode in global compositor space"/>
+ <arg name="height" type="int"
+ summary="height of the mode in global compositor space"/>
+ </event>
+
+ <event name="done">
+ <description summary="Sent all information about output">
+ This event is sent after all other properties have been sent, after
+ binding to an xdg_output interface and after any other property changes
+ done after that.
+
+ This allows changes to the xdg_output properties to be seen as atomic,
+ even if they happen via multiple events.
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ </event>
+
+ <request name="release" type="destructor">
+ <description summary="Destroy the xdg_output object">
+ Using this request a client can tell the server that it is not going to
+ use the xdg_output object anymore.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
+
--
2.9.4
Olivier Fourdan
2017-07-04 12:13:43 UTC
Permalink
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.

Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.

The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.

For now it just features the position and logical size which describe
the output position and size in the global compositor space.

Signed-off-by: Olivier Fourdan <***@redhat.com>
---
v2: use "destroy" instead of "release" for destructor

Makefile.am | 1 +
unstable/xdg-output/README | 4 +
unstable/xdg-output/xdg-output-unstable-v1.xml | 135 +++++++++++++++++++++++++
3 files changed, 140 insertions(+)
create mode 100644 unstable/xdg-output/README
create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..6c696aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols = \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
+ unstable/xdg-output/xdg-output-unstable-v1.xml \
$(NULL)

stable_protocols = \
diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
new file mode 100644
index 0000000..e42b711
--- /dev/null
+++ b/unstable/xdg-output/README
@@ -0,0 +1,4 @@
+xdg_output protocol
+
+Maintainers:
+Olivier Fourdan <***@redhat.com>
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml
new file mode 100644
index 0000000..09d03eb
--- /dev/null
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_output_unstable_v1">
+
+ <copyright>
+ Copyright © 2017 Red Hat Inc.
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="Protocol to describe output regions">
+ This protocol aims at describing outputs in way which is more in line
+ with the concept of an output on desktop oriented systems.
+
+ Some information are more specific to the concept of an output for
+ a desktop oriented system and may not make sense in other applications,
+ such as IVI systems for example.
+
+ Some of the information provided in this protocol might be identical
+ to their counterpart already available from wl_output, in which case
+ the information provided by this protocol should be preferred to their
+ equivalent in wl_output. The goal is to move the desktop specific
+ concepts (such as output location within the global compositor space,
+ the connector name and types, etc.) out of the core wl_output protocol.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible
+ changes may be added together with the corresponding interface
+ version bump.
+ Backward incompatible changes are done by bumping the version
+ number in the protocol and interface names and resetting the
+ interface version. Once the protocol is to be declared stable,
+ the 'z' prefix and the version number in the protocol and
+ interface names are removed and the interface version number is
+ reset.
+ </description>
+
+ <interface name="zxdg_output" version="1">
+ <description summary="Compositor logical output region">
+ An xdg_output describes part of the compositor geometry.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space.
+
+ This object is published during start up, when a monitor is hot
+ plugged or when the logical size of a wl_output is changed.
+ </description>
+
+ <event name="position">
+ <description summary="Position of the output within the global compositor space">
+ The position event describes the location of the wl_output within the
+ global compositor space.
+
+ The event is sent when binding to the xdg_output interface and whenever
+ the location of the output changes within the global compositor
+ space.
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="x" type="int"
+ summary="x position within the global compositor space"/>
+ <arg name="y" type="int"
+ summary="y position within the global compositor space"/>
+ </event>
+
+ <event name="logical_size">
+ <description summary="Size of the output in the global compositor space">
+ The logical_size event describes the size of the output in the global
+ compositor space.
+
+ For example, a surface with the size matching the logical_size will
+ have the same size as the corresponding output when displayed.
+
+ Clients such as Xwayland need this to configure their surfaces in
+ the global compositor space as the compositor may apply a different
+ scale from what is advertised by the output scaling property (to
+ achieve fractional scaling, for example).
+
+ The logical size being in global compositor space implies that the
+ client does not need to apply any wl_output.scale or wl_output.rotation
+ to the given logical_size to figure the size of a surface when
+ displayed on the output.
+
+ The event is sent when binding to the xdg_output interface and whenever
+ the logical size of the output changes, either as a result of a
+ change in the applied scale or because of a change in the corresponding
+ output mode (see wl_output.mode) or transform (see wl_output.transform).
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="width" type="int"
+ summary="width of the mode in global compositor space"/>
+ <arg name="height" type="int"
+ summary="height of the mode in global compositor space"/>
+ </event>
+
+ <event name="done">
+ <description summary="Sent all information about output">
+ This event is sent after all other properties have been sent, after
+ binding to an xdg_output interface and after any other property changes
+ done after that.
+
+ This allows changes to the xdg_output properties to be seen as atomic,
+ even if they happen via multiple events.
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ </event>
+
+ <request name="destroy" type="destructor">
+ <description summary="Destroy the xdg_output object">
+ Using this request a client can tell the server that it is not going to
+ use the xdg_output object anymore.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
+
--
2.9.4
Pekka Paalanen
2017-07-06 08:01:47 UTC
Permalink
On Tue, 4 Jul 2017 14:13:43 +0200
Post by Olivier Fourdan
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.
Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.
The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
---
v2: use "destroy" instead of "release" for destructor
Makefile.am | 1 +
unstable/xdg-output/README | 4 +
unstable/xdg-output/xdg-output-unstable-v1.xml | 135 +++++++++++++++++++++++++
3 files changed, 140 insertions(+)
create mode 100644 unstable/xdg-output/README
create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml
Hi Olivier,

I think I can offer only mostly mechanical comments, as I am still
quite confused about how this will actually be used.
Post by Olivier Fourdan
diff --git a/Makefile.am b/Makefile.am
index e693afa..6c696aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols = \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
+ unstable/xdg-output/xdg-output-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
new file mode 100644
index 0000000..e42b711
--- /dev/null
+++ b/unstable/xdg-output/README
@@ -0,0 +1,4 @@
+xdg_output protocol
+
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml
new file mode 100644
index 0000000..09d03eb
--- /dev/null
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_output_unstable_v1">
+
+ <copyright>
+ Copyright © 2017 Red Hat Inc.
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="Protocol to describe output regions">
+ This protocol aims at describing outputs in way which is more in line
+ with the concept of an output on desktop oriented systems.
+
+ Some information are more specific to the concept of an output for
+ a desktop oriented system and may not make sense in other applications,
+ such as IVI systems for example.
Would it be good to explain here, that on desktop the outputs are
expected to form a single connected 2D region? Exactly like RandR
outputs inside a single X11 SCREEN are, IOW window spanning and input
(pointer traveling) wise. Essentially this is that "global compositor
space" implies in practice.

And that each output is rectangular, able to show the complete
described area?

Or are these not actually always true?
Post by Olivier Fourdan
+
+ Some of the information provided in this protocol might be identical
+ to their counterpart already available from wl_output, in which case
+ the information provided by this protocol should be preferred to their
+ equivalent in wl_output. The goal is to move the desktop specific
+ concepts (such as output location within the global compositor space,
+ the connector name and types, etc.) out of the core wl_output protocol.
Good.
Post by Olivier Fourdan
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible
+ changes may be added together with the corresponding interface
+ version bump.
+ Backward incompatible changes are done by bumping the version
+ number in the protocol and interface names and resetting the
+ interface version. Once the protocol is to be declared stable,
+ the 'z' prefix and the version number in the protocol and
+ interface names are removed and the interface version number is
+ reset.
+ </description>
+
+ <interface name="zxdg_output" version="1">
+ <description summary="Compositor logical output region">
+ An xdg_output describes part of the compositor geometry.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space.
+
+ This object is published during start up, when a monitor is hot
+ plugged or when the logical size of a wl_output is changed.
Do you mean that zxgd_output interface is a global interface advertised
via wl_registry?

Can you explain why picked this design instead of the (IMO) more
conventional design of advertising a global factory interface in
wl_registry, and the factory interface having a request
get_xdg_output(xdg_output new_id, wl_output base)?

I see some inconveniences with the design of using wl_output as an
event argument:

A client may bind to the same wl_output global many times. This may
happen from independent software components (libraries). The compositor
cannot know which events should be sent with which wl_output
wl_resource, so it must send events for all wl_resources pointing to
the same output. Likewise, client components then must be able to cope
with getting a wl_output proxy they did not create or set up, the first
issue there being identifying whether the user data of the proxy is of
the expected type.

Every single event in the interface must carry an explicit wl_output
argument, while this could be implicit from the xdg_output proxy
instance if it was created for a specific wl_output proxy instance to
begin with.


The more conventional design I mentioned above does impose any
additional roundtrips, the client binding to a wl_output and also
create a xdg_output immediately without waiting for any reply. The
events from both wl_output and xdg_output still come to the client in
the same burst.
Post by Olivier Fourdan
+ </description>
+
+ <event name="position">
To mirror logical_size, should this be called logical_position?
Post by Olivier Fourdan
+ <description summary="Position of the output within the global compositor space">
+ The position event describes the location of the wl_output within the
+ global compositor space.
+
+ The event is sent when binding to the xdg_output interface and whenever
+ the location of the output changes within the global compositor
+ space.
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="x" type="int"
+ summary="x position within the global compositor space"/>
+ <arg name="y" type="int"
+ summary="y position within the global compositor space"/>
+ </event>
+
+ <event name="logical_size">
+ <description summary="Size of the output in the global compositor space">
+ The logical_size event describes the size of the output in the global
+ compositor space.
+
+ For example, a surface with the size matching the logical_size will
+ have the same size as the corresponding output when displayed.
+
+ Clients such as Xwayland need this to configure their surfaces in
+ the global compositor space as the compositor may apply a different
+ scale from what is advertised by the output scaling property (to
+ achieve fractional scaling, for example).
IOW, this event is a different way of sending the output scale,
supporting arbitrary fractional values. Except that we expect most
clients to ignore this and draw with the integer scale factor, instead
of using this information and wp_viewport to realize the fractional
scale factor. Is that correct?

Should there be wording to say that "normal" - however you define that -
clients should not use this information for sizing their buffers and
surfaces? And instead rely on the xdg_shell family of interfaces to
provide a target size.

I suppose we could really use a good write-up (with examples and
pictures!) on how Xwayland and compositors are intended to use this
information, how it affects RandR parameters and how X11 clients will
use this, and how their windows go through Xwayland to the compositor,
to achieve compositor-bypass and hit the direct scanout path in a
mixed-dpi environment. I get dizzy when I try to think of that. IOW, I
feel I cannot really evaluate the suitability of this solution for the
underlying Xwayland issue.
Post by Olivier Fourdan
+
+ The logical size being in global compositor space implies that the
+ client does not need to apply any wl_output.scale or wl_output.rotation
+ to the given logical_size to figure the size of a surface when
+ displayed on the output.
The only way you can actually directly set the size of a surface is via
wp_viewport, and in all other cases the surface size is computed from
the buffer size via the client-set buffer_scale and buffer_transform.

I think you wanted to talk about the output size here, somehow, that
you are given it directly and not need to take into account
output_scale and output_transform. If one then arranges a wl_surface to
have that size, it will be the same size as the output area. So it's
about finding out what size a client wants to have, not how the size of
a wl_surface is determined. Can you see what I mean?
Post by Olivier Fourdan
+
+ The event is sent when binding to the xdg_output interface and whenever
+ the logical size of the output changes, either as a result of a
+ change in the applied scale or because of a change in the corresponding
+ output mode (see wl_output.mode) or transform (see wl_output.transform).
Ok.
Post by Olivier Fourdan
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="width" type="int"
+ summary="width of the mode in global compositor space"/>
+ <arg name="height" type="int"
+ summary="height of the mode in global compositor space"/>
+ </event>
+
+ <event name="done">
+ <description summary="Sent all information about output">
+ This event is sent after all other properties have been sent, after
+ binding to an xdg_output interface and after any other property changes
+ done after that.
+
+ This allows changes to the xdg_output properties to be seen as atomic,
+ even if they happen via multiple events.
A good idea.
Post by Olivier Fourdan
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ </event>
+
+ <request name="destroy" type="destructor">
+ <description summary="Destroy the xdg_output object">
+ Using this request a client can tell the server that it is not going to
+ use the xdg_output object anymore.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
+
Thanks,
pq
Olivier Fourdan
2017-07-06 11:53:15 UTC
Permalink
Hi Pekka,
Post by Pekka Paalanen
I think I can offer only mostly mechanical comments, as I am still
quite confused about how this will actually be used.
Well, for now, it will be used by Xwayland, might be of some interest for other clients who might need to know about the output "logical" size (e.g. screencast maybe? not even sure...).
Post by Pekka Paalanen
Would it be good to explain here, that on desktop the outputs are
expected to form a single connected 2D region? Exactly like RandR
outputs inside a single X11 SCREEN are, IOW window spanning and input
(pointer traveling) wise. Essentially this is that "global compositor
space" implies in practice.
And that each output is rectangular, able to show the complete
described area?
Or are these not actually always true?
Yes, I kind of took for granted that those concepts where defined in wl_output, but considering this protocol is aimed at complementing wl_output for the desktop concept of an ouptut, it indeed makes sense to clarify further in xdg_output.
Post by Pekka Paalanen
Post by Olivier Fourdan
+
+ Some of the information provided in this protocol might be identical
+ to their counterpart already available from wl_output, in which case
+ the information provided by this protocol should be preferred to their
+ equivalent in wl_output. The goal is to move the desktop specific
+ concepts (such as output location within the global compositor space,
+ the connector name and types, etc.) out of the core wl_output protocol.
Good.
Post by Olivier Fourdan
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible
+ changes may be added together with the corresponding interface
+ version bump.
+ Backward incompatible changes are done by bumping the version
+ number in the protocol and interface names and resetting the
+ interface version. Once the protocol is to be declared stable,
+ the 'z' prefix and the version number in the protocol and
+ interface names are removed and the interface version number is
+ reset.
+ </description>
+
+ <interface name="zxdg_output" version="1">
+ <description summary="Compositor logical output region">
+ An xdg_output describes part of the compositor geometry.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space.
+
+ This object is published during start up, when a monitor is hot
+ plugged or when the logical size of a wl_output is changed.
Do you mean that zxgd_output interface is a global interface advertised
via wl_registry?
Can you explain why picked this design instead of the (IMO) more
conventional design of advertising a global factory interface in
wl_registry, and the factory interface having a request
get_xdg_output(xdg_output new_id, wl_output base)?
Mostly because it started as an additional wl_output event I guess, but I agree a "conventional" design is more appropriate for a separate xdg_output protocol.
Post by Pekka Paalanen
I see some inconveniences with the design of using wl_output as an
A client may bind to the same wl_output global many times. This may
happen from independent software components (libraries). The compositor
cannot know which events should be sent with which wl_output
wl_resource, so it must send events for all wl_resources pointing to
the same output. Likewise, client components then must be able to cope
with getting a wl_output proxy they did not create or set up, the first
issue there being identifying whether the user data of the proxy is of
the expected type.
Every single event in the interface must carry an explicit wl_output
argument, while this could be implicit from the xdg_output proxy
instance if it was created for a specific wl_output proxy instance to
begin with.
The more conventional design I mentioned above does impose any
additional roundtrips, the client binding to a wl_output and also
create a xdg_output immediately without waiting for any reply. The
events from both wl_output and xdg_output still come to the client in
the same burst.
Right.
Post by Pekka Paalanen
Post by Olivier Fourdan
+ </description>
+
+ <event name="position">
To mirror logical_size, should this be called logical_position?
OK
Post by Pekka Paalanen
Post by Olivier Fourdan
+ <description summary="Position of the output within the global
compositor space">
+ The position event describes the location of the wl_output within the
+ global compositor space.
+
+ The event is sent when binding to the xdg_output interface and whenever
+ the location of the output changes within the global compositor
+ space.
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="x" type="int"
+ summary="x position within the global compositor space"/>
+ <arg name="y" type="int"
+ summary="y position within the global compositor space"/>
+ </event>
+
+ <event name="logical_size">
+ <description summary="Size of the output in the global compositor space">
+ The logical_size event describes the size of the output in the global
+ compositor space.
+
+ For example, a surface with the size matching the logical_size will
+ have the same size as the corresponding output when displayed.
+
+ Clients such as Xwayland need this to configure their surfaces in
+ the global compositor space as the compositor may apply a different
+ scale from what is advertised by the output scaling property (to
+ achieve fractional scaling, for example).
IOW, this event is a different way of sending the output scale,
supporting arbitrary fractional values. Except that we expect most
clients to ignore this and draw with the integer scale factor, instead
of using this information and wp_viewport to realize the fractional
scale factor. Is that correct?
Yes, but not just that, this is also to cope with the different ways weston and mutter (< 3.26) deal with Xwayland surfaces, what you mentioned about Xwayland not downscaling the advertised output size (needed for weston, but not for mutter).
Post by Pekka Paalanen
Should there be wording to say that "normal" - however you define that -
clients should not use this information for sizing their buffers and
surfaces? And instead rely on the xdg_shell family of interfaces to
provide a target size.
Yes, instead of "normal", I would that that most Wayland clients should not need this and would rely on xdg_shell interfaces.
Post by Pekka Paalanen
I suppose we could really use a good write-up (with examples and
pictures!) on how Xwayland and compositors are intended to use this
information, how it affects RandR parameters and how X11 clients will
use this, and how their windows go through Xwayland to the compositor,
Well, X11 clients could never use that directly of course.
Post by Pekka Paalanen
to achieve compositor-bypass and hit the direct scanout path in a
mixed-dpi environment. I get dizzy when I try to think of that. IOW, I
feel I cannot really evaluate the suitability of this solution for the
underlying Xwayland issue.
The Xwayland issue this is aimed at solving is current, no need to go as far as achieving compositor bypass or direct scan out (I am not sure either if the logical_size would help at all with that)

Let's take an example, a hidpi monitor 3840×2160 at scale 2.

Right now, advertised as its mode resolution in Xwayland (which doesn't take into account the wl_output scale), so Xrandr reports:

XWAYLAND1 connected 3840x2160+0+0
3840x2160 60*+

In weston, an X client trying to configure its window the size based on what Xrandr reports for the monitor ends up with a window of size 7860×4320 because weston will scale the Xwayland surface buffer by 2, whereas in mutter, the resulting window is 3840×2160 because mutter (up to 3.26) doesn't scale Xwayland surfaces. But that will eventually be configurable in mutter, so there is no "one fits all" solution other than the compositor itself telling the "logical" output size.

In such a case, weston would set the "logical_size" as 1920×1080 whereas mutter current or future version without "scale-monitor-framebuffer" set would set a logical size of 3840×2160.

With mutter implementing fractional scaling and using a scale of 1.5 (for example), it would set a wl_output.scale of 2 and set a logical size of 2560×1620.

I'll add that example in the description for logical_size.
Post by Pekka Paalanen
Post by Olivier Fourdan
+
+ The logical size being in global compositor space implies that the
+ client does not need to apply any wl_output.scale or wl_output.rotation
+ to the given logical_size to figure the size of a surface when
+ displayed on the output.
The only way you can actually directly set the size of a surface is via
wp_viewport, and in all other cases the surface size is computed from
the buffer size via the client-set buffer_scale and buffer_transform.
Yes, but that's for "regular" Wayland clients, Xwayland surface aren't scaled in mutter even though Xwayland doesn't use wl_surface.set_buffer_scale (mutter doesn't support set_buffer_transform, either)
Post by Pekka Paalanen
I think you wanted to talk about the output size here, somehow, that
you are given it directly and not need to take into account
output_scale and output_transform. If one then arranges a wl_surface to
have that size, it will be the same size as the output area. So it's
about finding out what size a client wants to have, not how the size of
a wl_surface is determined. Can you see what I mean?
I think I kinda see what you mean, I would remove that sentence altogether (it's convoluted and confusing) and rephrase the introductory sentence as:

"For example, a surface without any buffer scale, transformation
nor rotation set, with the size matching the logical_size will
have the same size as the corresponding output when displayed."
Post by Pekka Paalanen
Post by Olivier Fourdan
+
+ The event is sent when binding to the xdg_output interface and whenever
+ the logical size of the output changes, either as a result of a
+ change in the applied scale or because of a change in the corresponding
+ output mode (see wl_output.mode) or transform (see wl_output.transform).
Ok.
Post by Olivier Fourdan
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="width" type="int"
+ summary="width of the mode in global compositor space"/>
+ <arg name="height" type="int"
+ summary="height of the mode in global compositor space"/>
+ </event>
+
+ <event name="done">
+ <description summary="Sent all information about output">
+ This event is sent after all other properties have been sent, after
+ binding to an xdg_output interface and after any other property changes
+ done after that.
+
+ This allows changes to the xdg_output properties to be seen as atomic,
+ even if they happen via multiple events.
A good idea.
Not mine of course, this is from wl_output :)
Post by Pekka Paalanen
Post by Olivier Fourdan
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ </event>
+
+ <request name="destroy" type="destructor">
+ <description summary="Destroy the xdg_output object">
+ Using this request a client can tell the server that it is not going to
+ use the xdg_output object anymore.
+ </description>
+ </request>
+
+ </interface>
+</protocol>
+
Thanks for the feedback! I'll post an updated patch soon(ish).

Cheers,
Olivier
Olivier Fourdan
2017-07-06 14:01:25 UTC
Permalink
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.

Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.

The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.

For now it just features the position and logical size which describe
the output position and size in the global compositor space.

Signed-off-by: Olivier Fourdan <***@redhat.com>
---
v2: use "destroy" instead of "release" for destructor
v3: adopt a more conventional global factory interface with a
get_xdg_output() method, add some clarification and example.

Makefile.am | 1 +
unstable/xdg-output/README | 4 +
unstable/xdg-output/xdg-output-unstable-v1.xml | 160 +++++++++++++++++++++++++
3 files changed, 165 insertions(+)
create mode 100644 unstable/xdg-output/README
create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..6c696aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols = \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
+ unstable/xdg-output/xdg-output-unstable-v1.xml \
$(NULL)

stable_protocols = \
diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
new file mode 100644
index 0000000..e42b711
--- /dev/null
+++ b/unstable/xdg-output/README
@@ -0,0 +1,4 @@
+xdg_output protocol
+
+Maintainers:
+Olivier Fourdan <***@redhat.com>
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml
new file mode 100644
index 0000000..74b5762
--- /dev/null
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -0,0 +1,160 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_output_unstable_v1">
+
+ <copyright>
+ Copyright © 2017 Red Hat Inc.
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="Protocol to describe output regions">
+ This protocol aims at describing outputs in a way which is more in line
+ with the concept of an output on desktop oriented systems.
+
+ Some information are more specific to the concept of an output for
+ a desktop oriented system and may not make sense in other applications,
+ such as IVI systems for example.
+
+ Typically, the global compositor space on a desktop system is made of
+ a contiguous or overlapping set of rectangular regions.
+
+ Some of the information provided in this protocol might be identical
+ to their counterparts already available from wl_output, in which case
+ the information provided by this protocol should be preferred to their
+ equivalent in wl_output. The goal is to move the desktop specific
+ concepts (such as output location within the global compositor space,
+ the connector name and types, etc.) out of the core wl_output protocol.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible
+ changes may be added together with the corresponding interface
+ version bump.
+ Backward incompatible changes are done by bumping the version
+ number in the protocol and interface names and resetting the
+ interface version. Once the protocol is to be declared stable,
+ the 'z' prefix and the version number in the protocol and
+ interface names are removed and the interface version number is
+ reset.
+ </description>
+
+ <interface name="zxdg_output_manager" version="1">
+ <description summary="manage xdg_output objects">
+ A global factory interface for xdg_output objects.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the xdg_output_manager object">
+ Using this request a client can tell the server that it is not
+ going to use the xdg_output_manager object anymore.
+ </description>
+ </request>
+
+ <request name="get_xdg_output">
+ <description summary="create an xdg output from a wl_output">
+ This creates a new xdg_output object for the given wl_output.
+ </description>
+ <arg name="id" type="new_id" interface="zxdg_output"/>
+ <arg name="output" type="object" interface="wl_output"/>
+ </request>
+ </interface>
+
+ <interface name="zxdg_output" version="1">
+ <description summary="compositor logical output region">
+ An xdg_output describes part of the compositor geometry.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the xdg_output object">
+ Using this request a client can tell the server that it is not
+ going to use the xdg_output object anymore.
+ </description>
+ </request>
+
+ <event name="logical_position">
+ <description summary="position of the output within the global compositor space">
+ The position event describes the location of the wl_output within
+ the global compositor space.
+
+ The logical_position event is sent after creating an xdg_output
+ (see xdg_output_manager.get_xdg_output) and whenever the location
+ of the output changes within the global compositor space.
+ </description>
+ <arg name="x" type="int"
+ summary="x position within the global compositor space"/>
+ <arg name="y" type="int"
+ summary="y position within the global compositor space"/>
+ </event>
+
+ <event name="logical_size">
+ <description summary="size of the output in the global compositor space">
+ The logical_size event describes the size of the output in the
+ global compositor space.
+
+ For example, a surface without any buffer scale, transformation
+ nor rotation set, with the size matching the logical_size will
+ have the same size as the corresponding output when displayed.
+
+ Most regular Wayland clients should not pay attention to the
+ logical size and would rather rely on xdg_shell interfaces.
+
+ Some clients such as Xwayland, however, need this to configure
+ their surfaces in the global compositor space as the compositor
+ may apply a different scale from what is advertised by the output
+ scaling property (to achieve fractional scaling, for example).
+
+ For example, for a wl_output mode 3840×2160 and a scale factor 2:
+
+ - A compositor not scaling the surface buffers will advertise a
+ logical size of 3840×2160,
+
+ - A compositor automatically scaling the surface buffers will
+ advertise a logical size of 1920×1080,
+
+ - A compositor using a fractional scale of 1.5 will advertise a
+ logical size to 2560×1620.
+
+ The logical_size event is sent after creating an xdg_output
+ (see xdg_output_manager.get_xdg_output) and whenever the logical
+ size of the output changes, either as a result of a change in the
+ applied scale or because of a change in the corresponding output
+ mode(see wl_output.mode) or transform (see wl_output.transform).
+ </description>
+ <arg name="width" type="int"
+ summary="width of the mode in global compositor space"/>
+ <arg name="height" type="int"
+ summary="height of the mode in global compositor space"/>
+ </event>
+
+ <event name="done">
+ <description summary="all information about the output have been sent">
+ This event is sent after all other properties of an xdg_output
+ have been sent.
+
+ This allows changes to the xdg_output properties to be seen as
+ atomic, even if they happen via multiple events.
+ </description>
+ </event>
+
+ </interface>
+</protocol>
+
--
2.9.4
Jonas Ådahl
2017-07-14 08:45:21 UTC
Permalink
Post by Olivier Fourdan
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.
Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.
The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
This one is

Reviewed-by: Jonas Ådahl <***@gmail.com>

but I'll wait with landing to see whether a consensus can be reached in
the E-mail thread.


Jonas
Post by Olivier Fourdan
---
v2: use "destroy" instead of "release" for destructor
v3: adopt a more conventional global factory interface with a
get_xdg_output() method, add some clarification and example.
Makefile.am | 1 +
unstable/xdg-output/README | 4 +
unstable/xdg-output/xdg-output-unstable-v1.xml | 160 +++++++++++++++++++++++++
3 files changed, 165 insertions(+)
create mode 100644 unstable/xdg-output/README
create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index e693afa..6c696aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols = \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
+ unstable/xdg-output/xdg-output-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
new file mode 100644
index 0000000..e42b711
--- /dev/null
+++ b/unstable/xdg-output/README
@@ -0,0 +1,4 @@
+xdg_output protocol
+
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml
new file mode 100644
index 0000000..74b5762
--- /dev/null
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -0,0 +1,160 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_output_unstable_v1">
+
+ <copyright>
+ Copyright © 2017 Red Hat Inc.
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="Protocol to describe output regions">
+ This protocol aims at describing outputs in a way which is more in line
+ with the concept of an output on desktop oriented systems.
+
+ Some information are more specific to the concept of an output for
+ a desktop oriented system and may not make sense in other applications,
+ such as IVI systems for example.
+
+ Typically, the global compositor space on a desktop system is made of
+ a contiguous or overlapping set of rectangular regions.
+
+ Some of the information provided in this protocol might be identical
+ to their counterparts already available from wl_output, in which case
+ the information provided by this protocol should be preferred to their
+ equivalent in wl_output. The goal is to move the desktop specific
+ concepts (such as output location within the global compositor space,
+ the connector name and types, etc.) out of the core wl_output protocol.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible
+ changes may be added together with the corresponding interface
+ version bump.
+ Backward incompatible changes are done by bumping the version
+ number in the protocol and interface names and resetting the
+ interface version. Once the protocol is to be declared stable,
+ the 'z' prefix and the version number in the protocol and
+ interface names are removed and the interface version number is
+ reset.
+ </description>
+
+ <interface name="zxdg_output_manager" version="1">
+ <description summary="manage xdg_output objects">
+ A global factory interface for xdg_output objects.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the xdg_output_manager object">
+ Using this request a client can tell the server that it is not
+ going to use the xdg_output_manager object anymore.
+ </description>
+ </request>
+
+ <request name="get_xdg_output">
+ <description summary="create an xdg output from a wl_output">
+ This creates a new xdg_output object for the given wl_output.
+ </description>
+ <arg name="id" type="new_id" interface="zxdg_output"/>
+ <arg name="output" type="object" interface="wl_output"/>
+ </request>
+ </interface>
+
+ <interface name="zxdg_output" version="1">
+ <description summary="compositor logical output region">
+ An xdg_output describes part of the compositor geometry.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the xdg_output object">
+ Using this request a client can tell the server that it is not
+ going to use the xdg_output object anymore.
+ </description>
+ </request>
+
+ <event name="logical_position">
+ <description summary="position of the output within the global compositor space">
+ The position event describes the location of the wl_output within
+ the global compositor space.
+
+ The logical_position event is sent after creating an xdg_output
+ (see xdg_output_manager.get_xdg_output) and whenever the location
+ of the output changes within the global compositor space.
+ </description>
+ <arg name="x" type="int"
+ summary="x position within the global compositor space"/>
+ <arg name="y" type="int"
+ summary="y position within the global compositor space"/>
+ </event>
+
+ <event name="logical_size">
+ <description summary="size of the output in the global compositor space">
+ The logical_size event describes the size of the output in the
+ global compositor space.
+
+ For example, a surface without any buffer scale, transformation
+ nor rotation set, with the size matching the logical_size will
+ have the same size as the corresponding output when displayed.
+
+ Most regular Wayland clients should not pay attention to the
+ logical size and would rather rely on xdg_shell interfaces.
+
+ Some clients such as Xwayland, however, need this to configure
+ their surfaces in the global compositor space as the compositor
+ may apply a different scale from what is advertised by the output
+ scaling property (to achieve fractional scaling, for example).
+
+
+ - A compositor not scaling the surface buffers will advertise a
+ logical size of 3840×2160,
+
+ - A compositor automatically scaling the surface buffers will
+ advertise a logical size of 1920×1080,
+
+ - A compositor using a fractional scale of 1.5 will advertise a
+ logical size to 2560×1620.
+
+ The logical_size event is sent after creating an xdg_output
+ (see xdg_output_manager.get_xdg_output) and whenever the logical
+ size of the output changes, either as a result of a change in the
+ applied scale or because of a change in the corresponding output
+ mode(see wl_output.mode) or transform (see wl_output.transform).
+ </description>
+ <arg name="width" type="int"
+ summary="width of the mode in global compositor space"/>
+ <arg name="height" type="int"
+ summary="height of the mode in global compositor space"/>
+ </event>
+
+ <event name="done">
+ <description summary="all information about the output have been sent">
+ This event is sent after all other properties of an xdg_output
+ have been sent.
+
+ This allows changes to the xdg_output properties to be seen as
+ atomic, even if they happen via multiple events.
+ </description>
+ </event>
+
+ </interface>
+</protocol>
+
--
2.9.4
Pekka Paalanen
2017-07-18 12:57:34 UTC
Permalink
On Thu, 6 Jul 2017 16:01:25 +0200
Post by Olivier Fourdan
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.
Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.
The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
---
v2: use "destroy" instead of "release" for destructor
v3: adopt a more conventional global factory interface with a
get_xdg_output() method, add some clarification and example.
Makefile.am | 1 +
unstable/xdg-output/README | 4 +
unstable/xdg-output/xdg-output-unstable-v1.xml | 160 +++++++++++++++++++++++++
3 files changed, 165 insertions(+)
create mode 100644 unstable/xdg-output/README
create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index e693afa..6c696aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols = \
unstable/tablet/tablet-unstable-v2.xml \
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
+ unstable/xdg-output/xdg-output-unstable-v1.xml \
$(NULL)
stable_protocols = \
diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
new file mode 100644
index 0000000..e42b711
--- /dev/null
+++ b/unstable/xdg-output/README
@@ -0,0 +1,4 @@
+xdg_output protocol
+
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml
new file mode 100644
index 0000000..74b5762
--- /dev/null
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -0,0 +1,160 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_output_unstable_v1">
+
...
Post by Olivier Fourdan
+ <interface name="zxdg_output_manager" version="1">
Hi,

missing major version as per unstable protocol policy.
Post by Olivier Fourdan
+ <description summary="manage xdg_output objects">
+ A global factory interface for xdg_output objects.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the xdg_output_manager object">
+ Using this request a client can tell the server that it is not
+ going to use the xdg_output_manager object anymore.
Might want to add: Any objects already created through this instance
are not affected.
Post by Olivier Fourdan
+ </description>
+ </request>
+
+ <request name="get_xdg_output">
+ <description summary="create an xdg output from a wl_output">
+ This creates a new xdg_output object for the given wl_output.
+ </description>
+ <arg name="id" type="new_id" interface="zxdg_output"/>
+ <arg name="output" type="object" interface="wl_output"/>
+ </request>
+ </interface>
+
+ <interface name="zxdg_output" version="1">
Missing major version as per unstable protocol policy.
Post by Olivier Fourdan
+ <description summary="compositor logical output region">
+ An xdg_output describes part of the compositor geometry.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space.
I was about to ask about clone mode behaviour but realised this is
explicitly tied to how wl_outputs are advertised.
Post by Olivier Fourdan
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the xdg_output object">
+ Using this request a client can tell the server that it is not
+ going to use the xdg_output object anymore.
+ </description>
+ </request>
+
+ <event name="logical_position">
+ <description summary="position of the output within the global compositor space">
+ The position event describes the location of the wl_output within
+ the global compositor space.
+
+ The logical_position event is sent after creating an xdg_output
+ (see xdg_output_manager.get_xdg_output) and whenever the location
+ of the output changes within the global compositor space.
+ </description>
+ <arg name="x" type="int"
+ summary="x position within the global compositor space"/>
+ <arg name="y" type="int"
+ summary="y position within the global compositor space"/>
+ </event>
+
+ <event name="logical_size">
+ <description summary="size of the output in the global compositor space">
+ The logical_size event describes the size of the output in the
+ global compositor space.
+
+ For example, a surface without any buffer scale, transformation
+ nor rotation set, with the size matching the logical_size will
+ have the same size as the corresponding output when displayed.
+
+ Most regular Wayland clients should not pay attention to the
+ logical size and would rather rely on xdg_shell interfaces.
+
+ Some clients such as Xwayland, however, need this to configure
+ their surfaces in the global compositor space as the compositor
+ may apply a different scale from what is advertised by the output
+ scaling property (to achieve fractional scaling, for example).
+
+
+ - A compositor not scaling the surface buffers will advertise a
+ logical size of 3840×2160,
+
+ - A compositor automatically scaling the surface buffers will
+ advertise a logical size of 1920×1080,
+
+ - A compositor using a fractional scale of 1.5 will advertise a
+ logical size to 2560×1620.
+
+ The logical_size event is sent after creating an xdg_output
+ (see xdg_output_manager.get_xdg_output) and whenever the logical
+ size of the output changes, either as a result of a change in the
+ applied scale or because of a change in the corresponding output
+ mode(see wl_output.mode) or transform (see wl_output.transform).
+ </description>
+ <arg name="width" type="int"
+ summary="width of the mode in global compositor space"/>
+ <arg name="height" type="int"
+ summary="height of the mode in global compositor space"/>
Replace "mode" with a more appropriate word or remove it. Mode refers
to the hardware video mode, and I think it is a bit confusing to talk
about size of a mode in global compositor space, even though it is
accurate.
Post by Olivier Fourdan
+ </event>
+
+ <event name="done">
+ <description summary="all information about the output have been sent">
+ This event is sent after all other properties of an xdg_output
+ have been sent.
+
+ This allows changes to the xdg_output properties to be seen as
+ atomic, even if they happen via multiple events.
+ </description>
+ </event>
+
+ </interface>
+</protocol>
+
Otherwise looks good, so:
Acked-by: Pekka Paalanen <***@collabora.co.uk>


Thanks,
pq
Olivier Fourdan
2017-07-19 08:51:41 UTC
Permalink
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.

Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.

The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.

For now it just features the position and logical size which describe
the output position and size in the global compositor space.

Signed-off-by: Olivier Fourdan <***@redhat.com>
Reviewed-by: Jonas Ådahl <***@gmail.com>
Acked-by: Pekka Paalanen <***@collabora.co.uk>
---
v2: use "destroy" instead of "release" for destructor
v3: adopt a more conventional global factory interface with a
get_xdg_output() method, add some clarification and example.
v4: Rebase on current master
Add major version in interface name as per Pekka's review
Add that objects already created are not affected by the manager
destroy method.
Remove the word "mode" from argument summary for logical_size as
per Pekka's review
Add A-b Pekka and R-b Jonas following their respective feedback.

Makefile.am | 1 +
unstable/xdg-output/README | 4 +
unstable/xdg-output/xdg-output-unstable-v1.xml | 162 +++++++++++++++++++++++++
3 files changed, 167 insertions(+)
create mode 100644 unstable/xdg-output/README
create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index d100c13..5b5ae96 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,6 +14,7 @@ unstable_protocols = \
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \
unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml \
unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
+ unstable/xdg-output/xdg-output-unstable-v1.xml \
$(NULL)

stable_protocols = \
diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
new file mode 100644
index 0000000..e42b711
--- /dev/null
+++ b/unstable/xdg-output/README
@@ -0,0 +1,4 @@
+xdg_output protocol
+
+Maintainers:
+Olivier Fourdan <***@redhat.com>
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml
new file mode 100644
index 0000000..8a403a5
--- /dev/null
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -0,0 +1,162 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_output_unstable_v1">
+
+ <copyright>
+ Copyright © 2017 Red Hat Inc.
+
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of this software and associated documentation files (the "Software"),
+ to deal in the Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <description summary="Protocol to describe output regions">
+ This protocol aims at describing outputs in a way which is more in line
+ with the concept of an output on desktop oriented systems.
+
+ Some information are more specific to the concept of an output for
+ a desktop oriented system and may not make sense in other applications,
+ such as IVI systems for example.
+
+ Typically, the global compositor space on a desktop system is made of
+ a contiguous or overlapping set of rectangular regions.
+
+ Some of the information provided in this protocol might be identical
+ to their counterparts already available from wl_output, in which case
+ the information provided by this protocol should be preferred to their
+ equivalent in wl_output. The goal is to move the desktop specific
+ concepts (such as output location within the global compositor space,
+ the connector name and types, etc.) out of the core wl_output protocol.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible
+ changes may be added together with the corresponding interface
+ version bump.
+ Backward incompatible changes are done by bumping the version
+ number in the protocol and interface names and resetting the
+ interface version. Once the protocol is to be declared stable,
+ the 'z' prefix and the version number in the protocol and
+ interface names are removed and the interface version number is
+ reset.
+ </description>
+
+ <interface name="zxdg_output_manager_v1" version="1">
+ <description summary="manage xdg_output objects">
+ A global factory interface for xdg_output objects.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the xdg_output_manager object">
+ Using this request a client can tell the server that it is not
+ going to use the xdg_output_manager object anymore.
+
+ Any objects already created through this instance are not affected.
+ </description>
+ </request>
+
+ <request name="get_xdg_output">
+ <description summary="create an xdg output from a wl_output">
+ This creates a new xdg_output object for the given wl_output.
+ </description>
+ <arg name="id" type="new_id" interface="zxdg_output"/>
+ <arg name="output" type="object" interface="wl_output"/>
+ </request>
+ </interface>
+
+ <interface name="zxdg_output_v1" version="1">
+ <description summary="compositor logical output region">
+ An xdg_output describes part of the compositor geometry.
+
+ This typically corresponds to a monitor that displays part of the
+ compositor space.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the xdg_output object">
+ Using this request a client can tell the server that it is not
+ going to use the xdg_output object anymore.
+ </description>
+ </request>
+
+ <event name="logical_position">
+ <description summary="position of the output within the global compositor space">
+ The position event describes the location of the wl_output within
+ the global compositor space.
+
+ The logical_position event is sent after creating an xdg_output
+ (see xdg_output_manager.get_xdg_output) and whenever the location
+ of the output changes within the global compositor space.
+ </description>
+ <arg name="x" type="int"
+ summary="x position within the global compositor space"/>
+ <arg name="y" type="int"
+ summary="y position within the global compositor space"/>
+ </event>
+
+ <event name="logical_size">
+ <description summary="size of the output in the global compositor space">
+ The logical_size event describes the size of the output in the
+ global compositor space.
+
+ For example, a surface without any buffer scale, transformation
+ nor rotation set, with the size matching the logical_size will
+ have the same size as the corresponding output when displayed.
+
+ Most regular Wayland clients should not pay attention to the
+ logical size and would rather rely on xdg_shell interfaces.
+
+ Some clients such as Xwayland, however, need this to configure
+ their surfaces in the global compositor space as the compositor
+ may apply a different scale from what is advertised by the output
+ scaling property (to achieve fractional scaling, for example).
+
+ For example, for a wl_output mode 3840×2160 and a scale factor 2:
+
+ - A compositor not scaling the surface buffers will advertise a
+ logical size of 3840×2160,
+
+ - A compositor automatically scaling the surface buffers will
+ advertise a logical size of 1920×1080,
+
+ - A compositor using a fractional scale of 1.5 will advertise a
+ logical size to 2560×1620.
+
+ The logical_size event is sent after creating an xdg_output
+ (see xdg_output_manager.get_xdg_output) and whenever the logical
+ size of the output changes, either as a result of a change in the
+ applied scale or because of a change in the corresponding output
+ mode(see wl_output.mode) or transform (see wl_output.transform).
+ </description>
+ <arg name="width" type="int"
+ summary="width in global compositor space"/>
+ <arg name="height" type="int"
+ summary="height in global compositor space"/>
+ </event>
+
+ <event name="done">
+ <description summary="all information about the output have been sent">
+ This event is sent after all other properties of an xdg_output
+ have been sent.
+
+ This allows changes to the xdg_output properties to be seen as
+ atomic, even if they happen via multiple events.
+ </description>
+ </event>
+
+ </interface>
+</protocol>
+
--
2.9.4
Pekka Paalanen
2017-07-20 08:48:46 UTC
Permalink
On Wed, 19 Jul 2017 10:51:41 +0200
Post by Olivier Fourdan
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.
Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.
The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
---
v2: use "destroy" instead of "release" for destructor
v3: adopt a more conventional global factory interface with a
get_xdg_output() method, add some clarification and example.
v4: Rebase on current master
Add major version in interface name as per Pekka's review
Add that objects already created are not affected by the manager
destroy method.
Remove the word "mode" from argument summary for logical_size as
per Pekka's review
Add A-b Pekka and R-b Jonas following their respective feedback.
Makefile.am | 1 +
unstable/xdg-output/README | 4 +
unstable/xdg-output/xdg-output-unstable-v1.xml | 162 +++++++++++++++++++++++++
3 files changed, 167 insertions(+)
create mode 100644 unstable/xdg-output/README
create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml
+ <interface name="zxdg_output_manager_v1" version="1">
+ <description summary="manage xdg_output objects">
+ A global factory interface for xdg_output objects.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the xdg_output_manager object">
+ Using this request a client can tell the server that it is not
+ going to use the xdg_output_manager object anymore.
+
+ Any objects already created through this instance are not affected.
+ </description>
+ </request>
+
+ <request name="get_xdg_output">
+ <description summary="create an xdg output from a wl_output">
+ This creates a new xdg_output object for the given wl_output.
+ </description>
+ <arg name="id" type="new_id" interface="zxdg_output"/>
Hi,

you forgot to update the interface name in the arg.

Fixing that, you can upgrade my Acked-by to Reviewed-by. :-)
No need to send v5 for me.
Post by Olivier Fourdan
+ <arg name="output" type="object" interface="wl_output"/>
+ </request>
+ </interface>
+
+ <interface name="zxdg_output_v1" version="1">
Thanks,
pq
Olivier Fourdan
2017-07-20 09:58:33 UTC
Permalink
Hi Pekka,
Post by Pekka Paalanen
you forgot to update the interface name in the arg.
Argh!...
Post by Pekka Paalanen
Fixing that, you can upgrade my Acked-by to Reviewed-by. :-)
No need to send v5 for me.
Humm, I need to send an update nevertheless, otherwise we shall forget about your comment and the wrong version might end up being pushed eventually.

I'll wait a couple of more days to see if anyone else has something to add though.

Cheers,
Olivier

Pekka Paalanen
2017-07-06 14:24:39 UTC
Permalink
Hi Olivier,

it's very hard for me to wrap my head around this, so the below may
sound a bit harsh, sorry. I don't mean to rant, but I feel there is
something fundamental amiss. I am diving back into the high-level
design which is fairly separated from the xdg_output interface.

On Thu, 6 Jul 2017 07:53:15 -0400 (EDT)
Post by Olivier Fourdan
Post by Pekka Paalanen
Post by Olivier Fourdan
+ <event name="position">
To mirror logical_size, should this be called logical_position?
OK
Post by Pekka Paalanen
Post by Olivier Fourdan
+ <description summary="Position of the output within the
global compositor space">
+ The position event describes the location of the
wl_output within the
+ global compositor space.
+
+ The event is sent when binding to the xdg_output
interface and whenever
+ the location of the output changes within the global
compositor
+ space.
+ </description>
+ <arg name="output" type="object" interface="wl_output"
+ summary="corresponding wl_output"/>
+ <arg name="x" type="int"
+ summary="x position within the global compositor
space"/>
+ <arg name="y" type="int"
+ summary="y position within the global compositor
space"/>
+ </event>
+
+ <event name="logical_size">
+ <description summary="Size of the output in the global compositor space">
+ The logical_size event describes the size of the output
in the global
+ compositor space.
+
+ For example, a surface with the size matching the
logical_size will
+ have the same size as the corresponding output when
displayed. +
+ Clients such as Xwayland need this to configure their
surfaces in
+ the global compositor space as the compositor may apply
a different
+ scale from what is advertised by the output scaling
property (to
+ achieve fractional scaling, for example).
IOW, this event is a different way of sending the output scale,
supporting arbitrary fractional values. Except that we expect most
clients to ignore this and draw with the integer scale factor,
instead of using this information and wp_viewport to realize the
fractional scale factor. Is that correct?
Yes, but not just that, this is also to cope with the different ways
weston and mutter (< 3.26) deal with Xwayland surfaces, what you
mentioned about Xwayland not downscaling the advertised output size
(needed for weston, but not for mutter).
Right... let me think out loud once again.

X11 essentially uses a single global coordinate space for everything.
Traditionally it has no scaling, so window and output sizes are in the
same units. It must keep a single concept of a unit pixel to be
consistent.

But we could do the scaling two ways: a) consider everything X11 to be
scale=1, or b) consider everything X11 to be scale=N. Both are
consistent. However, using mixed-dpi setup, it would be inconsistent to
advertise all outputs with the hardware resolutions unscaled.

...

Ok, I'm not sure where I was going with that.
Post by Olivier Fourdan
Post by Pekka Paalanen
I suppose we could really use a good write-up (with examples and
pictures!) on how Xwayland and compositors are intended to use this
information, how it affects RandR parameters and how X11 clients
will use this, and how their windows go through Xwayland to the
compositor,
Well, X11 clients could never use that directly of course.
If this affects what sizes RandR exposes and if X11 apps use RandR as
the base to size and position their windows, then this does fairly
explicitly affect how X11 apps work. But that's only one thing they
might do, they might look at SCREEN dimensions(?) and whatever... does
Xinerama protocol provide yet another way to get "the same" information?
Post by Olivier Fourdan
Post by Pekka Paalanen
to achieve compositor-bypass and hit the direct scanout path in a
mixed-dpi environment. I get dizzy when I try to think of that.
IOW, I feel I cannot really evaluate the suitability of this
solution for the underlying Xwayland issue.
The Xwayland issue this is aimed at solving is current, no need to go
as far as achieving compositor bypass or direct scan out (I am not
sure either if the logical_size would help at all with that)
Well, when we think about what we should expose in RandR, and assuming
there are apps, e.g. fullscreen games, that use that information for
window size, and window size determines buffer size, which eventually
is related to whether one can scan it out without scaling as
intended... or deliberately with scaling when picking a "non-native"
resolution via RandR... luckily modern hardware is usually capable of
scaling at scanout, so a wrong scale is not a performance-cliff.

Yes, that is not the current issue, but I have a feeling that the
solutions to both issues are intertwined, which makes me fear of an
arbitrary decision making something else impossible. But that's me.
Post by Olivier Fourdan
Let's take an example, a hidpi monitor 3840×2160 at scale 2.
Right now, advertised as its mode resolution in Xwayland (which
XWAYLAND1 connected 3840x2160+0+0
3840x2160 60*+
In weston, an X client trying to configure its window the size based
on what Xrandr reports for the monitor ends up with a window of size
7860×4320 because weston will scale the Xwayland surface buffer by 2,
whereas in mutter, the resulting window is 3840×2160 because mutter
(up to 3.26) doesn't scale Xwayland surfaces. But that will
eventually be configurable in mutter, so there is no "one fits all"
solution other than the compositor itself telling the "logical"
output size.
Ok, I get that. It the difference in the chosen global scale factor
between X11 coordinate system and the compositor logical coordinate
system.
Post by Olivier Fourdan
In such a case, weston would set the "logical_size" as 1920×1080
whereas mutter current or future version without
"scale-monitor-framebuffer" set would set a logical size of 3840×2160.
Don't forget that it will also affect input coordinates. Setting the
logical_size effectively chooses a single scale factor for all X11, and
even in a mixed-dpi setting, outputs must not disagree on what the
scale factor is, otherwise I would expect e.g. input to become nearly
impossible to get right.
Post by Olivier Fourdan
With mutter implementing fractional scaling and using a scale of 1.5
(for example), it would set a wl_output.scale of 2 and set a logical
size of 2560×1620.
RandR would advertise 2560×1620, X11 apps will create windows and
buffers of that size, and then mutter will... scale them how?

If it assumes the Xwayland windows are already in scale=2, the
wl_surface size becomes 1280×810, and that scaled up to the output
factor 1.5 gets us to 1920×1215.

If it assumes Xwayland windows are not to be scaled at all, the surface
size becomes 2560×1620, which on the 1.5 output will be 3840×1620. That
means that the compositor is up-scaling for the output, not
down-scaling as I understood was intended.

If it assumes Xwayland windows are literally not to be scaled at all,
the size on the 1.5 output will be 2560×1620, which calculating
backwards would mean surface size 1706.7×1080.

I am so confused, because it feels like you are inventing scaling
factors here and there to get the numbers you want, without any design
on what the coordinate systems actually are. OTOH, I always think in
coordinate systems and how to map from one to another, how you move on
the 2D plane and how that motion translates to the other one,
especially when crossing from a low-dpi output to a high-dpi output. I
would love to see the coordinate systems drawn out, and the mappings
between them written down, parametrized with what we intend to have in
protocol and in compositor scaling modes.

I also cherish the idea of a chain of coordinate transformations. Start
with coordinate system 1, apply transformation A, end up in coordinate
system 2, apply transformation B, end up in coordinate system 3. All
transformations are invertible. If there is more than one chain of
transformations between two coordinate systems, the total
transformations must be identical. The less exceptions on when each
coordinate system applies, the better. This might be obvious, but it
must also hold when traveling in a coordinate system and crossing
window and output boundaries, and that is where I think we will hit
problems. The transformations do not apply only to points, they must
also apply to vectors (motion).


I still think that handling Xwayland as a special client that does not
obey the normal Wayland protocol semantics like how the size of a
wl_surface is determined from buffer size, buffer_scale and
buffer_transform, maybe via wp_viewport, is not a good design. I'm not
sure if Mutter does that or not.
Post by Olivier Fourdan
I'll add that example in the description for logical_size.
I think this would need a separate design document with pictures,
cramming it into the protocol doc doesn't seem feasible to me. Ideally
we'd have it in the Wayland docbook. I see no problem having
desktop-specific chapters there.
Post by Olivier Fourdan
Post by Pekka Paalanen
Post by Olivier Fourdan
+
+ The logical size being in global compositor space
implies that the
+ client does not need to apply any wl_output.scale or
wl_output.rotation
+ to the given logical_size to figure the size of a
surface when
+ displayed on the output.
The only way you can actually directly set the size of a surface is
via wp_viewport, and in all other cases the surface size is
computed from the buffer size via the client-set buffer_scale and
buffer_transform.
Yes, but that's for "regular" Wayland clients, Xwayland surface
aren't scaled in mutter even though Xwayland doesn't use
wl_surface.set_buffer_scale (mutter doesn't support
set_buffer_transform, either)
Right, I think that's a mistake. Or at least it makes me not understand
at all how Mutter can work in a mixed-dpi setup.
Post by Olivier Fourdan
Post by Pekka Paalanen
I think you wanted to talk about the output size here, somehow, that
you are given it directly and not need to take into account
output_scale and output_transform. If one then arranges a
wl_surface to have that size, it will be the same size as the
output area. So it's about finding out what size a client wants to
have, not how the size of a wl_surface is determined. Can you see
what I mean?
I think I kinda see what you mean, I would remove that sentence
altogether (it's convoluted and confusing) and rephrase the
"For example, a surface without any buffer scale, transformation
nor rotation set, with the size matching the logical_size will
have the same size as the corresponding output when displayed."
I think it could be simplified even further. A wl_surface whose size
equals the logical_size of an output, will be shown at the size of the
output.

There is no reason to rule out buffer_scale, buffer_transform, or
wp_viewport, because all they do is affect what size the wl_surface
will be based on the buffer size. A client can set all those any way it
wants if the resulting wl_surface size equals the output logical_size.
Post by Olivier Fourdan
Post by Pekka Paalanen
Post by Olivier Fourdan
+ <event name="done">
+ <description summary="Sent all information about output">
+ This event is sent after all other properties have
been sent, after
+ binding to an xdg_output interface and after any other
property changes
+ done after that.
+
+ This allows changes to the xdg_output properties to be
seen as atomic,
+ even if they happen via multiple events.
A good idea.
Not mine of course, this is from wl_output :)
Yes, it is good to not make the same mistake twice. ;-)


Thanks,
pq
Olivier Fourdan
2017-07-07 08:21:57 UTC
Permalink
Hi Pekka,
Post by Pekka Paalanen
it's very hard for me to wrap my head around this, so the below may
sound a bit harsh, sorry. I don't mean to rant, but I feel there is
something fundamental amiss. I am diving back into the high-level
design which is fairly separated from the xdg_output interface.
No worries, but my goal with the protocol proposal (being an Xwayland specific proposal initially, or merely an additional wl_output event or now a more generic xdg_output protocol to be extended in the future with whatever people want for desktop output uses) is to make Xwayland work with the current existing design/implementations, not to advocate for or against an existing design or particular compositor implementation.

WRT fractional scaling, my understanding of the design in mutter is based on this document:

https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html

I cannot really comment on the design decisions, nor how those decisions were made, Jonas would probably be in a better position for this.

Regarding this particular discussion about the need of xdg_output and logical size/position, I am completely open to suggestions, how would see Xwayland work with both weston and mutter as they are now and mutter in the future when it implements fractional scaling, without adding logical size in xdg_output (or even not adding xdg_output at all)?
Post by Pekka Paalanen
Post by Olivier Fourdan
Post by Pekka Paalanen
[...]
IOW, this event is a different way of sending the output scale,
supporting arbitrary fractional values. Except that we expect most
clients to ignore this and draw with the integer scale factor,
instead of using this information and wp_viewport to realize the
fractional scale factor. Is that correct?
Yes, but not just that, this is also to cope with the different ways
weston and mutter (< 3.26) deal with Xwayland surfaces, what you
mentioned about Xwayland not downscaling the advertised output size
(needed for weston, but not for mutter).
Right... let me think out loud once again.
X11 essentially uses a single global coordinate space for everything.
Traditionally it has no scaling, so window and output sizes are in the
same units. It must keep a single concept of a unit pixel to be
consistent.
But we could do the scaling two ways: a) consider everything X11 to be
scale=1, or b) consider everything X11 to be scale=N. Both are
consistent. However, using mixed-dpi setup, it would be inconsistent to
advertise all outputs with the hardware resolutions unscaled.
...
Ok, I'm not sure where I was going with that.
Mixed dpi doesn't work in GNOME/x11, does it?

GNOME implementation of HiDPI on x11 uses an xsettings, which by definition is per screen (in x11 terminology), thus not per monitor.

https://wiki.gnome.org/HowDoI/HiDpi

So fixing mixed DPI in Xwayland will require additional mechanisms (possibly new EWMH properties?), but this is not part of this proposal.

However, nothing would stop an x11 client or toolkit from querying the monitor's mode and physical size (using xrandx), computing the current DPI depending on the monitor it resides and adapting its rendering based on that. X11 has all the mechanisms in place for that, it's just that most clients won't do that (iirc, Firefox has something like that at some point, not sure it's still used though)

That makes a wide range of different x11 clients who behave differently:

- Plain old x11 clients, who don't know anything about DPI
- gtk+/GNOME clients, who base their rendering on a specific xsettings Gdk/WindowScalingFactor and/or a envvar read by clutter,
- Some other app trying to compute DPI themselves (very few, I think of Firefox, LibreOffice maybe? not sure at all about those)

I'm don't see how Xwayland could change its behavior for each app, xrandr is not per client. I guess we could come up with a new window property that Xwayland could monitor and set the buffer scale accordingly, maybe? Anyhow, that's going off topic wrt the xdg_output protocol, I'm afraid.

The "benefit" I see in "lying" to the clients in xrandr by advertising a lower mode than actual is that it solves the problem in a consistent way for all these cases even those clients who try to compute the DPI themselves).

There are some additional discussions in https://bugs.freedesktop.org/show_bug.cgi?id=93315
Post by Pekka Paalanen
Post by Olivier Fourdan
Post by Pekka Paalanen
I suppose we could really use a good write-up (with examples and
pictures!) on how Xwayland and compositors are intended to use this
information, how it affects RandR parameters and how X11 clients
will use this, and how their windows go through Xwayland to the
compositor,
Well, X11 clients could never use that directly of course.
If this affects what sizes RandR exposes and if X11 apps use RandR as
the base to size and position their windows, then this does fairly
explicitly affect how X11 apps work. But that's only one thing they
might do, they might look at SCREEN dimensions(?) and whatever... does
Xinerama protocol provide yet another way to get "the same" information?
Xwayland computes the screen size by adding up the output size and position. So it all comes from the same wl_output description (for now).

Plain x11 screen width/height, Xrandr, Xinerama and even Xvidmode will remain consistent.
Post by Pekka Paalanen
Post by Olivier Fourdan
Post by Pekka Paalanen
to achieve compositor-bypass and hit the direct scanout path in a
mixed-dpi environment. I get dizzy when I try to think of that.
IOW, I feel I cannot really evaluate the suitability of this
solution for the underlying Xwayland issue.
The Xwayland issue this is aimed at solving is current, no need to go
as far as achieving compositor bypass or direct scan out (I am not
sure either if the logical_size would help at all with that)
Well, when we think about what we should expose in RandR, and assuming
there are apps, e.g. fullscreen games, that use that information for
window size, and window size determines buffer size, which eventually
is related to whether one can scan it out without scaling as
intended... or deliberately with scaling when picking a "non-native"
resolution via RandR... luckily modern hardware is usually capable of
scaling at scanout, so a wrong scale is not a performance-cliff.
Yes, that is not the current issue, but I have a feeling that the
solutions to both issues are intertwined, which makes me fear of an
arbitrary decision making something else impossible. But that's me.
Post by Olivier Fourdan
Let's take an example, a hidpi monitor 3840×2160 at scale 2.
Right now, advertised as its mode resolution in Xwayland (which
XWAYLAND1 connected 3840x2160+0+0
3840x2160 60*+
In weston, an X client trying to configure its window the size based
on what Xrandr reports for the monitor ends up with a window of size
7860×4320 because weston will scale the Xwayland surface buffer by 2,
whereas in mutter, the resulting window is 3840×2160 because mutter
(up to 3.26) doesn't scale Xwayland surfaces. But that will
eventually be configurable in mutter, so there is no "one fits all"
solution other than the compositor itself telling the "logical"
output size.
Ok, I get that. It the difference in the chosen global scale factor
between X11 coordinate system and the compositor logical coordinate
system.
Post by Olivier Fourdan
In such a case, weston would set the "logical_size" as 1920×1080
whereas mutter current or future version without
"scale-monitor-framebuffer" set would set a logical size of 3840×2160.
Don't forget that it will also affect input coordinates. Setting the
logical_size effectively chooses a single scale factor for all X11, and
even in a mixed-dpi setting, outputs must not disagree on what the
scale factor is, otherwise I would expect e.g. input to become nearly
impossible to get right.
Post by Olivier Fourdan
With mutter implementing fractional scaling and using a scale of 1.5
(for example), it would set a wl_output.scale of 2 and set a logical
size of 2560×1620.
RandR would advertise 2560×1620, X11 apps will create windows and
buffers of that size, and then mutter will... scale them how?
If it assumes the Xwayland windows are already in scale=2, the
wl_surface size becomes 1280×810, and that scaled up to the output
factor 1.5 gets us to 1920×1215.
If it assumes Xwayland windows are not to be scaled at all, the surface
size becomes 2560×1620, which on the 1.5 output will be 3840×1620. That
means that the compositor is up-scaling for the output, not
down-scaling as I understood was intended.
If it assumes Xwayland windows are literally not to be scaled at all,
the size on the 1.5 output will be 2560×1620, which calculating
backwards would mean surface size 1706.7×1080.
If randr advertise the output mode 3840×2160 as 2560×1620 with a fractional scale of 1.5, then the compositor would scale the buffer up by that fractional scaling factor, i.e. 1.5, which gives the expected 3840×2160.

I don't see how downscaling an already tiny x11 window would work. Take a basic x11 app, say xterm, with its default fixed font size. It looks "fine" on a low DPI monitor, but is completely unreadable on a hidpi screen (at least for my old eyes), so the goal would be to scale it up, not down.

The scale factor of 2 advertised in wl_output would be for Wayland native clients, so they can set their buffer scale to that scale 2, and then be downscaled by the compositor to achieve the expected fractional scale of 1.5 with best rendering on screen.

If the compositor was to scale Xwayland surfaces by 2 as well and then downscale to achieve the expected fractional scale of 1.5, it would downscale by a factor of (2÷1.5) = 1.33, in which case it would simply advertise a logical size of 5120×2880 (i.e [3840 × 2 ÷ 1.5]×[2160 × 2 ÷ 1.5]) - That's the whole idea behind the logical size, whatever the compositor does eventually, Xwayland gets it right as long as the compositor advertise the expected size once the scaling factor -whatever it is- is applied, if that makes any sense.

At least it's how I understood it from the description from:

https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html

But I might be wrong in my understanding :)
Post by Pekka Paalanen
I am so confused, because it feels like you are inventing scaling
factors here and there to get the numbers you want, without any design
on what the coordinate systems actually are. OTOH, I always think in
coordinate systems and how to map from one to another, how you move on
the 2D plane and how that motion translates to the other one,
especially when crossing from a low-dpi output to a high-dpi output. I
would love to see the coordinate systems drawn out, and the mappings
between them written down, parametrized with what we intend to have in
protocol and in compositor scaling modes.
I read this as a question about fractional scaling design, not how Xwayland would advertise output size.
Post by Pekka Paalanen
I also cherish the idea of a chain of coordinate transformations. Start
with coordinate system 1, apply transformation A, end up in coordinate
system 2, apply transformation B, end up in coordinate system 3. All
transformations are invertible. If there is more than one chain of
transformations between two coordinate systems, the total
transformations must be identical. The less exceptions on when each
coordinate system applies, the better. This might be obvious, but it
must also hold when traveling in a coordinate system and crossing
window and output boundaries, and that is where I think we will hit
problems. The transformations do not apply only to points, they must
also apply to vectors (motion).
That's up to the compositor, not Xwayland, innit? Xwayland is just a Wayland client and has no control on that.
Post by Pekka Paalanen
I still think that handling Xwayland as a special client that does not
obey the normal Wayland protocol semantics like how the size of a
wl_surface is determined from buffer size, buffer_scale and
buffer_transform, maybe via wp_viewport, is not a good design. I'm not
sure if Mutter does that or not.
If you want to see how current mutter works with mixed DPI and Xwayland, you can try mutter nested with:

$ MUTTER_DEBUG_NUM_DUMMY_MONITORS=2 MUTTER_DEBUG_DUMMY_MONITOR_SCALES=2,1 mutter --wayland --nested

(from the HiDPI GNOME wiki page mentioned above)

And then run an xterm on the correspnding X11 display:

$ DISPLAY=:1 xterm
Post by Pekka Paalanen
Post by Olivier Fourdan
I'll add that example in the description for logical_size.
I think this would need a separate design document with pictures,
cramming it into the protocol doc doesn't seem feasible to me. Ideally
we'd have it in the Wayland docbook. I see no problem having
desktop-specific chapters there.
Post by Olivier Fourdan
Post by Pekka Paalanen
Post by Olivier Fourdan
+
+ The logical size being in global compositor space
implies that the
+ client does not need to apply any wl_output.scale or
wl_output.rotation
+ to the given logical_size to figure the size of a
surface when
+ displayed on the output.
The only way you can actually directly set the size of a surface is
via wp_viewport, and in all other cases the surface size is
computed from the buffer size via the client-set buffer_scale and
buffer_transform.
Yes, but that's for "regular" Wayland clients, Xwayland surface
aren't scaled in mutter even though Xwayland doesn't use
wl_surface.set_buffer_scale (mutter doesn't support
set_buffer_transform, either)
Right, I think that's a mistake. Or at least it makes me not understand
at all how Mutter can work in a mixed-dpi setup.
You mean mutter or Xwayland with mutter? Either way, it's a comment for mutter devs.
Post by Pekka Paalanen
Post by Olivier Fourdan
Post by Pekka Paalanen
I think you wanted to talk about the output size here, somehow, that
you are given it directly and not need to take into account
output_scale and output_transform. If one then arranges a
wl_surface to have that size, it will be the same size as the
output area. So it's about finding out what size a client wants to
have, not how the size of a wl_surface is determined. Can you see
what I mean?
I think I kinda see what you mean, I would remove that sentence
altogether (it's convoluted and confusing) and rephrase the
"For example, a surface without any buffer scale, transformation
nor rotation set, with the size matching the logical_size will
have the same size as the corresponding output when displayed."
I think it could be simplified even further. A wl_surface whose size
equals the logical_size of an output, will be shown at the size of the
output.
There is no reason to rule out buffer_scale, buffer_transform, or
wp_viewport, because all they do is affect what size the wl_surface
will be based on the buffer size. A client can set all those any way it
wants if the resulting wl_surface size equals the output logical_size.
Post by Olivier Fourdan
Post by Pekka Paalanen
Post by Olivier Fourdan
+ <event name="done">
+ <description summary="Sent all information about output">
+ This event is sent after all other properties have
been sent, after
+ binding to an xdg_output interface and after any other
property changes
+ done after that.
+
+ This allows changes to the xdg_output properties to be
seen as atomic,
+ even if they happen via multiple events.
A good idea.
Not mine of course, this is from wl_output :)
Yes, it is good to not make the same mistake twice. ;-)
Cheers,
Olivier
Pekka Paalanen
2017-07-12 09:07:29 UTC
Permalink
On Fri, 7 Jul 2017 04:21:57 -0400 (EDT)
Post by Olivier Fourdan
Hi Pekka,
Post by Pekka Paalanen
it's very hard for me to wrap my head around this, so the below may
sound a bit harsh, sorry. I don't mean to rant, but I feel there is
something fundamental amiss. I am diving back into the high-level
design which is fairly separated from the xdg_output interface.
No worries, but my goal with the protocol proposal (being an Xwayland
specific proposal initially, or merely an additional wl_output event
or now a more generic xdg_output protocol to be extended in the
future with whatever people want for desktop output uses) is to make
Xwayland work with the current existing design/implementations, not
to advocate for or against an existing design or particular
compositor implementation.
Hi Olivier,

if the intention is not to evaluate whether the current implementations
are actually workable in the long run, then should the new interface be
named so that we can throw it away if it actually doesn't work? And not
design anything else directly on top of it, so that it remains
relatively easy to throw away, i.e. stop using?
Post by Olivier Fourdan
https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html
I cannot really comment on the design decisions, nor how those
decisions were made, Jonas would probably be in a better position for
this.
That email talks about a new feature, separated coordinate spaces:
logical and physical. I believe that is the correct design.

But I have understood that you want to make Xwayland work with the
design before that one, which I cannot see how it could work. Do you
really need to make Xwayland work well with that old design?

I fully agree with section 1, Overall approach.

Section 5 mentions a hwdb-alike database but keyed by EDID data. This is
something Keith Packard needs for his VR work to identify HMDs and I
discussed with him about it a bit. I think the scaling info would be a
good fit there.

Section 7 touches the game and fullscreen topic, which I believe is
important for deciding how RandR should advertise output resolutions.

Section 8 is exactly what we are talking about in this thread, right?


What resolution do you want RandR to advertise to X11 apps?

If it is the physical output resolution, the window size in logical
units will be wrong unless XWM can reliably detect the X11 application
is actually intending to use the physical resolution. How would one do
that?

If it is the logical output size, the window size in logical units will
be correct, but the X11 application cannot provide a buffer of the
physical output resolution, which means the Wayland compositor must
scale the image. If the buffer can hit direct scanout, that should be
no problem, but otherwise it could be a performance issue. (I agree to
prefer this option.)

In any case, there is a single (default) "scaling factor" covering all
X11 clients in an Xwayland instance, because neither Xwayland nor XWM
have per-window knowledge of the scaling the X11 app used. Also, X11
apps are laid out in a global coordinate space spanning all outputs
(within a X11 SCREEN), and also input works in that global coordinate
space with trivial conversions to per-window coordinates. I assume
Xwayland converts per-wl_surface input coordinates to global input
coordinates in the X11 space before dispatching to the X11 windows,
which means that the Wayland server must send input events taking that
into account. How will input work in the proposals?

I do not like the idea of special-casing the Xwayland Wayland client in
the Wayland compositor outside of XWM, even less if it requires special
mangling for input as well. How much special casing do you do? Or maybe
I'm just biased and it would actually be fairly easy to implement in
Weston with a little bit of API... Quentin might have some opinions
here.
Post by Olivier Fourdan
Regarding this particular discussion about the need of xdg_output and
logical size/position, I am completely open to suggestions, how would
see Xwayland work with both weston and mutter as they are now and
mutter in the future when it implements fractional scaling, without
adding logical size in xdg_output (or even not adding xdg_output at
all)?
I wouldn't say "without", I just do not understand how it all is
supposed to work in a mixed-dpi hardware setup. If we design an
interface that just cannot work in a mixed-dpi setup, we should be
able to throw it away later.

So I'm starting to think that the way forward is to design the new
interface such that it is easy to deprecate if it turns out to be a
dead end, or keep it if turns out future-proof.

Yeah, I'm going in circles here as I'm trying to find out what the
goals are.
Post by Olivier Fourdan
Mixed dpi doesn't work in GNOME/x11, does it?
I guess - do you want to keep that status quo?
Post by Olivier Fourdan
GNOME implementation of HiDPI on x11 uses an xsettings, which by
definition is per screen (in x11 terminology), thus not per monitor.
https://wiki.gnome.org/HowDoI/HiDpi
So fixing mixed DPI in Xwayland will require additional mechanisms
(possibly new EWMH properties?), but this is not part of this
proposal.
I would not want to go there. I would prefer to keep all of X11 in a
single scale factor, and scale accordingly in the compositor. That is
what I call a working mixed-dpi setup - it may not be pixel-perfect
pretty, but at least everything is readable and not blown up.

Maybe the definition of "mixed-dpi support" is what we disagree here.

In my mind, Xwayland cannot provide full mixed-dpi support, because X11
is simply incapable of it with current toolkits. It can provide partial
mixed-dpi support however, where the Wayland compositor is
automatically scaling, assuming all X11 apps are configured to use the
same scale factor.

It same as with Wayland apps: HiDPI unaware apps get partial mixed-dpi
support, while HiDPI aware apps get the full mixed-dpi support.

This would classify all HiDPI-aware X11 apps as being somewhere between
HiDPI unaware and aware Wayland apps: they cannot communicate their
scaling factor, but they can be configured as a group to always draw
with a given scaling factor.
Post by Olivier Fourdan
However, nothing would stop an x11 client or toolkit from querying
the monitor's mode and physical size (using xrandx), computing the
current DPI depending on the monitor it resides and adapting its
rendering based on that. X11 has all the mechanisms in place for
that, it's just that most clients won't do that (iirc, Firefox has
something like that at some point, not sure it's still used though)
That's actually a case I didn't even think of. I've only been thinking
about apps that want to make their window cover an output, like games.
This is a very good topic to bring up.
Post by Olivier Fourdan
That makes a wide range of different x11 clients who behave
- Plain old x11 clients, who don't know anything about DPI
- gtk+/GNOME clients, who base their rendering on a specific
xsettings Gdk/WindowScalingFactor and/or a envvar read by clutter,
- Some other app trying to compute DPI themselves (very few, I think
of Firefox, LibreOffice maybe? not sure at all about those)
I'm don't see how Xwayland could change its behavior for each app,
xrandr is not per client. I guess we could come up with a new window
property that Xwayland could monitor and set the buffer scale
accordingly, maybe? Anyhow, that's going off topic wrt the xdg_output
protocol, I'm afraid.
I agree, I don't see the worth in implementing per-X11-window scales.

Therefore we need to stick with one scale over all X11 clients. If
there are plain old clients in that set, then the only workable factor
for X11 is scale=1. Would you agree with that?
Post by Olivier Fourdan
The "benefit" I see in "lying" to the clients in xrandr by
advertising a lower mode than actual is that it solves the problem in
a consistent way for all these cases even those clients who try to
compute the DPI themselves).
How does it solve it for all the cases? Does it not help only with the
third case, while the first and second are unaffected? Not to belittle
the benefit, just wanting to be accurate.
Post by Olivier Fourdan
There are some additional discussions in
https://bugs.freedesktop.org/show_bug.cgi?id=93315
Xwayland computes the screen size by adding up the output size and
position. So it all comes from the same wl_output description (for
now).
Plain x11 screen width/height, Xrandr, Xinerama and even Xvidmode will remain consistent.
That's nice, it's all consistent. We just need to be similarly
consistent in what we advertise as size in RandR. It means it has to
make sense in a mixed-dpi setup.
Post by Olivier Fourdan
If randr advertise the output mode 3840×2160 as 2560×1620 with a
fractional scale of 1.5, then the compositor would scale the buffer
up by that fractional scaling factor, i.e. 1.5, which gives the
expected 3840×2160.
I don't see how downscaling an already tiny x11 window would work.
Take a basic x11 app, say xterm, with its default fixed font size. It
looks "fine" on a low DPI monitor, but is completely unreadable on a
hidpi screen (at least for my old eyes), so the goal would be to
scale it up, not down.
The scale factor of 2 advertised in wl_output would be for Wayland
native clients, so they can set their buffer scale to that scale 2,
and then be downscaled by the compositor to achieve the expected
fractional scale of 1.5 with best rendering on screen.
Oh yes, I forgot that the X11 apps in this case are always drawing with
scale=1, so they are expected to be scaled up indeed. I must have been
thinking about all of X11 land being configured with scale=2.
Post by Olivier Fourdan
If the compositor was to scale Xwayland surfaces by 2 as well and
I think you mean the X11 apps are configured to draw in scale=2, right?
Post by Olivier Fourdan
then downscale to achieve the expected fractional scale of 1.5, it
would downscale by a factor of (2÷1.5) = 1.33, in which case it would
simply advertise a logical size of 5120×2880 (i.e [3840 × 2 ÷
1.5]×[2160 × 2 ÷ 1.5]) - That's the whole idea behind the logical
size, whatever the compositor does eventually, Xwayland gets it right
as long as the compositor advertise the expected size once the
scaling factor -whatever it is- is applied, if that makes any sense.
https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html
But I might be wrong in my understanding :)
Yes, now we are onto something. This feels good, considering outputs in
isolation. I didn't actually go through the numbers yet to make sure the
example is right, though.
Post by Olivier Fourdan
Post by Pekka Paalanen
I am so confused, because it feels like you are inventing scaling
factors here and there to get the numbers you want, without any
design on what the coordinate systems actually are. OTOH, I always
think in coordinate systems and how to map from one to another, how
you move on the 2D plane and how that motion translates to the
other one, especially when crossing from a low-dpi output to a
high-dpi output. I would love to see the coordinate systems drawn
out, and the mappings between them written down, parametrized with
what we intend to have in protocol and in compositor scaling
modes.
I read this as a question about fractional scaling design, not how
Xwayland would advertise output size.
They are all related. Xwayland itself together with all X11 clients use
a coordinate system, and everything needs to be consistent: RandR,
window placement, buffers, input.
Post by Olivier Fourdan
Post by Pekka Paalanen
I also cherish the idea of a chain of coordinate transformations.
Start with coordinate system 1, apply transformation A, end up in
coordinate system 2, apply transformation B, end up in coordinate
system 3. All transformations are invertible. If there is more than
one chain of transformations between two coordinate systems, the
total transformations must be identical. The less exceptions on
when each coordinate system applies, the better. This might be
obvious, but it must also hold when traveling in a coordinate
system and crossing window and output boundaries, and that is where
I think we will hit problems. The transformations do not apply only
to points, they must also apply to vectors (motion).
That's up to the compositor, not Xwayland, innit? Xwayland is just a
Wayland client and has no control on that.
No, I believe Xwayland converts input coordinates from per-wl_surface
to global X11 coordinates, and then does everything in the global X11
coordinate system which is all that X11 apps ever know about.

ISTR there have been Xwayland patches going back and forth on that
design, so I'm not sure what the current state actually is. It
definitely is tricky code in Xwayland.
Post by Olivier Fourdan
Post by Pekka Paalanen
Post by Olivier Fourdan
Yes, but that's for "regular" Wayland clients, Xwayland surface
aren't scaled in mutter even though Xwayland doesn't use
wl_surface.set_buffer_scale (mutter doesn't support
set_buffer_transform, either)
Right, I think that's a mistake. Or at least it makes me not
understand at all how Mutter can work in a mixed-dpi setup.
You mean mutter or Xwayland with mutter? Either way, it's a comment for mutter devs.
Mutter with Xwayland, yes, and more precisely the partial HiDPI support
which is fundamental in getting X11 apps show up readable and not blown
up.

We actually can make even plain old X11 apps scale up properly on HiDPI
outputs, if the Wayland compositor's design allows it. And it sounds
like the new coordinate systems work in Mutter is going to allow that,
while the old way of never scale any X11 window was as bad as native
X11 on HiDPI.

So my criticism here is against caring at all about the old way of
never scaling any X11 window in the Wayland compositor. Maybe I have
misunderstood and you don't care about it?


Thanks,
pq
Jonas Ådahl
2017-07-14 08:40:32 UTC
Permalink
This E-mail is quite long, but I tried to reply to some parts.
Post by Pekka Paalanen
On Fri, 7 Jul 2017 04:21:57 -0400 (EDT)
Post by Olivier Fourdan
Hi Pekka,
Post by Pekka Paalanen
it's very hard for me to wrap my head around this, so the below may
sound a bit harsh, sorry. I don't mean to rant, but I feel there is
something fundamental amiss. I am diving back into the high-level
design which is fairly separated from the xdg_output interface.
No worries, but my goal with the protocol proposal (being an Xwayland
specific proposal initially, or merely an additional wl_output event
or now a more generic xdg_output protocol to be extended in the
future with whatever people want for desktop output uses) is to make
Xwayland work with the current existing design/implementations, not
to advocate for or against an existing design or particular
compositor implementation.
Hi Olivier,
if the intention is not to evaluate whether the current implementations
are actually workable in the long run, then should the new interface be
named so that we can throw it away if it actually doesn't work? And not
design anything else directly on top of it, so that it remains
relatively easy to throw away, i.e. stop using?
Post by Olivier Fourdan
WRT fractional scaling, my understanding of the design in mutter is
https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html
I cannot really comment on the design decisions, nor how those
decisions were made, Jonas would probably be in a better position for
this.
logical and physical. I believe that is the correct design.
But I have understood that you want to make Xwayland work with the
design before that one, which I cannot see how it could work. Do you
really need to make Xwayland work well with that old design?
The benefit of the current/old design (in mutter) is that X11 clients
don't particularly regress in functionality, compared to how it worked
before. HiDPI aware clients work just as well, and non-HiDPI clients
works just as bad.

Naturally, if we can make both HiDPI aware and HiDPI unaware X11 clients
work good, that's the most optimal, but I find it hard to believe we can
make that happen without adaptations to HiDPI aware X11 clients (like
mentioned EWMH extensions or something).
Post by Pekka Paalanen
I fully agree with section 1, Overall approach.
Section 5 mentions a hwdb-alike database but keyed by EDID data. This is
something Keith Packard needs for his VR work to identify HMDs and I
discussed with him about it a bit. I think the scaling info would be a
good fit there.
Section 7 touches the game and fullscreen topic, which I believe is
important for deciding how RandR should advertise output resolutions.
Section 8 is exactly what we are talking about in this thread, right?
Right. Lets split up Xwayland support into three distinguishable parts:

(A) Plain old Xwayland support with no HiDPI awareness or anything

(B) Fullscreen windows with buffer size matching the monitor framebuffer
it is fullscreen on

(C) HiDPI aware X11 clients.


For (A), this protocol solves the problem more or less completely
without any further changes. No input transformation changes needed
anywhere, not in Xwayland, not in any compositor. It is just a way to
communicate the logical layout of the screen to Xwayland so that it can
position its buffer-scale-1 windows in a grid that matches the global
compositor coordinate space.
Post by Pekka Paalanen
What resolution do you want RandR to advertise to X11 apps?
If it is the physical output resolution, the window size in logical
units will be wrong unless XWM can reliably detect the X11 application
is actually intending to use the physical resolution. How would one do
that?
This is about part (B).

How? I'd say, probably only using "best effort" emulation strategies,
like detecting fullscreen windows matching the physical resolution set
and assuming anything else should be hidden, then using wp_viewporter or
something to make it to the logical size, which should result in no
scaling being done by the compositor.
Post by Pekka Paalanen
If it is the logical output size, the window size in logical units will
be correct, but the X11 application cannot provide a buffer of the
physical output resolution, which means the Wayland compositor must
scale the image. If the buffer can hit direct scanout, that should be
no problem, but otherwise it could be a performance issue. (I agree to
prefer this option.)
It'll be a regression quality wise though, as something somewhere will
have to scale up from the logical to the physical resolution. Long term,
this is not acceptable as it'll mean games and other applications where
graphics quality is important that also won't be ported would regress.

However, as a first step I think this is what we should do since it's
trivial. This is what (A) does.
Post by Pekka Paalanen
In any case, there is a single (default) "scaling factor" covering all
X11 clients in an Xwayland instance, because neither Xwayland nor XWM
have per-window knowledge of the scaling the X11 app used. Also, X11
apps are laid out in a global coordinate space spanning all outputs
(within a X11 SCREEN), and also input works in that global coordinate
space with trivial conversions to per-window coordinates. I assume
Xwayland converts per-wl_surface input coordinates to global input
coordinates in the X11 space before dispatching to the X11 windows,
which means that the Wayland server must send input events taking that
into account. How will input work in the proposals?
I do not like the idea of special-casing the Xwayland Wayland client in
the Wayland compositor outside of XWM, even less if it requires special
mangling for input as well. How much special casing do you do? Or maybe
I'm just biased and it would actually be fairly easy to implement in
Weston with a little bit of API... Quentin might have some opinions
here.
Are you talking about (C) here? I don't really have a thought out idea
or plan how it should work, but EWMH is mentioned, but whether Xwayland
should play a part or not I'm not sure. I suspect it'll require changes
to X11 clients to make it work though.
Post by Pekka Paalanen
Post by Olivier Fourdan
Regarding this particular discussion about the need of xdg_output and
logical size/position, I am completely open to suggestions, how would
see Xwayland work with both weston and mutter as they are now and
mutter in the future when it implements fractional scaling, without
adding logical size in xdg_output (or even not adding xdg_output at
all)?
I wouldn't say "without", I just do not understand how it all is
supposed to work in a mixed-dpi hardware setup. If we design an
interface that just cannot work in a mixed-dpi setup, we should be
able to throw it away later.
So I'm starting to think that the way forward is to design the new
interface such that it is easy to deprecate if it turns out to be a
dead end, or keep it if turns out future-proof.
Well, this is an unstable wayland-protocols protocol, so we are
completely free to abandon it right? If we need xdg_output to do
something else after having abandoned the purpose of it now, we're also
free to reinvent it.
Post by Pekka Paalanen
Yeah, I'm going in circles here as I'm trying to find out what the
goals are.
Post by Olivier Fourdan
Mixed dpi doesn't work in GNOME/x11, does it?
I guess - do you want to keep that status quo?
It does not indeed.
Post by Pekka Paalanen
Post by Olivier Fourdan
GNOME implementation of HiDPI on x11 uses an xsettings, which by
definition is per screen (in x11 terminology), thus not per monitor.
https://wiki.gnome.org/HowDoI/HiDpi
So fixing mixed DPI in Xwayland will require additional mechanisms
(possibly new EWMH properties?), but this is not part of this
proposal.
I would not want to go there. I would prefer to keep all of X11 in a
single scale factor, and scale accordingly in the compositor. That is
what I call a working mixed-dpi setup - it may not be pixel-perfect
pretty, but at least everything is readable and not blown up.
Maybe the definition of "mixed-dpi support" is what we disagree here.
In my mind, Xwayland cannot provide full mixed-dpi support, because X11
is simply incapable of it with current toolkits. It can provide partial
mixed-dpi support however, where the Wayland compositor is
automatically scaling, assuming all X11 apps are configured to use the
same scale factor.
It same as with Wayland apps: HiDPI unaware apps get partial mixed-dpi
support, while HiDPI aware apps get the full mixed-dpi support.
This would classify all HiDPI-aware X11 apps as being somewhere between
HiDPI unaware and aware Wayland apps: they cannot communicate their
scaling factor, but they can be configured as a group to always draw
with a given scaling factor.
Post by Olivier Fourdan
However, nothing would stop an x11 client or toolkit from querying
the monitor's mode and physical size (using xrandx), computing the
current DPI depending on the monitor it resides and adapting its
rendering based on that. X11 has all the mechanisms in place for
that, it's just that most clients won't do that (iirc, Firefox has
something like that at some point, not sure it's still used though)
That's actually a case I didn't even think of. I've only been thinking
about apps that want to make their window cover an output, like games.
This is a very good topic to bring up.
Post by Olivier Fourdan
That makes a wide range of different x11 clients who behave
- Plain old x11 clients, who don't know anything about DPI
- gtk+/GNOME clients, who base their rendering on a specific
xsettings Gdk/WindowScalingFactor and/or a envvar read by clutter,
- Some other app trying to compute DPI themselves (very few, I think
of Firefox, LibreOffice maybe? not sure at all about those)
I'm don't see how Xwayland could change its behavior for each app,
xrandr is not per client. I guess we could come up with a new window
property that Xwayland could monitor and set the buffer scale
accordingly, maybe? Anyhow, that's going off topic wrt the xdg_output
protocol, I'm afraid.
I agree, I don't see the worth in implementing per-X11-window scales.
Therefore we need to stick with one scale over all X11 clients. If
there are plain old clients in that set, then the only workable factor
for X11 is scale=1. Would you agree with that?
Post by Olivier Fourdan
The "benefit" I see in "lying" to the clients in xrandr by
advertising a lower mode than actual is that it solves the problem in
a consistent way for all these cases even those clients who try to
compute the DPI themselves).
How does it solve it for all the cases? Does it not help only with the
third case, while the first and second are unaffected? Not to belittle
the benefit, just wanting to be accurate.
For the first case, this proposal makes it at least work at all, i.e.
xterm becomes readable by default.

For the second case, in GNOME, we (at least now) simply set the Xsetting
scaling factor to 1 via gnome-settings-daemon.

For the third case, as Olivier mentiones, makes self calculating clients
think the resolution isn't that high so they might avoid scaling up.
Post by Pekka Paalanen
Post by Olivier Fourdan
There are some additional discussions in
https://bugs.freedesktop.org/show_bug.cgi?id=93315
Xwayland computes the screen size by adding up the output size and
position. So it all comes from the same wl_output description (for
now).
Plain x11 screen width/height, Xrandr, Xinerama and even Xvidmode
will remain consistent.
That's nice, it's all consistent. We just need to be similarly
consistent in what we advertise as size in RandR. It means it has to
make sense in a mixed-dpi setup.
Post by Olivier Fourdan
If randr advertise the output mode 3840×2160 as 2560×1620 with a
fractional scale of 1.5, then the compositor would scale the buffer
up by that fractional scaling factor, i.e. 1.5, which gives the
expected 3840×2160.
I don't see how downscaling an already tiny x11 window would work.
Take a basic x11 app, say xterm, with its default fixed font size. It
looks "fine" on a low DPI monitor, but is completely unreadable on a
hidpi screen (at least for my old eyes), so the goal would be to
scale it up, not down.
The scale factor of 2 advertised in wl_output would be for Wayland
native clients, so they can set their buffer scale to that scale 2,
and then be downscaled by the compositor to achieve the expected
fractional scale of 1.5 with best rendering on screen.
Oh yes, I forgot that the X11 apps in this case are always drawing with
scale=1, so they are expected to be scaled up indeed. I must have been
thinking about all of X11 land being configured with scale=2.
Post by Olivier Fourdan
If the compositor was to scale Xwayland surfaces by 2 as well and
I think you mean the X11 apps are configured to draw in scale=2, right?
Post by Olivier Fourdan
then downscale to achieve the expected fractional scale of 1.5, it
would downscale by a factor of (2÷1.5) = 1.33, in which case it would
simply advertise a logical size of 5120×2880 (i.e [3840 × 2 ÷
1.5]×[2160 × 2 ÷ 1.5]) - That's the whole idea behind the logical
size, whatever the compositor does eventually, Xwayland gets it right
as long as the compositor advertise the expected size once the
scaling factor -whatever it is- is applied, if that makes any sense.
https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html
But I might be wrong in my understanding :)
Yes, now we are onto something. This feels good, considering outputs in
isolation. I didn't actually go through the numbers yet to make sure the
example is right, though.
Telling Xwayland the logical output is twice as large as the logical
output actually is, then assuming surface are scale=2 would, I think,
make HiDPI aware clients draw properly, but it'd also make things like
xterm and gitk become completely unusable always right?
Post by Pekka Paalanen
Post by Olivier Fourdan
Post by Pekka Paalanen
I am so confused, because it feels like you are inventing scaling
factors here and there to get the numbers you want, without any
design on what the coordinate systems actually are. OTOH, I always
think in coordinate systems and how to map from one to another, how
you move on the 2D plane and how that motion translates to the
other one, especially when crossing from a low-dpi output to a
high-dpi output. I would love to see the coordinate systems drawn
out, and the mappings between them written down, parametrized with
what we intend to have in protocol and in compositor scaling
modes.
I read this as a question about fractional scaling design, not how
Xwayland would advertise output size.
They are all related. Xwayland itself together with all X11 clients use
a coordinate system, and everything needs to be consistent: RandR,
window placement, buffers, input.
Post by Olivier Fourdan
Post by Pekka Paalanen
I also cherish the idea of a chain of coordinate transformations.
Start with coordinate system 1, apply transformation A, end up in
coordinate system 2, apply transformation B, end up in coordinate
system 3. All transformations are invertible. If there is more than
one chain of transformations between two coordinate systems, the
total transformations must be identical. The less exceptions on
when each coordinate system applies, the better. This might be
obvious, but it must also hold when traveling in a coordinate
system and crossing window and output boundaries, and that is where
I think we will hit problems. The transformations do not apply only
to points, they must also apply to vectors (motion).
That's up to the compositor, not Xwayland, innit? Xwayland is just a
Wayland client and has no control on that.
No, I believe Xwayland converts input coordinates from per-wl_surface
to global X11 coordinates, and then does everything in the global X11
coordinate system which is all that X11 apps ever know about.
ISTR there have been Xwayland patches going back and forth on that
design, so I'm not sure what the current state actually is. It
definitely is tricky code in Xwayland.
IIRC it'll just take the x/y in surface local coordinates and append the
window position to get the "X" coordinate.
Post by Pekka Paalanen
Post by Olivier Fourdan
Post by Pekka Paalanen
Post by Olivier Fourdan
Yes, but that's for "regular" Wayland clients, Xwayland surface
aren't scaled in mutter even though Xwayland doesn't use
wl_surface.set_buffer_scale (mutter doesn't support
set_buffer_transform, either)
Right, I think that's a mistake. Or at least it makes me not
understand at all how Mutter can work in a mixed-dpi setup.
You mean mutter or Xwayland with mutter? Either way, it's a comment for mutter devs.
Mutter with Xwayland, yes, and more precisely the partial HiDPI support
which is fundamental in getting X11 apps show up readable and not blown
up.
We actually can make even plain old X11 apps scale up properly on HiDPI
outputs, if the Wayland compositor's design allows it. And it sounds
like the new coordinate systems work in Mutter is going to allow that,
while the old way of never scale any X11 window was as bad as native
X11 on HiDPI.
So my criticism here is against caring at all about the old way of
never scaling any X11 window in the Wayland compositor. Maybe I have
misunderstood and you don't care about it?
Caring about the fractional scaling use case and implementing it this
way (communicating the output layout in the global compositor coordinate
space) has the nice side effect of also making it possible to implement
the "old" mutter way of dealing with X11 clients, i.e. regress as little
as possible by not ever scaling X11 client windows.


Jonas
Post by Pekka Paalanen
Thanks,
pq
Pekka Paalanen
2017-07-18 11:55:49 UTC
Permalink
On Fri, 14 Jul 2017 16:40:32 +0800
Post by Jonas Ådahl
This E-mail is quite long, but I tried to reply to some parts.
Hi Jonas, Olivier,

appreciated. :-)

TL;DR, I don't think there is anything in this email that would
actually be an opposition to the xdg-output protocol proposal. This
discussion has taken off in an academic direction about everything
surrounding the protocol proposal.
Post by Jonas Ådahl
Post by Pekka Paalanen
On Fri, 7 Jul 2017 04:21:57 -0400 (EDT)
Post by Olivier Fourdan
Hi Pekka,
Post by Pekka Paalanen
it's very hard for me to wrap my head around this, so the below may
sound a bit harsh, sorry. I don't mean to rant, but I feel there is
something fundamental amiss. I am diving back into the high-level
design which is fairly separated from the xdg_output interface.
No worries, but my goal with the protocol proposal (being an Xwayland
specific proposal initially, or merely an additional wl_output event
or now a more generic xdg_output protocol to be extended in the
future with whatever people want for desktop output uses) is to make
Xwayland work with the current existing design/implementations, not
to advocate for or against an existing design or particular
compositor implementation.
Hi Olivier,
if the intention is not to evaluate whether the current implementations
are actually workable in the long run, then should the new interface be
named so that we can throw it away if it actually doesn't work? And not
design anything else directly on top of it, so that it remains
relatively easy to throw away, i.e. stop using?
Post by Olivier Fourdan
WRT fractional scaling, my understanding of the design in mutter is
https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html
I cannot really comment on the design decisions, nor how those
decisions were made, Jonas would probably be in a better position for
this.
logical and physical. I believe that is the correct design.
But I have understood that you want to make Xwayland work with the
design before that one, which I cannot see how it could work. Do you
really need to make Xwayland work well with that old design?
The benefit of the current/old design (in mutter) is that X11 clients
don't particularly regress in functionality, compared to how it worked
before. HiDPI aware clients work just as well, and non-HiDPI clients
works just as bad.
Very well, it's your choice to support two paths there.
Post by Jonas Ådahl
Naturally, if we can make both HiDPI aware and HiDPI unaware X11 clients
work good, that's the most optimal, but I find it hard to believe we can
make that happen without adaptations to HiDPI aware X11 clients (like
mentioned EWMH extensions or something).
Not being a user, that is another design decision I would have hard
time understanding - why enhance modern toolkits to run better via
Xwayland instead of porting apps to Wayland. I suppose the obvious
answer is apps you don't actually control but still use GTK+ et al. But
how many of those are actually also HiDPI aware? And if you implement
that, do you not get into consistency problems with input and output
coordinate systems?

The two paragraph you wrote above talk about two cases, which in my
mind are mutually exclusive.
Post by Jonas Ådahl
Post by Pekka Paalanen
I fully agree with section 1, Overall approach.
Section 5 mentions a hwdb-alike database but keyed by EDID data. This is
something Keith Packard needs for his VR work to identify HMDs and I
discussed with him about it a bit. I think the scaling info would be a
good fit there.
Section 7 touches the game and fullscreen topic, which I believe is
important for deciding how RandR should advertise output resolutions.
Section 8 is exactly what we are talking about in this thread, right?
(A) Plain old Xwayland support with no HiDPI awareness or anything
(B) Fullscreen windows with buffer size matching the monitor framebuffer
it is fullscreen on
(C) HiDPI aware X11 clients.
For (A), this protocol solves the problem more or less completely
without any further changes. No input transformation changes needed
anywhere, not in Xwayland, not in any compositor. It is just a way to
communicate the logical layout of the screen to Xwayland so that it can
position its buffer-scale-1 windows in a grid that matches the global
compositor coordinate space.
Right, this is starting to slowly sink in. ;-)
Post by Jonas Ådahl
Post by Pekka Paalanen
What resolution do you want RandR to advertise to X11 apps?
If it is the physical output resolution, the window size in logical
units will be wrong unless XWM can reliably detect the X11 application
is actually intending to use the physical resolution. How would one do
that?
This is about part (B).
How? I'd say, probably only using "best effort" emulation strategies,
like detecting fullscreen windows matching the physical resolution set
and assuming anything else should be hidden, then using wp_viewporter or
something to make it to the logical size, which should result in no
scaling being done by the compositor.
You imply that the heuristics to detect fullscreen windows would be in
Xwayland. Is that feasible?

So far Xwayland has been very ignorant of any window management
concepts. I'm not sure if that is intentional or just inherited from
Xorg, i.e. is there an actual reason to avoid window management in the
X server.

As much as I'd like to have Xwayland wl_surfaces handled as any
wl_surface, I'm not so sure about that anymore.
Post by Jonas Ådahl
Post by Pekka Paalanen
If it is the logical output size, the window size in logical units will
be correct, but the X11 application cannot provide a buffer of the
physical output resolution, which means the Wayland compositor must
scale the image. If the buffer can hit direct scanout, that should be
no problem, but otherwise it could be a performance issue. (I agree to
prefer this option.)
It'll be a regression quality wise though, as something somewhere will
have to scale up from the logical to the physical resolution. Long term,
this is not acceptable as it'll mean games and other applications where
graphics quality is important that also won't be ported would regress.
It depends on the application. Applications using pixel units would be
unreadable if not scaled, but games could often be using relative units
so would scale automatically and effectively be "HiDPI aware" even if
not intending it. And then there will likely be some where 3D view
scales nicely but some UI elements are in pixel units and perhaps
lacking a scaling setting that would make them readable.

I think you are right, and we should aim for X11 buffer matching the
physical output resolution. The other case where scaling is actually
desired could be solved via, say, RandR video modes induced scaling.
Doing it the other way would not work.
Post by Jonas Ådahl
However, as a first step I think this is what we should do since it's
trivial. This is what (A) does.
Right.
Post by Jonas Ådahl
Post by Pekka Paalanen
In any case, there is a single (default) "scaling factor" covering all
X11 clients in an Xwayland instance, because neither Xwayland nor XWM
have per-window knowledge of the scaling the X11 app used. Also, X11
apps are laid out in a global coordinate space spanning all outputs
(within a X11 SCREEN), and also input works in that global coordinate
space with trivial conversions to per-window coordinates. I assume
Xwayland converts per-wl_surface input coordinates to global input
coordinates in the X11 space before dispatching to the X11 windows,
which means that the Wayland server must send input events taking that
into account. How will input work in the proposals?
I do not like the idea of special-casing the Xwayland Wayland client in
the Wayland compositor outside of XWM, even less if it requires special
mangling for input as well. How much special casing do you do? Or maybe
I'm just biased and it would actually be fairly easy to implement in
Weston with a little bit of API... Quentin might have some opinions
here.
Are you talking about (C) here? I don't really have a thought out idea
or plan how it should work, but EWMH is mentioned, but whether Xwayland
should play a part or not I'm not sure. I suspect it'll require changes
to X11 clients to make it work though.
It is about (C) yes, but in the generic case where you have both
low-dpi and hi-dpi X11 windows up. Think about a hi-dpi X11 main
window, with a low-dpi menu window on it, be that a child window or an
override-redirect window. Can you make that work in both window
positioning and input coordinate wise?

I haven't thought it through, but I have a strong suspicion it cannot
work.

Yes, the mangling paragraph is about (C).
Post by Jonas Ådahl
Post by Pekka Paalanen
Post by Olivier Fourdan
Regarding this particular discussion about the need of xdg_output and
logical size/position, I am completely open to suggestions, how would
see Xwayland work with both weston and mutter as they are now and
mutter in the future when it implements fractional scaling, without
adding logical size in xdg_output (or even not adding xdg_output at
all)?
I wouldn't say "without", I just do not understand how it all is
supposed to work in a mixed-dpi hardware setup. If we design an
interface that just cannot work in a mixed-dpi setup, we should be
able to throw it away later.
So I'm starting to think that the way forward is to design the new
interface such that it is easy to deprecate if it turns out to be a
dead end, or keep it if turns out future-proof.
Well, this is an unstable wayland-protocols protocol, so we are
completely free to abandon it right? If we need xdg_output to do
something else after having abandoned the purpose of it now, we're also
free to reinvent it.
Yeah, that should help a lot. I was thinking of stable xdg_shell
protocols needing xdg_output for something, which is not possible if
xdg_output is still unstable.
Post by Jonas Ådahl
Post by Pekka Paalanen
Maybe the definition of "mixed-dpi support" is what we disagree here.
In my mind, Xwayland cannot provide full mixed-dpi support, because X11
is simply incapable of it with current toolkits. It can provide partial
mixed-dpi support however, where the Wayland compositor is
automatically scaling, assuming all X11 apps are configured to use the
same scale factor.
It same as with Wayland apps: HiDPI unaware apps get partial mixed-dpi
support, while HiDPI aware apps get the full mixed-dpi support.
This would classify all HiDPI-aware X11 apps as being somewhere between
HiDPI unaware and aware Wayland apps: they cannot communicate their
scaling factor, but they can be configured as a group to always draw
with a given scaling factor.
Post by Olivier Fourdan
However, nothing would stop an x11 client or toolkit from querying
the monitor's mode and physical size (using xrandx), computing the
current DPI depending on the monitor it resides and adapting its
rendering based on that. X11 has all the mechanisms in place for
that, it's just that most clients won't do that (iirc, Firefox has
something like that at some point, not sure it's still used though)
That's actually a case I didn't even think of. I've only been thinking
about apps that want to make their window cover an output, like games.
This is a very good topic to bring up.
Post by Olivier Fourdan
- Plain old x11 clients, who don't know anything about DPI
- gtk+/GNOME clients, who base their rendering on a specific
xsettings Gdk/WindowScalingFactor and/or a envvar read by clutter,
- Some other app trying to compute DPI themselves (very few, I think
of Firefox, LibreOffice maybe? not sure at all about those)
I'm don't see how Xwayland could change its behavior for each app,
xrandr is not per client. I guess we could come up with a new window
property that Xwayland could monitor and set the buffer scale
accordingly, maybe? Anyhow, that's going off topic wrt the xdg_output
protocol, I'm afraid.
I agree, I don't see the worth in implementing per-X11-window scales.
Therefore we need to stick with one scale over all X11 clients. If
there are plain old clients in that set, then the only workable factor
for X11 is scale=1. Would you agree with that?
Post by Olivier Fourdan
The "benefit" I see in "lying" to the clients in xrandr by
advertising a lower mode than actual is that it solves the problem in
a consistent way for all these cases even those clients who try to
compute the DPI themselves).
How does it solve it for all the cases? Does it not help only with the
third case, while the first and second are unaffected? Not to belittle
the benefit, just wanting to be accurate.
For the first case, this proposal makes it at least work at all, i.e.
xterm becomes readable by default.
The only thing xterm needs to be readable is that the compositor scales
it up on HiDPI screens, which I believe already works in Weston today.
Hence I am again confused, since the only way it would not work is the
old mutter behaviour, where as to my understanding it can never work:
xterm is not HiDPI aware and does not look at RandR info AFAIK.

Did I misunderstand what proposal you referred to?
Post by Jonas Ådahl
For the second case, in GNOME, we (at least now) simply set the Xsetting
scaling factor to 1 via gnome-settings-daemon.
You must be talking about the new mutter design where the compositor is
scaling the X11 windows, right?
Post by Jonas Ådahl
For the third case, as Olivier mentiones, makes self calculating clients
think the resolution isn't that high so they might avoid scaling up.
Right, those are the only ones actually looking at RandR.

You can see how having to consider both the old and the new mutter
designs is confusing me. And I haven't even thought about fractional
scaling yet.

Taking a step back, what was the point of this "chapter"? Was it to
violently agree on how to make all X11 clients use the same scaling
factor: 1?
Post by Jonas Ådahl
Post by Pekka Paalanen
Post by Olivier Fourdan
If randr advertise the output mode 3840×2160 as 2560×1620 with a
fractional scale of 1.5, then the compositor would scale the buffer
up by that fractional scaling factor, i.e. 1.5, which gives the
expected 3840×2160.
I don't see how downscaling an already tiny x11 window would work.
Take a basic x11 app, say xterm, with its default fixed font size. It
looks "fine" on a low DPI monitor, but is completely unreadable on a
hidpi screen (at least for my old eyes), so the goal would be to
scale it up, not down.
The scale factor of 2 advertised in wl_output would be for Wayland
native clients, so they can set their buffer scale to that scale 2,
and then be downscaled by the compositor to achieve the expected
fractional scale of 1.5 with best rendering on screen.
Oh yes, I forgot that the X11 apps in this case are always drawing with
scale=1, so they are expected to be scaled up indeed. I must have been
thinking about all of X11 land being configured with scale=2.
Post by Olivier Fourdan
If the compositor was to scale Xwayland surfaces by 2 as well and
I think you mean the X11 apps are configured to draw in scale=2, right?
Post by Olivier Fourdan
then downscale to achieve the expected fractional scale of 1.5, it
would downscale by a factor of (2÷1.5) = 1.33, in which case it would
simply advertise a logical size of 5120×2880 (i.e [3840 × 2 ÷
1.5]×[2160 × 2 ÷ 1.5]) - That's the whole idea behind the logical
size, whatever the compositor does eventually, Xwayland gets it right
as long as the compositor advertise the expected size once the
scaling factor -whatever it is- is applied, if that makes any sense.
https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg00000.html
But I might be wrong in my understanding :)
Yes, now we are onto something. This feels good, considering outputs in
isolation. I didn't actually go through the numbers yet to make sure the
example is right, though.
Telling Xwayland the logical output is twice as large as the logical
output actually is, then assuming surface are scale=2 would, I think,
make HiDPI aware clients draw properly, but it'd also make things like
xterm and gitk become completely unusable always right?
Yes, I think so.

I have understood that in the old mutter design and in X11 in general,
non-HiDPI-aware clients on a HiDPI output are always unusable. So that
would not be a regression.

It would be a regression in Weston, because Weston is scaling up
low-dpi X11 windows. (It's also scaling up hi-dpi X11 windows, but that
is an existing bug.)
Post by Jonas Ådahl
Post by Pekka Paalanen
No, I believe Xwayland converts input coordinates from per-wl_surface
to global X11 coordinates, and then does everything in the global X11
coordinate system which is all that X11 apps ever know about.
ISTR there have been Xwayland patches going back and forth on that
design, so I'm not sure what the current state actually is. It
definitely is tricky code in Xwayland.
IIRC it'll just take the x/y in surface local coordinates and append the
window position to get the "X" coordinate.
Right. What is "window position" if some windows are scale=1 and
some are scale=2?

If an X11 client positions one window relative to another, how do they
map to the global X11 coordinate system if the window scales differ?

Do we need to start scaling coordinates inside Xwayland? But all
coordinate spaces are visible to X11 clients, who do not expect any
scaling to be going on between them.

This is my gripe with any proposal to start supporting X11 windows with
differing scales, and the rationale behind my "all X11 must have a
single scaling factor". Granted, it is all based on the premise that we
apply the same partial mixed-dpi support to X11 as we have for Wayland
clients: the Wayland compositor is scaling as needed. The premise is
based on the fact that otherwise there are cases where the application
is unreadable.


Thanks,
pq
Olivier Fourdan
2017-07-06 13:16:08 UTC
Permalink
Hi,
I don't understand what we gain by sending the position again in global
compositor space, it will always match the position of the wl_output.
That's right, but the position in wl_output has limited sense for some applications (basically, an x/y position makes sense only in a 2D compositor, which is limiting for a core protocol such as wl_output). In other words, it should not be wl_output, but now that it is, it cannot be removed from wl_output.

Yet, starting with a new protocol aimed at desktop concepts (xdg_output), it belongs there more than wl_output.

Cheers,
Olivier
Continue reading on narkive:
Loading...