DRM connector tiling

[emersion]

Some monitors might have multiple connectors with tiled screens.

DRM connectors will have a TILE property that can be used to retrieve tile information. See for example how GNOME Shell handles this: https://gitlab.gnome.org/GNOME/mutter/blob/fb8dc918932d0cf246227468f742d89fe4d80d57/src/backends/native/meta-output-kms.c#L170

---

wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1580

[ghost]

Any word on this?
Any way I can contribute?

[emersion]

I think we'll want to expose this information to compositors, and let them decide how to handle these monitors.

In the future when wlr_output doesn't have rendering primitives built-in we could maybe add wlr_output_group, a wlr_output that attaches a subset of its attached buffer to each sub-output.

[emersion]

We'll also want to advertise a single logical wl_output to clients so that e.g. layer-shell clients work properly.

[hanetzer]

I now have two of these displays now, so if someone needs a guinea pig
and perhaps help with the coding and design. I use gentoo so I'm used
to having system state in various forms of broke so feel free to try crazy
things.

[coroner21]

It seems this is currently an obstacle for getting my LG 5k display to work with full resolution in sway. Happy to support in any way getting this to work. Any pointers?

Is my understanding correct that we first need to make wlroots conscious of such a specific display type? In a second part this would be exposed to sway and then handled accordingly?

[emersion]

Yes. The first step is to parse the TILE property in the DRM backend.

The second step is to introduce something like wlr_output_group to make it easy for compositors to support this.

Alternatively we could add transparent support for tiled outputs in wlroots, but in the past we've tried doing magic under the hood and it turned out to be a bad idea. There are tricky details such as repaint timings to take into account. Also compositors may want to have their own custom logic for tiled displays instead of wlroots'.

[ammen99]

The second step is to introduce something like wlr_output_group to make it easy for compositors to support this.

Alternatively we could add transparent support for tiled outputs in wlroots, but in the past we've tried doing magic under the hood and it turned out to be a bad idea. There are tricky details such as repaint timings to take into account. Also compositors may want to have their own custom logic for tiled displays instead of wlroots'.

Can we somehow scan out parts of the buffers on each output? Or the compositor will have to really render the two parts separately?

[emersion]

No, we can use a single buffer, and scan out part of the buffer on each physical output. wlr_output_group would expose a single buffer to the compositor, and scan out part of it on each child output.

[coroner21]

Would it not be preferable to indeed just do this under the hood in wlroots?

• The compositor should only have to deal with actual screens (the complete physical display in this case), why would it make any difference to the compositor knowing that we are dealing with a tiling screen?
• Currently wlroots reports two outputs (e.g. DP1 and DP2) for the same display (the ID string is fully identical) which in itself is quite confusing
• if we handle tiling displays by wlroots we could report only one output with one connector (e.g. DP1 or the one which carries most of the non-tiling resolutions) and one display ID including all the resolutions (also the tiled ones)
• The compositor could just use this output including the tiled ones which are using also DP2, but this does not really need to be known by the compositor, or does it...?

From my point of view it would also be easier to implement this since only wlroots needs to change and handling of tiling screens could be fully private to wlroots...

[emersion]

why would it make any difference to the compositor knowing that we are dealing with a tiling screen?

Because many output properties are still, well, per-tile. Modesets, timings, hardware planes and so on are per-tile.

Currently wlroots reports two outputs (e.g. DP1 and DP2) for the same display (the ID string is fully identical) which in itself is quite confusing

If you're referring to data exposed to Wayland clients, it's easy for the compositor to avoid this: just don't add these to the wlr_output_layout. Instead add the output group.

if we handle tiling displays by wlroots we could report only one output with one connector (e.g. DP1 or the one which carries most of the non-tiling resolutions) and one display ID including all the resolutions (also the tiled ones)

A wlr_output_group can do this, too.

From my point of view it would also be easier to implement this since only wlroots needs to change and handling of tiling screens could be fully private to wlroots...

As I said before, we've done some magical under-the-hood stuff like this in wlroots before and it always turned out to be a bad solution. I much prefer the solution of exposing an helper to make it easy for compositors to deal with tiled outputs.

[coroner21]

OK, it just seems easier for me to work on such a more simple solution since it would require basically tracing the flow from display registering to output rendering and understanding what needs to change in order to support tiling displays. Adding another virtual wlr_output_group to collect all tiles and handle the rendering based on one full buffer requires probably a lot more knowledge of the wlroots code base than I currently have.

[emersion]

FWIW, I don't think the "under-the-hood" solution would necessarily be simpler, since the DRM backend doesn't really expect to drive two connectors and CRTCs with a single wlr_output. Changing the assumption "1 wlr_output = 1 CRTC = 1 connector" sounds like a tall order.

Feel free to ping me in #sway-devel on Libera Chat if you want directions.

[coroner21]

That probably makes sense. Will definitely take you up on the offer to provide some guidance on this. Have already started to dig into the DRM backend code... I expect parsing the TILE property and writing it into some struct is the easy part, adding another wlr_output_group interface and implementing that will be the harder part. Fortunately it should still be more or less shuffling around and plugging together of existing bits and pieces and not so much new creations...

[emersion]

Yeah, I think we can split this work into smaller pieces:

• Parse the TILE prop and expose it in a wlr_output field (maybe look at other blob props like EDID to see how to read it)
• Add a way to crop a buffer with wlr_output. Probably something like wlr_output_set_src_box? This should translate to the KMS SRC_* props.
• Add wlr_output_group which forwards buffers to multiple child outputs on commit.