DRM "panel orientation" property support

[emersion]

DRM exposes a "panel orientation" property to suggest an output to have a particular transform. Similarily, there are "suggested X" and "suggested Y" properties.

[emersion]

Weston patch: https://gitlab.freedesktop.org/wayland/weston/merge_requests/315

[agx]

Would the idea to just expose the property so the compositor can make use of it or would we actually want to honor that (and hence rotate e.g. touch input coordinates accordingly too)?

[emersion]

would we actually want to honor that

What do you mean? The DRM backend can't do any magical input coordinate transformation, because it doesn't handle input at all.

Rotating touch input will work out-of-the-box with wlr_cursor if the touch device is mapped to the correct output and the output has the right transform.

We could expose the DRM prop in several ways:

• Automagically add the panel orientation to the output transform. For instance if the compositor sets a 90-degree rotation on an output with a 180-degree panel orientation, set a 270-degree rotation to the output. This sounds fragile and surprising.
• Set an initial output transform. For insance if the output has a 180-degree panel orientation, set wlr_output.transform to 180-degree when the output is initialized. However this will get overwritten once the compositor calls wlr_output_set_transform and can't be extended to other hints like TILE.
• Add a new transform hint field to wlr_output.

Do you have other ideas?

[agx]

What do you mean? The DRM backend can't do any magical input coordinate transformation, because it doesn't handle input at all.

Rotating touch input will work out-of-the-box with wlr_cursor if the touch device is mapped to the correct output and the output has the right transform.

I think i didn't phrase it very well let me try to explain

I'm wondering whether wlroots should apply the necessary transform to honor panel orientation
implicitly (that is on top of wlr_output_set_tranform and tell the compositor via a hint that it does so or if wlroots just sets a hint and does not do any transform by default at all.

If we have wlroots apply the transform upfront the nice thing is that WL_OUTPUT_TRANSFORM_NORMAL would mean 'natural panel orientation'. If we have the compositor apply the transform explicitly on the output clients would see WL_OUTPUT_TRANSFORM_180 for a 180 deg rotated panel and wouldn't have a way to figure out that this is due to the panel being mounted upside down.

So i'd go with hint that indicates to the compositor that wlroots adds a transform to every transform set on the output to compensate for panel orientation. wlr_cursor would then have to take this into account too.

[emersion]

clients would see WL_OUTPUT_TRANSFORM_180 for a 180 deg rotated panel and wouldn't have a way to figure out that this is due to the panel being mounted upside down

I think we want to tell clients that the panel is mounted upside-down, because then clients could set a transform on their buffers and make it so the compositor doesn't need to rotate the buffers. That's the only use-case for wl_output.transform I know of.

[agx]

That's a good point so we should set that as you suggest.

i was thinking about wlr-output-management so clients can fix up the transform to show 'normal' orientation in user facing UI when the transform currently used corresponds to the transform in the drm property. But we can just add the panel's transform as additional event like make or model, right? This way clients using wl_output.transform get the right thing and clients using wlr-output-management can have a wlr-output-management.orientation .

[emersion]

Another benefit of exposing the "real" transform is that screencopy/export-dmabuf clients use wl_output.transform to rotate the captured buffer back to the normal orientation. If we expose a normal transform while rendering with 90-degree one, these clients will capture incorrectly oriented buffers.

i was thinking about wlr-output-management so clients can fix up the transform to show 'normal' orientation in user facing UI when the transform currently used corresponds to the transform in the drm property

Indeed, that makes sense to me.

But we can just add the panel's transform as additional event like make or model, right?

With wlr-output-management the compositor is in full control of the configuration sent to clients and can decide to implicitly apply the panel orientation. I guess a compositor will want to implicitly apply the panel orientation if it has a settings file too.

[emersion]

Somewhat related: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/7