Atomic modeset fails for dual output (eDP-1 + DP-3) on CoffeeLake i915 — second monitor only works after hot-replug, then eDP-1 breaks

[gitdayn]

Environment

• Compositor: Hyprland 0.56.2 / Aquamarine 0.14.0
• GPU: Intel CoffeeLake-H GT2 UHD 630 (PCI 0000:00:02.0, device 3e9b) + NVIDIA (hybrid)
• Kernel: 7.1.8-arch1-3 (Arch Linux, Omarchy)
• External monitor: Acer XR342CK (3440x1440 ultrawide) on DP-3
• Internal panel: Sharp Corporation 0x148D (3840x2160) on eDP-1

Description

At boot, Aquamarine detects both eDP-1 and DP-3 as connected with valid EDID and assigns them CRTC 59 and CRTC 84 respectively. However, the atomic DRM commit fails with Invalid argument, and eDP-1 is disabled while DP-3 gets reassigned to CRTC 59. The laptop screen goes black.

After physically unplugging and replugging the DP cable, DP-3 activates successfully on CRTC 59, but eDP-1 remains disabled: true and cannot be re-enabled.

Steps to Reproduce

1. Have both eDP-1 and DP-3 connected at boot
2. Hyprland starts, detects both monitors, attempts modeset
3. Atomic commit fails, eDP-1 is disabled
4. Unplug DP-3, replug — DP-3 works, eDP-1 stays dead

Key Log Output

Aquamarine sees both monitors and assigns CRTCs:
DEBUG: drm: found 3 CRTCs
DEBUG: drm: Connector eDP-1 connected
DEBUG: drm: Connecting connector eDP-1, CRTC ID 59
DEBUG: drm: Connector DP-3 connected
DEBUG: drm: Connecting connector DP-3, CRTC ID 84

Atomic commit fails:
ERR: atomic drm request: failed to commit: Invalid argument, flags: ATOMIC_ALLOW_MODESET ATOMIC_TEST_ONLY

eDP-1 gets disabled, DP-3 steals its CRTC:
DEBUG: drm: eDP-1 is disabled, releasing crtc 59
DEBUG: drm: connected slot 0 crtc 59 assigned to DP-3
DEBUG: drm: backup slot 1 crtc 84 assigned to disabled eDP-1

Subsequent commit also fails:
ERR: drm: Cannot commit when a page-flip is awaiting

Kernel cmdline

cryptdevice=UUID=...:omarchy_root root=/dev/mapper/omarchy_root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs rtc_cmos.use_acpi_alarm=1 resume=/dev/mapper/omarchy_root resume_offset=1904529 initramfs_async=0 quiet splash loglevel=0

Tried

• i915.enable_psr=0 — no change
• Clearing monitor config (Hyprland auto-detect) — no change
• Changing DP-3 mode from preferred (75Hz) to 3440x1440@60 — no change
• Kernel 7.1.8-arch1-3 (latest stable)

Sysfs State

• /sys/class/drm/card2-DP-3/status: connected
• /sys/class/drm/card2-DP-3/enabled: enabled
• /sys/class/drm/card2-DP-3/edid: valid (Acer XR342CK, 3440x1440@75Hz preferred)
• /sys/class/drm/card2-DP-3/modes: 3440x1440@75Hz and many others

Notes

• This is a Dell laptop with Intel+NVIDIA GPU
• Both CRTCs are available (3 found), but atomic commit rejects the dual-output configuration
• Similar to modesetting failing on external monitor #59 but on CoffeeLake rather than newer Intel GPU
• NVIDIA GPU (card1) has no outputs connected — all displays on Intel iGPU (card2)

[ricky-0x7B7]

I can reproduce a closely related issue on a ThinkPad T14 Gen 1 with Intel Comet Lake-U i915 and an LG 5120x1440 ultrawide.

---

Environment:
OS: Omarchy / Arch Linux
Kernel: 7.1.9-arch1-2
GPU: Intel CometLake-U GT2 [UHD Graphics]
Driver: i915
CPU: Intel Core i7-10610U
Hyprland: 0.56.2
Aquamarine: 0.14.0

External display:
Connector: DP-2
Monitor: LG Electronics LG HDR DQHD
Native resolution: 5120x1440
Working mode: 3840x1080@60

---

Hyprland correctly reports:

availableModes:
5120x1440@60.00Hz
5120x1440@30.00Hz
3840x1080@60.00Hz

...

DRM sysfs also exposes the native mode:

$ cat /sys/class/drm/card*-DP-2/modes
5120x1440
5120x1440
3840x1080
3840x2160

...

Trying:
hyprctl eval 'hl.monitor({ output = "DP-2", mode = "5120x1440@60", position = "0x0", scale = 1 })'

returns:
ok

but the output remains at 3840x1080@60.

The same happens with 5120x1440@30, so this does not appear to be specific to the 60 Hz bandwidth requirement.

Relevant Aquamarine log:

