### System details

Acer Swift Go i5 1024/OLED 14

### What's wrong?

Summary
Multi-monitor layout management has been unreliable on my Acer Swift Go 14. A simple arrangement — external monitor on the left, laptop display on the right — has required repeated troubleshooting and manual configuration changes.

The external monitor initially appears on the wrong side. After correcting the layout, it can become incorrect again when resuming from hibernation. During attempts to configure the displays, I have also encountered overlap warnings and overlapping or otherwise broken layouts.

This makes switching between laptop-only use, a directly connected external monitor, and docked use frustrating and unpredictable. A basic two-screen arrangement should not require repeatedly repairing monitor coordinates.

Environment
Laptop: Acer Swift Go 14, SFG14-71 series.

Internal display: 2880 × 1800 OLED, 90 Hz.

External display: Samsung Odyssey G7 G70D, 3840 × 2160.

Connections used: HDMI and direct USB-C-to-DisplayPort; my workflow also involves docked and undocked use.

Direct USB-C-to-DisplayPort has successfully supported 4K at 144 Hz.

Mixed display scaling: 2× on the laptop display, approximately 1.5–1.6× on the external display during troubleshooting.

Desired arrangement: external display on the left, laptop display on the right, without overlap.

Configuration attempts included a community monitor-layout plugin and manual edits to ~/.config/hypr/monitors.lua.

Exact Omarchy, Hyprland, and plugin versions: currently unavailable.

The laptop is currently away for hardware service, so I cannot provide fresh logs or repeat the tests immediately. These display-layout problems occurred before the separate hardware failure.

Observed behavior
The initial display arrangement does not match the physical setup.

Moving the external display to the left and the laptop display to the right is unexpectedly difficult to get working reliably.

The layout can work temporarily, then become incorrect again after resuming from hibernation.

The layout tool has reported overlap even when the arrangement I intended to save placed the displays beside each other.

Some configuration attempts have left the desktop layout badly broken or overlapping, requiring further manual intervention.

I have not captured a compositor crash log, so I am not claiming a confirmed Hyprland crash. The confirmed issue is that the display layout becomes incorrect or unusable.

I also cannot yet isolate whether the problem originates in Omarchy’s display/resume handling, the community plugin, Hyprland, or interactions between them.

Reproduction workflow
The following describes the workflow in which I encounter the problem, rather than a guaranteed minimal reproducer:

Connect an external monitor to the laptop.

Configure the external display on the left and the internal display on the right.

Use different scaling factors on the two displays.

Apply and save the arrangement.

Hibernate the laptop and resume with the external display connected.

Check whether the saved arrangement has been restored correctly.

Repeat while switching between laptop-only, direct external-display, and docked configurations.

The issue is intermittent. I do not yet have a complete test matrix showing which connection and resume sequence triggers each symptom.

Expected behavior
A saved display arrangement should survive hibernation and resume.

Reconnecting the same monitor, directly or through a dock, should restore the appropriate saved layout.

Disconnecting external displays should return to a usable laptop-only configuration.

Positioning should account correctly for each display’s resolution and scale.

The layout shown by the configuration tool should match the layout actually applied.

Invalid arrangements should be rejected safely, with a clear explanation and a way to restore the last working configuration.

Actual behavior
Layouts can revert, displays can end up on the wrong side, and configuration attempts can produce overlap warnings or broken arrangements. A routine two-monitor setup requires repeated troubleshooting instead of remaining stable once configured.

Requested improvement
Please provide a reliable, first-party multi-monitor workflow integrated with Omarchy’s existing display controls.

By “native,” I mean an officially supported, integrated solution—not necessarily a new tool written from scratch. The important requirements are:

Simple visual positioning with edge snapping.

Correct handling of mixed scaling.

Persistent layouts associated with the connected displays, ideally using stable display identity rather than only connector names.

Reliable restoration after hibernation, resume, docking, and undocking.

Clear ownership of the active configuration, so saved layouts and resume/hotplug handling do not unexpectedly override each other.

Safe apply with confirmation and automatic rollback.

Useful diagnostics when a layout cannot be restored.

Community plugins are valuable, but users should not need to assemble and debug multiple tools just to keep an external monitor on the left and the laptop display on the right.

This is a basic daily workflow for anyone using Omarchy on a laptop with external displays.

Related reports
#13062 — Monitor positions do not auto-adjust when scaling changes, causing overlap.

#2858 — Add a better display configuration tool; closed as fixed, resolved, or superseded by the Quattro implementation.

These appear relevant, but I have not confirmed that they share the same root cause as my issue.