Update monitor configuration defaults and docs to use relative positioning (auto) to prevent cursor trapping

[syskey8]

Suggestion: Use relative positioning (auto) instead of absolute pixel coordinates for multi-monitor setups

I wanted to suggest a change to how multi-monitor configurations are handled in the default Omarchy templates and official documentation, specifically regarding the position variable in ~/.config/hypr/monitors.lua.

Currently, the default examples and guides teach users to use absolute pixel coordinates (e.g., position = "1920x0" or position = "0x1080"). While this works perfectly at a 1.0 scale, it completely breaks the desktop if a user decides to use fractional scaling.

The Issue

If a user has two 1080p monitors stacked and sets the bottom one to 0x1080, everything is fine. But if they change the scale of the top monitor to 1.25, Hyprland maps coordinates based on the scaled logical resolution:

• The top monitor's logical height shrinks to 864 (1080 / 1.25).
• The bottom monitor is still hardcoded to start at Y=1080.
• This creates an invisible "dead zone" gap between 864 and 1080.

The result: the mouse cursor gets physically trapped and cannot cross the boundary between the monitors. Users are forced to manually switch workspaces just to warp the cursor to the other screen, which feels like a severe system bug.

Reproducible Proof

Here is what my monitors.lua looked like when the mouse got trapped:

local omarchy_monitor_scale = 1.25
hl.monitor({ output = "HDMI-A-1", mode = "1920x1080@60", position = "0x0", scale = omarchy_monitor_scale })
hl.monitor({ output = "eDP-1", mode = "1920x1080@120", position = "0x1080", scale = omarchy_monitor_scale })

And here is the math exposing the gap:

• Top Monitor (HDMI-A-1): Height is 1080, scale is 1.25 → logical bottom edge sits at Y=864.
• Bottom Monitor (eDP-1): Hardcoded position tells Hyprland it starts at Y=1080.
• The Dead Zone: The physical space between Y=864 and Y=1080 is left completely unmapped, acting as an invisible wall for the cursor.

The Solution

Hyprland natively supports relative positioning: auto, auto-right, auto-left, and auto-down.

If we update the Omarchy default templates, setup scripts, and documentation examples to teach auto-right / auto-down (or just auto) instead of absolute pixels, the configuration becomes bulletproof:

• Coordinate boundaries dynamically glue together no matter what display scale the user chooses.
• Completely eliminates the cursor trap issue.
• No math required from the user — it "just works" regardless of resolution or scale mismatches.

References

• Omarchy 3.4.0: Monitor scale cycling breaks layout #4785 — this is likely the exact geometry clash described above, occurring when the script updates scaling but leaves hardcoded positions intact.
• omarchy-hyprland-monitor-scaling doesn't persist scale on outputs with explicit per-monitor rules in monitors.lua #8103 — users are hitting this coordinate trap because the scaling script does not recalculate the boundaries.

---

I'd love to hear your thoughts on this! If the team agrees this is the better approach, I'd be happy to submit a PR to update the relevant docs and templates.

[syskey8]

I've gone ahead and submitted a Pull Request (#8362) that completely fixes this issue by updating the default templates and documentation to use auto-right!

The underlying problem was that the official documentation taught absolute coordinates (e.g. 1920x0), but when users used the system scaling tool, it updated their scale factor without updating their absolute coordinates, instantly breaking their monitor layouts and trapping their cursors.

By switching the defaults to use relative positioning, Hyprland will always mathematically glue the monitors together flawlessly regardless of the user's fractional scale. Looking forward to any feedback on the PR!