Hyprland version
Hyprland 0.56.2 built from branch v0.56.2 at commit efb50993780079460b0cbed1363e2166a2de1d9f clean ([gha] Nix: update inputs).
Date: Wed Aug 5 14:13:21 2026
Tag: v0.56.2, commits: 7661
Libraries:
Hyprgraphics: built against 0.5.1, system has 0.5.1
Hyprutils: built against 0.14.0, system has 0.14.1
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.14.0, system has 0.14.0
Version ABI string: efb50993780079460b0cbed1363e2166a2de1d9f_aq_0.14_hu_0.14_hg_0.5_hc_0.1_hlg_0.6
no flags were set
Hello, on my current display server I use the xrandr --setmonitor command to combine multiple physical monitors into a single virtual monitor. Is there any way to use Lua to configure Hyprland to be able to do the same thing?
opened 05:36AM - 05 Apr 23 UTC
Some X11 window managers (AFAIK only openbox and marco) support the [`xrandr --s… etmonitor` command](https://gitlab.freedesktop.org/xorg/app/xrandr/-/blob/master/xrandr.c#L3212-L3249), which makes the following possible (while perfectly preserving all OpenGL, Vulkan and Glamor DRM GPU acceleration functionality for Intel and AMD GPUs) on all systems using Xorg + openbox:
* **force all windows to maximize _and_ fullscreen (provided the window's app normally allows maximizing or fullscreening it respectively) across only an arbitrary subsection of one monitor instead of filling the entire monitor**
* **force all windows to maximize _and_ fullscreen across an arbitrary amalgamation of multiple monitors instead of only filling a single monitor at a time**
A basic example of using this functionality is on [the Arch Wiki](https://wiki.archlinux.org/title/multihead#Combine_screens_into_virtual_display).
As far as I have been able to tell, no currently existing Wayland compositor has had either of these features added to it. Could this be added to the "Missing" list, or is there a counterexample?
opened 12:51PM - 07 Jul 25 UTC
> [!NOTE]
> **This feature has only been seen in wild open source code
> within … the window managers `marco` and `openbox`**,
> and has only historically been seen working when those window managers
> are run within the display server [Freedesktop Xorg](https://gitlab.freedesktop.org/xorg/xserver).
> No other currently existing open source window managers or wayland compositors
> have ever been confirmed to support this feature at this time, as far as I know.
- Depends on https://github.com/kaniini/wayback/issues/8
- Example of https://github.com/mpsq/arewewaylandyet/issues/181
- Near-Equivalent Issue in other Preexisting Wayland Compositor's Repository: https://github.com/labwc/labwc/issues/903
- Near-Equivalent Issue in other Preexisting Wayland Compositor's Repository: https://gitlab.gnome.org/GNOME/mutter/-/issues/1406
- Near-Equivalent Issue in other Preexisting Wayland Compositor's Repository: https://bugs.kde.org/show_bug.cgi?id=465030
- **Was stated as won't-fix in `wlr-randr`** https://github.com/emersion/wlr-randr/issues/13
- If the `xrandr --setmonitor` command and all its features were reimplemented in a Wayland compositor, it would allow the creation of virtual monitors composed of arbitrary sections of physical monitors.
- The vast majority of X11 windows would automatically **maximize**, **fullscreen** and **snap** within the bounds of the **virtual monitors**, not the borders of the **physical monitors**
- **This project is very exciting and wonderful because, unlike other Wayland compositors, it appears to be intended for running the `marco` and `openbox` programs, which are very important, beloved GUIs that cannot be lost!**
- **I'm enthusiastically excited about the slight potential for a modern backend update for this important shared feature of the `marco` and `openbox` window managers!**
[`xrandr` 1.5+ Documentation:](https://gitlab.freedesktop.org/xorg/app/xrandr/-/blob/12ed42b3fa0e59bc41ca4eeb40d9a5675f3f82e2/man/xrandr.man#L140)
> - --setmonitor _name geometry outputs_
> - Define a new monitor with the given geometry and associated to the given outputs. The output list is either the keyword **none** or a comma-separated list of outputs. The geometry is either the keyword **auto**, in which case the monitor will automatically track the geometry of the associated outputs, or a manual specification in the form _w/mmwxh/mmh+x+y_ where w, h, x, y are in pixels and mmw, mmh are the physical dimensions of the monitor.
Example:
```bash
xrandr --output DisplayPort-3 --mode 2560x1440 --pos 0x1080 --rotate normal --primary \
--output HDMI-A-1-0 --mode 1920x1080 --pos 320x0 --rotate normal \
--output DisplayPort-2 --mode 1920x1080 --pos 2560x880 --rotate left \
--output DisplayPort-1 --mode 1920x1080 --pos 3640x880 --rotate left \
--output HDMI-A-1 --mode 1920x1080 --pos 4720x880 --rotate left
xrandr --setmonitor three auto DisplayPort-2,DisplayPort-1,HDMI-A-1
```
```
~ $ xrandr --listmonitors
Monitors: 2
0: +*DisplayPort-2 2560/708x1440/398+0+200 DisplayPort-2
1: three 3240/521x1920/293+2560+0 DisplayPort-1 DisplayPort-0 HDMI-A-0
```
I had a long list of other URLs to post here but the system said new users are only allowed to post 2 links
Afaik, no Wayland compositor has achieved this.
Closest effort:
Conversely, a popular feature request for Hyprland:
thanks for the updated information about this as it relates to hyprland. I am a “single issue user”; this limitation of wayland is what keeps me on Xorg. Once a wayland compositor successfully implements this feature with correct, pixel-perfect accuracy to the behavior of Xorg with the Marco or Openbox window managers, it will probably be the first wayland compositor I try switching to from Xorg.