drm: connected slot 1 crtc 84 assigned to DP-2
drm: Connecting connector DP-2, CRTC ID 84
atomic drm request: failed to commit: Invalid argument, flags: ATOMIC_ALLOW_MODESET ATOMIC_TEST_ONLY

This error is repeated several times. I also occasionally see:

drm: Cannot commit when a page-flip is awaiting
atomic drm request: failed to commit: Device or resource busy, flags: ATOMIC_NONBLOCK PAGE_FLIP_EVENT

Additional observations:
3840x1080@60 works reliably.
5120x1440@60 and @30 are both advertised by DRM but cannot be applied.
Disabling the internal eDP-1 display does not resolve the problem.
No obvious i915 link-training or bandwidth errors appear in the kernel journal.
Scaling changes are applied correctly; only the requested video mode fails.

This looks very similar to the atomic modeset / CRTC assignment issue described here, so I’m adding this hardware case in case it helps narrow the Intel i915 path.

---

I can provide the full Aquamarine/Hyprland log if needed.

[ricky-0x7B7]

Follow-up: I was able to isolate the problem further and confirm a working workaround.

What led to the diagnosis

The key observation was that both:

• 5120x1440@60
• 5120x1440@30

failed in exactly the same way, while:

• 3840x1080@60

worked reliably.

That made a pure DisplayPort link bandwidth issue unlikely, because if the problem were simply bandwidth saturation, the 30 Hz mode should have had a much better chance of succeeding.

At the same time:

• Hyprland correctly exposed both 5120x1440 modes in availableModes
• the kernel DRM connector also exposed them:

$ cat /sys/class/drm/card*-DP-2/modes
5120x1440
5120x1440
3840x1080
3840x2160
...

So the mode itself was clearly present in EDID/DRM.

The relevant Aquamarine log during the failed modeset was:

drm: connected slot 1 crtc 84 assigned to DP-2
drm: Connecting connector DP-2, CRTC ID 84

atomic drm request: failed to commit: Invalid argument,
flags: ATOMIC_ALLOW_MODESET ATOMIC_TEST_ONLY

This strongly suggested that the failure was happening during atomic validation of the framebuffer/plane state rather than during link training.

Hypothesis

On Gen9 Intel i915 hardware, primary-plane maximum width depends on the framebuffer tiling/modifier.

For 32bpp buffers, linear/X-tiled layouts can support wider scanout than some Y-tiled / Yf-tiled / CCS layouts.

Aquamarine builds the GBM buffer using explicit DRM modifiers supported by the plane, and Mesa is then free to select one of them.

The problem is that IN_FORMATS only tells userspace that a modifier is supported in general; it cannot express width-dependent constraints for that modifier.

So a modifier may be advertised as valid for the plane, but still produce a framebuffer that is rejected by i915 when the width reaches 5120 pixels.

That would explain the exact behavior here:

• 3840-wide framebuffer: accepted
• 5120-wide framebuffer: rejected during ATOMIC_TEST_ONLY
• both 60 Hz and 30 Hz fail because the issue is framebuffer width/layout, not link bandwidth

Confirmation

I then started Hyprland with DRM modifiers disabled:

AQ_NO_MODIFIERS=1 Hyprland

With this environment variable set, the exact same output can successfully run at:

5120x1440@60

The previous configuration command now works:

hyprctl eval 'hl.monitor({
    output = "DP-2",
    mode = "5120x1440@60",
    position = "0x0",
    scale = 1
})'

and hyprctl monitors reports the native mode correctly.

So the workaround fully resolves the problem.

Conclusion

This appears to confirm that the issue is related to the DRM buffer modifier / primary-plane compatibility path on Intel Gen9 i915, rather than:

• EDID
• monitor mode availability
• DisplayPort bandwidth
• refresh rate
• the Hyprland monitor configuration itself

AQ_NO_MODIFIERS=1 is therefore a reliable workaround on this hardware.

Possible upstream fix

A more robust solution may be to retry buffer allocation with a reduced modifier set when an ATOMIC_TEST_ONLY commit fails with EINVAL, for example:

1. current explicit modifier set
2. retry without Y-tiled / CCS modifiers
3. retry with X-tiled
4. fallback to linear

That would avoid requiring a global AQ_NO_MODIFIERS=1 workaround and would preserve explicit modifiers where they are valid.

An Intel Gen9-specific quirk based on framebuffer width would probably also work, but a generic modifier fallback after a failed atomic test would be cleaner.

There may also be a separate issue around CRTC reassignment after failed TEST_ONLY commits, but the modifier problem above is sufficient to explain the 5120x1440 failure in my case.

Environment

OS: Omarchy / Arch Linux
Kernel: 7.1.9-arch1-2
GPU: Intel CometLake-U GT2 [UHD Graphics]
Driver: i915
CPU: Intel Core i7-10610U
Hyprland: 0.56.2
Aquamarine: 0.14.0
Monitor: LG Electronics LG HDR DQHD
Connector: DP-2
Native mode: 5120x1440@60

I have now made AQ_NO_MODIFIERS=1 persistent as a local workaround and it perfectly works.
👍