All wl_output properties don't always make sense for all
compositors.

Some compositors might not implement a "global compositor space",
(e.g. 3D compositors) in which case properties like x and y don't
make sense.

Some compositors might expose virtual outputs, in which case modes,
make and model are not relevant.

In a lot of these situations, information from xdg_output is better
suited.

Compositors also expose output refresh rate, which shouldn't be used
for synchronization purposes.

Signed-off-by: Simon Ser <[email protected]>
---

Thoughts?

Changes from v2 to v3: forgot to mention wl_surface.frame.

 protocol/wayland.xml | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 141038b..9a841f8 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -2402,6 +2402,13 @@
 
        The physical size can be set to zero if it doesn't make sense for this
        output (e.g. for projectors or virtual outputs).
+
+       Note: wl_output only advertises partial information about the output
+       position and identification. Some compositors, for instance those not
+       implementing a desktop-style output layout or those exposing virtual
+       outputs, might fake this information. Instead of using x and y, clients
+       should use xdg_output.logical_position. Instead of using make and model,
+       clients should use xdg_output.name and xdg_output.description.
       </description>
       <arg name="x" type="int"
           summary="x position within the global compositor space"/>
@@ -2446,7 +2453,17 @@
        the output device. This is not necessarily the same as
        the output size in the global compositor space. For instance,
        the output may be scaled, as described in wl_output.scale,
-       or transformed, as described in wl_output.transform.
+       or transformed, as described in wl_output.transform. Clients
+       willing to retrieve the output size in the global compositor
+       space should use xdg_output.logical_size instead.
+
+       Clients should not use the refresh rate to schedule frames. Instead,
+       they should use the wl_surface.frame event or the presentation-time
+       protocol.
+
+       Note: this information is not always meaningful for all outputs. Some
+       compositors, such as those exposing virtual outputs, might fake the
+       refresh rate or the size.
       </description>
       <arg name="flags" type="uint" enum="mode" summary="bitfield of mode 
flags"/>
       <arg name="width" type="int" summary="width of the mode in hardware 
units"/>
-- 
2.19.1


_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to