Output splitting

[emersion]

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

Split off from https://github.com/swaywm/sway/issues/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.

[shimeike]

Curious whether doing this somehow dynamically, like the Herbsluftwm concept of splits could be relevant here? Apologies for linking to a YouTube video, but the concept is demonstrated briefly here for those unfamiliar.

[minus7]

Curious whether doing this somehow dynamically, like the Herbsluftwm concept of splits could be relevant here?

After using a 32:9 49" monitor (basically 2 27" ones side by side) for a few months now, I've come to the same conclusion: Just splitting up the monitor statically is too inflexible, since for some things, like fullscreen video or games, you do want to be able to use the whole width. Being able to split on the fly might be useful. Or maybe workspaces of workspaces. Having windows exist on multiple workspaces simultaneously might also be useful (e.g. an IRC or email client that you want to keep around on various workspaces). Both of those seem dangerously close to out-of-scope for sway though.

[tsipinakis]

I've delved into this rabbit hole before, from my experience implementing this into the sway side has the downside that clients are not aware of this split, meaning that e.g. swaybar will extend to the full length of the physical screen, not the virtual split.

To achieve a real separation I also think that this should be something built into wayland.

[Ferdi265]

I've delved into this rabbit hole before, from my experience implementing this into the wayland side has the downside that clients are not aware of this split, meaning that e.g. swaybar will extend to the full length of the physical screen, not the virtual split.

To achieve a real separation I also think that this should be something built into wayland.

if this is implemented, the real outputs would probably need to be hidden from clients, and the split outputs would need to be advertised to clients as regular wl_outputs. Changing resolution via wlr-output-management would then need to be implemented accordingly as well, not sure how to do this properly.

I think this might need changes in wlroots.

[aDogCalledSpot]

I think a main challenge here is to completely override any access to physical screen sizes and also consider what possible trade-offs are in this case.

For example, is there an issue if a full-screen application, like a game, never gets the "true" screen dimensions. What about an application for displaying a wallpaper?m

Off the top of my head, I don't think so because I have seen both of these go wrong on Xorg.

[Ferdi265]

I think a main challenge here is to completely override any access to physical screen sizes and also consider what possible trade-offs are in this case.

For example, is there an issue if a full-screen application, like a game, never gets the "true" screen dimensions. What about an application for displaying a wallpaper?m

Off the top of my head, I don't think so because I have seen both of these go wrong on Xorg.

I agree, if the feature is intended to split monitors into two logical outputs, all apps should see these as two separate outputs.

Though, there is a case for potentially allowing different behaviour for things like layer-shell (backgrounds, bars, notification overlays), but the problem is that there isn't really an easy way to show only those apps the real output dimensions without changing the protocols. At least I can't think of an easy way.

[Ferdi265]

Changing resolution via wlr-output-management would then need to be implemented accordingly as well, not sure how to do this properly.

Looking at wlr-output-management, this should probably work fine if the real monitors are exposed as zwlr_output_heads. Potentially, configuration of splitting could even be added as an extension to the output management protocol.