wlr-output-management lacks mirrored outputs

[AdrianVovk]

There is currently no way to tell if an output is a clone/is mirroring another output. This is important to know, because without this it's impossible to make a distinction between real, physical displays and logical outputs in compositor coordinate space. I ran into this trying to make a client that translates the wlroots protocol into the DBus API gnome-control-center expects. Without knowing that an output is a mirror of another, my code just told g-c-c that there are two physical displays (and their various properties), and that there are two logical outputs stacked on top of each other at 0,0. This broke the UI.

Due to the lack of support in protocol, Wayfire is supposed to just disable the mirror output and stop sending valid x/y coordinates, but this doesn't currently work correctly and so it sends even weirder state to the client. When/if this does get fixed in Wayfire, it'll be even worse because then there will be no distinction between a mirror output and a disabled output. @ammen99 suggested I open an issue here to fix this in-protocol, so that Wayfire doesn't have to do any hacks to support mirror outputs.

The way I envision this working is that heads have a new mirroring signal, with a reference to another head object passed in. If the reference is null, then the head is no longer a mirror. If the reference is another head, the client now knows that this head is mirroring another head. Compositors that don't support output mirroring can simply never send this signal with a reference to another head.

[emersion]

This was discussed in #38. Compositors don't need this information because they can opportunistically use a CRTC for two connectors if possible. There's no need for this information to be in the protocol in this regard.

Your translation layer can detect outputs that span over the same regions and expose them as a single logical monitor in the D-Bus API.

[AdrianVovk]

@emersion So right now, my efforts to get this to work look like so:

1. To figure out if a head is a clone, I try to match it to a wl_output (by matching based on make/model in the geometry event. I reuse this wl_output to make wlr_power_management and wlr_gamma_control objects too). If it is enabled, but doesn't have a wl_output, it is a clone.
2. To figure out what this head is a clone of, I loop over all the known heads. If a candidate head's x/y matches, and the candidate is not itself a clone, then it is the "source" head

Is this what a correct implementation might look like?

[ammen99]

This was discussed in #38. Compositors don't need this information because they can opportunistically use a CRTC for two connectors if possible. There's no need for this information to be in the protocol in this regard.

Your translation layer can detect outputs that span over the same regions and expose them as a single logical monitor in the D-Bus API.

This makes the assumption that cloned outputs need to have the same resolution, which is not true, at least Wayfire supports mirroring different resolutions by stretching.

[ammen99]

Or should the compositor report "fake" resolutions to make the output sizes match?

[emersion]

To figure out if a head is a clone, I try to match it to a wl_output

This shouldn't be necessary. Just compare the geometries of the heads.

There is no parent-child relationship for heads. In other words, clients can tell which heads are clones of each other, but can't tell which one is the "master" (this is left as a compositor-specific implementation detail, some compositors may not have this concept of "master").

This makes the assumption that cloned outputs need to have the same resolution, which is not true, at least Wayfire supports mirroring different resolutions by stretching.

This is deliberately unsupported by the protocol. Stretching will look bad, what are the use-cases for it?

Or should the compositor report "fake" resolutions to make the output sizes match?

Definitely not.

[ammen99]

Sorry for the late response, somehow I missed your comment the last time I read this issue ..

This is deliberately unsupported by the protocol. Stretching will look bad, what are the use-cases for it?

You don't have to stretch it, you can also add padding. For example, if you have a 4:3 projector and a 16:9 monitor, you want to mirror them .. How'd you do it? Overlapping outputs don't really work, since resolution won't match.

There is no parent-child relationship for heads. In other words, clients can tell which heads are clones of each other, but can't tell which one is the "master" (this is left as a compositor-specific implementation detail, some compositors may not have this concept of "master").

This could be made to work with some heuristics in the compositor (at least for Wayfire where we do have a 'master' output), but only in the case the resolutions totally match, which doesn't have to be the case.

[emersion]

Yeah, letter-boxing is certainly a better option than stretching when it comes to output mirroring.

I don't think it'd be unreasonable to add a request to set the viewport of a head. It would be a rect in the global compositor coordinate space.

[emersion]

wlr-protocols has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/101