Relative display placement and rotation in the Display panel (an alternative to drag-and-drop)

[xe-nvdk]

I extended the stock omarchy.monitor (Display) panel with an ARRANGE section, so multi-monitor placement and rotation can be done from the bar instead of by editing ~/.config/hypr/monitors.lua.

What it does

• Relative placement — per display, four buttons: left / right / above / below the anchor. The anchor is the built-in laptop panel when there is one, so it never moves and the layout can't drift off the origin. The plugin computes the coordinates, centres the smaller panel on the shared edge, and normalises everything back to 0x0.
• Rotation — 0° / 90° / 180° / 270° per display, including the axis swap, so a rotated 2560×1440 correctly reports and occupies 1440×2560 when the next display is placed beside it.
• Persistence — every change applies live and is written to a managed block in monitors.lua, so it survives hyprctl reload and logout. Only the text between the markers is rewritten; your own hl.monitor() lines above it are left alone.
• Brightness, text size, scale and the display toggles are unchanged from the stock panel.

External displays are keyed by desc: (description + serial from EDID) rather than connector name, so a rule keeps applying when the same monitor moves from DisplayPort to HDMI and comes back as a different output. The internal panel stays keyed by connector name, since it can't move.

Why buttons instead of a drag canvas

The arithmetic is the annoying part — "this one is 2560 wide, so the next starts at 2560, and centre the shorter one by half the difference". Four buttons say the intent directly and the plugin does the maths. It's deliberately the lighter-weight take next to the drag-and-drop plugins below.

One thing worth flagging for anyone building in this area

Omarchy configures Hyprland in Lua, and the Lua parser rejects hyprctl keyword outright:

keyword can't work with non-legacy parsers. Use eval.

hyprctl eval 'hl.monitor({ ... })' works instead. I lost a while to this because the failure is quiet if you're also writing monitors.lua — the file write triggers a reload, so the layout still changes and the dead keyword call looks like it worked. Same root cause as #6968, which the open PR #8728 fixes for the stock panel's monitor toggle.

Second gotcha, in case it saves someone else the time: editing a user plugin's QML doesn't really hot-reload. The shell logs Local plugin changed, reloading: and re-reads the file but keeps the old panel instance, so edits appear to do nothing until omarchy restart shell.

Install

git clone https://github.com/xe-nvdk/omarchy-display-arrange.git \
  ~/.config/omarchy/plugins/nvdk.monitor
install -Dm755 ~/.config/omarchy/plugins/nvdk.monitor/bin/nvdk-display-layout \
  ~/.local/bin/nvdk-display-layout
omarchy plugin enable nvdk.monitor
omarchy restart shell

Repository: https://github.com/xe-nvdk/omarchy-display-arrange

There's a CLI underneath it too (nvdk-display-layout place DP-3 left eDP-1, rotate DP-3 90, mode DP-3 2560x1440@100), so it's scriptable without the panel.

Known limitations

• Mouse only for now — the panel's keyboard cursor is a one-dimensional section walker, and wiring a per-display grid into it risked breaking the existing navigation.
• One anchor, so with three or more displays you can't place two on the same side.
• While docked, the clamshell watcher re-applies position = "auto" to the internal panel every ~2s and ignores desc: rules (Internal monitor position cannot be made to stick: clamshell watcher and Display panel scaling both re-apply position = "auto" #7326, Clamshell watcher ignores desc: rules for the internal panel and overwrites its scale every 2s #7084 — PR Monitor scaling: honour desc: and multi-line hl.monitor rules for the internal panel #8808 addresses the parser side).

Prior art

Credit where due — two drag-and-drop takes on this already exist, and I found them only after building mine:

• @Azteriisk's omarchy-display-manager (Interactive Drag-and-Drop Display Manager & Monitor Positioning Plugin for Omarchy Shell #8853), an interactive canvas with magnetic snapping
• Omarchy Display Order (Omarchy Display Order — drag-and-drop monitor ordering #8494), drag-and-drop monitor ordering

Neither covers rotation, which is the piece I'd most like to see land in the core widget regardless of which UI wins. Happy to fold the transform handling into whichever approach the maintainers prefer.

[Azteriisk]

Rotation is a good callout. I'll extend my option as well unless you want to file a pr before I can. Would be great to see one of these solutions in core

[Azteriisk]

Just updating- got it all working if you'd like to use.