xdg-output: add logical_transform

Compositors might apply two types of transforms to outputs: a software transform applied at compositing time, and a hardware transform applied by the GPU (e.g. via the "rotation" DRM property).

wl_output.geometry already contains a transform hint. Clients use this info to pre-rotate their buffers so that the compositor doesn't need to do it (this is especially useful for direct scan-out). For instance, the Weston clients have this behaviour.

However, in the case of a hardware transform, the compositor doesn't want clients to rotate their buffers because this is already done after compositing. So the compositor will send a NORMAL output transform via wl_output.geometry.

Doing so is fine for most clients, but some special clients like Xwayland use wl_output.geometry's transform to expose it in Xrandr. This results in invalid modes, causing pointer input coordinates issues.

This commit exposes a "logical transform", which is the sum of the software and hardware transforms.

Signed-off-by: Simon Ser contact@emersion.fr

added xdg-output label

Something that still needs discussion is panel orientation.

10:39 <jadahl> one thing that should be addressed is what logical transform is in relation to panel mounting etc
10:39 <emersion> hmm, what do you mean?
10:40 <emersion> ah, so what is the transformation applied to the user?
10:40 <emersion> by*
10:40 <jadahl> some devices have a panels which are mounted "incorrectly" (well, in a non-natural way)
10:40 <emersion> yeah, and there's a KMS prop about it
10:40 <emersion> i se
10:41 <jadahl> e.g. you hold the device in the "normal" way, the panel is actually side ways
10:41 <jadahl> yea
10:42 <jadahl> in mutter we pre-transform monitors so they appear "correct". a logical transform, if really "logical" (not related to hardware) sounds like it should use the post-transformed orientation
10:42 <jadahl> but that'd confuse modes again
10:42 <jadahl> so matching things to "modes" and matching things to what the person holding/looking at the device, might be incompatible
10:42 <emersion> hmm, that's a good point
10:45 <jadahl> maybe we should just split up xdg_output and move parts only consumed by xwayland in a protocol maintained in xserver/hw/xwayland/
10:46 <jadahl> then we can have a logical transform that clients that care about that can use (maybe your screenshooter, but also maybe UI's for selecting where to fullscreen something)
10:47 <emersion> but a UI to select where to fullscreen doesn't acre about orientation?
10:47 <emersion> care*
10:47 <emersion> only cares about the logical position and size?
10:48 <emersion> maybe our screenshooting things should use a separate protocol instead
10:50 <jadahl> emersion: yea, maybe not. I assume your screenshooting thing provides buffers that are not transformed some how. maybe what you need is meta data of how to transform it to get the "natural" orientation instead?
10:50 <emersion> yes, exactly
10:51 <jadahl> if you have properties on the output, and screenshot separately, its racy
10:50 <emersion> we get per-output raw buffers, we want to draw them in the layout coordinate space
10:52 <jadahl> then to me it sounds like meta data sent together with the buffer might make more sense
10:52 <emersion> indeed, that might be the case
10:52 <jadahl> would make sense if you take buffers from clients too
10:53 <jadahl> because they'll have independent orientation
10:53 <emersion> what do you mean?
10:53 <emersion> "take buffers from clients"?
10:54 <jadahl> with wl_output::transform a client might pre-transform. if you hand over a buffer from such a client directly to the screenshooter, it'll have a hard time to know how to transform it to make it "natural" without orientation meta data
10:54 <emersion> ah, interesting
10:54 <jadahl> (or copy it without transforming it)
10:54 <emersion> yeah, that's true

Yeah, I think I basically agree with everything Jonas said here - stick this in xwayland-shell for Xwl to discover geometry, then extend the wlr screenshooter protocol to include everything it needs for the client to stitch it together properly?

Yes, I agree too. But now that we have wl_surface.preferred_buffer_transform that wouldn't even be necessary!

changed target branch from master to main

mentioned in merge request wayland!220 (merged)

Closing because the issue this MR is trying to fix has been fixed by wl_surface.preferred_buffer_transform already.

closed