Output splitting

[emersion]

Very wide screens can benefit from being logically split into 2 or more outputs.

Split off from #1666

Ref https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3959

[dustymabe]

logically split into 2 outputs.

I assume you mean this but I don't want to assume here.. Do you mean "into 2 or more outputs"?

I currently have my large monitor (42" TV really) split into 3 (using i3) like:

+-------+----+
|       |    |
|       |    |
|       +----+
|       |    |
|       |    |
+-------+----+

[emersion]

Indeed, we probably don't want to hardcode any limitation in this regard.

[aDogCalledSpot]

I assume you mean this but I don't want to assume here.. Do you mean "into 2 or more outputs"?

I currently have my large monitor (42" TV really) split into 3 (using i3) like:

To my understanding this should be more like xrandr --setmonitor where applications will truly think that you have multiple monitors attached. i3 divides a single output but doesn't create any further virtual outputs.

The use case for me is that I have a 32:9 screen and a lot of apps aren't usable when they're that wide. At the moment I use xorg to create a virtual 16:9 screen in the middle and then create a virtual 8:9 on either side of it. The workflow is then exactly as if I had three screens.

[made4this]

I agree wholeheartedly. This is why I am a bit concerned about the implementation of this as a sway project. To my understanding this should rather be a wayland project and be usable for any window compositor in the end (like xrandr --setmonitor is usable for any window manager). In other words, I think we really don't want to split our screen into multiple workspaces (that is way too weak!). We want to split our screen into multiple (virtual) screens (which as such will have their own (sway) workspaces)! However, I don't have any technical understanding about wayland and maybe the developers think about it like this.

[Ferdi265]

I agree wholeheartedly. This is why I am a bit concerned about the implementation of this as a sway project. To my understanding this should rather be a wayland project and be usable for any window compositor in the end (like xrandr --setmonitor is usable for any window manager). In other words, I think we really don't want to split our screen into multiple workspaces (that is way too weak!). We want to split our screen into multiple (virtual) screens (which as such will have their own (sway) workspaces)! However, I don't have any technical understanding about wayland and maybe the developers think about it like this.

On Wayland, implementing things like this is up to compositors. The best we can do here is probably see how much of this can be implemented in a generic way to allow the complicated parts to live in wlroots, and offer a useful abstraction so sway, labwc, river, etc don't have to reimplement everything (except maybe configuration). KDE / Gnome / COSMIC(smithay) will have to implement things like this on their own since libwayland-server is not responsible for dealing with whatever a physical monitor is.

The initial implementation will potentially be sway-specific, and changes/refactoring during the review process could move generic / non-sway-specific parts into a wlroots PR.

[made4this]

On Wayland, implementing things like this is up to compositors.

That's what I was worried about ... I cannot help it but this feels like a design flaw of wayland. Clearly, the power of xrandr is/was a great thing in X and I hoped that wayland would be superior to X in every aspect - just by design. Thanks a lot for the quick explanation and especially for working on this!

Thanks to everyone who is or will be involved!

Your work will make us move to wayland.