Output mirroring

[emersion]

Split off from #1666, with a smaller scope on just mirroring outputs.

Mirrored outputs show exactly the same area of the layout (in logical coordinates). If resolutions don't match, scaling (with same factor for both axes) and pillarboxing are used.

Only a single wl_output is advertised to clients, so that layer-shell works as expected. Each output can still have different settings (scale, transform, refresh rate, color management, etc).

Ref https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/116

[rhysperry111]

Just to clarify so people are on the same page - is there expect to be a strict relationship between "source" outputs, and the mirrors those are based off? i.e. the source output's resolution is used for rendering and then the mirrors will scale/letterbox that content as needed to their own resolutions?

[Ferdi265]

Only a single wl_output is advertised to clients, so that layer-shell works as expected. Each output can still have different settings (scale, transform, refresh rate, color management, etc).

is there expect to be a strict relationship between "source" outputs, and the mirrors those are based off? i.e. the source output's resolution is used for rendering and then the mirrors will scale/letterbox that content as needed to their own resolutions?

I'm not sure what the best solution there is, since there are multiple ways this could be implemented, IMO the different settings might even benefit from slightly different handling.

• Logical Resolution / Aspect Ratio: This should probably be taken 1:1 from the "source output", since it determines which of the two outputs gets letter boxing. Other behaviour would probably also be unexpected for users.
• Scale / Fractional Scale for clients on that output: One way could be to always advertise the values from the "source" output to clients to avoid modifying any aspect of the display of the "source" monitor. Another design choice could be to potentially increase the advertised scale to clients if a low resolution "source" monitor is mirrored to a high resolution monitor to allow the high resolution monitor to display crisp apps. This might change how the app looks on the "source" monitor though.
• Refresh rate, color management, etc...: Each of these probably has their own edge cases or considerations, but I have no expertise there

Some of this logic potentially overlaps with how floating windows that overlap multiple outputs are handled. If something clever can be done there, then maybe an analogous technique can be implemented for mirroring.

[rhysperry111]

• Another design choice could be to potentially increase the advertised scale to clients if a low resolution "source" monitor is mirrored to a high resolution monitor to allow the high resolution monitor to display crisp apps. This might change how the app looks on the "source" monitor though.

I think with that case it's best just to leave it down to users to pick the most sensible (likely highest res) display as the source.

• Refresh rate, color management, etc...: Each of these probably has their own edge cases or considerations, but I have no expertise there

Not much experience here either, but I think it makes sense to take the same approach as just using the source display's refresh rate for syncing with clients. Ideally the mirrors would be at the same refresh rate or some VRR tricks could be used.

Some of this logic potentially overlaps with how floating windows that overlap multiple outputs are handled. If something clever can be done there, then maybe an analogous technique can be implemented for mirroring.

It's crude but you can actually just overlap outputs to cover the same coordinate space and almost get usable mirroring :P

[emersion]

In the wlr-protocols discussion, I'm arguing that there is no need for a specific "source" or "destination" ouput. The user can indicate that two outputs show the same area of the screen, and it's up to the compositor to combine the scale/refresh rate/etc and configure clients accordingly.

[SoumyaRanjanPatnaik]

I was going through the viewport related changes in the wlr-protocols MR that you've linked. From what I understand, each output is positioned within the compositor space. With the introduction of viewports, it seems like one of two models could emerge:

1. All Physical Outputs Define Viewport: In this model, physical outputs are no longer directly positioned in compositor space. Instead, we introduce "logical outputs" (or use virtual outputs) that exist within compositor space, and physical outputs can only viewport onto the compositor space.
2. Either Occupy or Viewport: Here, a physical output may optionally define a viewport. If a viewport is defined, the output no longer maps to a region in compositor space. Otherwise, it behaves as before and occupies a region directly.

Given the potential deprecation of the set_scale request in v5, the first approach feels more likely — since scaling might shift from being a property of the output/head to being dependent on the size of the region it viewports onto.

That said, the second approach could still achieve scaling within the viewport framework by creating "logical outputs" or virtual outputs at the desired scale and viewporting onto their respective regions.

P.S. Apologies if I’ve misunderstood anything — I’m still getting familiar with the Wayland protocols.

Also LMK if the wlr-protocols MR is a better place to discuss this.