Systemd/Udev boot resolution issue on multihead

Cyantum · 2025-12-08 18:53:28

DE: KDE Plasma (wayland)
Login manager: ly
GPU: Nvidia RTX 580+
Driver: Nouveau
Primary monitor: LG Ultragear 2560 x 1440 (DP-1)
Secondary monitor (left): MSI MD272XP 1920 x 1080 (DP-2)

I'm trying to get either systmd or ly to display at the proper resolution on either both screens, or at least my primary screen. If I only have my primary screen plugged in, everything obviously works fine. But when I plug my second monitor in, it appears that systemd and ly treat my other (lower resolution) monitor as the primary and bases the display behavior off of that.

During boot, I will see the below message on my primary monitor in a lower resolution that has been up-scaled:

:: running early hook [udev]
Starting systemd-udevd version 258.2-2-arch
:: running hook [udev]
:: Triggering uevents...

Then my monitor will refresh, using the secondary monitor's resolution, and what is displayed on the primary monitor appears to be a 1920 x 1080 mirror of the secondary monitor. The remaining screenspace is just black bars.

After this refresh, the screen displays:

:: running hook [keymap]
:: Loading keymap...done.
:: running hook [encrypt]

And after that, it appears to run the rest of the bootup process after I decrypt my drive. Only when I login with ly and load up Plasma does it display properly.

I tried debugging using udev's config as per these instructions, but I only received the following error:

/etc/udev.conf:6 Failed to parse udev_log="debug", ignoring: Invalid argum

These are the only relevant contents of journal -b I could find:

Dec 08 10:31:44 desktop kernel: ACPI: video: Video Device [VGA] (multi-head: yes  rom: no  post: no)
Dec 08 10:31:44 desktop kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:20/LNXVIDEO:00/input/input11
Dec 08 10:31:44 desktop kernel: nouveau 0000:01:00.0: NVIDIA AD104 (194000a1)
Dec 08 10:31:44 desktop kernel: nouveau 0000:01:00.0: gsp: RM version: 570.144
Dec 08 10:31:44 desktop kernel: nouveau 0000:01:00.0: bios: version 95.04.69.00.c1
Dec 08 10:31:44 desktop kernel: Console: switching to colour dummy device 80x25
Dec 08 10:31:44 desktop kernel: nouveau 0000:01:00.0: vgaarb: deactivate vga console
Dec 08 10:31:44 desktop kernel: nouveau 0000:01:00.0: drm: VRAM: 12282 MiB
Dec 08 10:31:44 desktop kernel: nouveau 0000:01:00.0: drm: GART: 536870912 MiB
Dec 08 10:31:44 desktop kernel: nouveau 0000:01:00.0: drm: MM: using COPY for buffer copies
Dec 08 10:31:44 desktop kernel: nouveau 0000:01:00.0: [drm] Registered 4 planes with drm panic
Dec 08 10:31:44 desktop kernel: [drm] Initialized nouveau 1.4.0 for 0000:01:00.0 on minor 0
Dec 08 10:31:44 desktop kernel: fbcon: nouveaudrmfb (fb0) is primary device
Dec 08 10:31:44 desktop kernel: Console: switching to colour frame buffer device 240x67
Dec 08 10:31:44 desktop kernel: nouveau 0000:01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
...
Dec 08 09:39:48 desktop systemd[1]: systemd 258.2-2-arch running in system mode (+PAM +AUDIT -SELINUX +APPARMOR -IMA +IPE +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF +XKBCOMMON +UTMP -SYSVINIT +LIBARCHIVE)

One possible idea would be that my support monitor is simply booting faster than my primary! If that's the case, I'm sure I could find a way to disable that monitor on bootup, and re-enable it when I log in - but that seems pretty hacky and doesn't actually diagnose the problem. Any idea what might be going on? Ideally I'd like to just have my primary monitor during boot/ly, but I'll settle for both monitors being the correct resolution.

Last edited by Cyantum (2025-12-08 20:24:23)

tony5429 · 2025-12-09 18:11:20

OK, I asked ChatGPT about your question because I was at a loss. This is the response I got...

You’re not crazy — what you’re seeing is a **classic kernel / fbcon / DRM connector-order problem**, and it has *nothing* to do with KDE or Wayland proper. Plasma fixes it later because it applies real KMS modes once the session starts.

Below is what’s actually happening, why the “faster monitor” theory is basically correct, and what you can *cleanly* do about it.

---

## What’s really going on (high-level)

### 1. Early boot ≠ Wayland ≠ KDE ≠ ly

During:

* initramfs
* systemd early boot
* LUKS prompt
* ly’s own renderer

Linux is using:

* **kernel modesetting**
* **nouveau DRM**
* **fbcon (framebuffer console)**

No compositor. No KWin. No Wayland protocols. No per-monitor logic.

---

### 2. fbcon picks *one* DRM connector and mirrors it

This line tells the whole story:

```
fbcon: nouveaudrmfb (fb0) is primary device
```

fbcon:

* uses the **first DRM connector that becomes “connected”**
* sets a single framebuffer mode
* mirrors it to *all attached outputs*

If DP-2 (1080p) comes up first:

* fbcon locks to 1920×1080
* DP-1 (1440p) gets a scaled clone
* black bars appear because the mode doesn’t match the panel

This is **expected behavior**, not a bug.

> ✅ Your “the lower-res monitor boots faster” theory is essentially correct.

---

### 3. ly is innocent (mostly)

`ly`:

* uses `/dev/dri/card*`
* inherits whatever fbcon/KMS handed it
* has **no multi-monitor policy**
* cannot re-negotiate modes like a real compositor

Once Plasma starts:

* KWin queries DRM properly
* assigns per-output modes
* everything “magically fixes itself”

---

## The udev debug error (ignore it)

```
/etc/udev.conf:6 Failed to parse udev_log="debug"
```

That’s because:

* `udev_log` was removed
* udev config lives in systemd now
* the Arch wiki page you followed is **outdated**

✅ This is not related to your display issue at all.

---

## What *won’t* fix this

* udev rules (too late in the boot process)
* ly config alone
* Wayland tweaks
* Plasma display settings
* waiting for monitors to sync

This is decided **before userspace really exists**.

---

## Clean, non-hacky solutions (pick one)

### ✅ **Best fix: Force the console mode via kernel parameters**

Explicitly tell the kernel what modes to use.

Edit `/etc/default/grub`:

```bash
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash \
video=DP-1:2560x1440@60 \
video=DP-2:1920x1080@60"
```

Then:

```bash
sudo grub-mkconfig -o /boot/grub/grub.cfg
```

What this does:

* forces DRM modes *before* fbcon attaches
* prevents “first connector wins” behavior
* works with nouveau
* works with LUKS prompts
* works for ly

✅ This is the **most correct fix**.

---

### ✅ **If you want only the primary monitor during boot**

Disable the secondary *at kernel level*:

```bash
video=DP-2:d
```

Full example:

```bash
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=DP-2:d"
```

Then Plasma will re-enable it later automatically.

✅ Not hacky — this is how servers do it.

---

### ✅ **Alternative: Make DP-1 the fbcon primary**

Less reliable, but sometimes enough:

```bash
fbcon=map:1
```

Where:

* `map:1` maps fbcon to the second registered framebuffer
* ordering depends on driver probe order

I recommend this **only** if the `video=` approach fails.

---

## Why this is worse on NVIDIA + nouveau

* Nouveau KMS is slower to negotiate EDID
* Connector detection order can change between boots
* GSP firmware adds additional delay
* fbcon does *not* dynamically re-evaluate modes

This is why Intel/AMD users see it less often.

---

## Why systemd and ly “seem” to choose the wrong monitor

They didn’t choose anything.

They inherited:

* whatever fbcon decided
* based on which DP link finished training first

---

## TL;DR (recommended setup)

**Do this and you’re done**:

```bash
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash \
video=DP-1:2560x1440@60 \
video=DP-2:1920x1080@60"
```

Rebuild grub, reboot.

✅ Correct resolution during:

* initramfs
* LUKS prompt
* systemd
* ly
* Wayland session

If you want, I can also:

* help you identify exact connector names (`modetest`, `/sys/class/drm`)
* tailor this for systemd-boot instead of GRUB
* walk through a simpledrm vs nouveaudrmfb fallback setup

You diagnosed the root cause correctly — you just needed to solve it at the **kernel → DRM → fbcon** layer instead of userspace.

tekstryder · 2025-12-09 20:05:44

AI version of lmgtfy

Let Me Grok That For You

Cyantum · 2025-12-10 14:13:09

tony5429 wrote:

You’re not crazy — what you’re seeing is a **classic kernel / fbcon / DRM connector-order problem**, and it has *nothing* to do with KDE or Wayland proper. Plasma fixes it later because it applies real KMS modes once the session starts.

OK this makes a lot of sense! Thanks for the really detailed response - before I go goofing with kernel parameters, my guess would be that the fix for systemd-boot is editing /boot/loader/.conf and adding

video=DP-1:2560x1440@60 \
video=DP-2:1920x1080@60"

or, to disable the secondary monitor,

video=DP-2:d

To the bottom, then running bootctl before next system reboot?

Last edited by Cyantum (2025-12-10 14:16:23)

V1del · 2025-12-11 17:02:42

systemd-boot reads it's config when you edit it, you shouldn't need to rerun bootctl. The reast should be okayish: https://docs.kernel.org/fb/modedb.html -- also doubt that systemd-boot has a \ based newline escape parser and to be sure you'd put both values on the same line. You'll also want to apply this to the relevant entries, not the loader configuration. https://wiki.archlinux.org/title/System … ng_loaders

system72 · 2025-12-11 17:09:06

markdown doesnt work on this forum

Cyantum · 2025-12-13 16:09:03

OK I've tried a few boot options in my /boot/loader/entries/XXX_linux.conf (since that's what bootctl says I'm using) as per this documentation. I've only got the spoons in me to try a few combinations but this might help narrow it down.

# For all combinations, this is a universal behavior, after prompting for an encryption password:
nouveau 0000:01:00.0: drm: DDC responded, but no EDID for DP-2
# I only see the above error error when DP-1 is rendering correctly, but it might also be hidden with the other configs and will require more time to confirm it's not hidden somewhere
# The below errors repeat something like four or five times
nouveau 0000:01:00.0: gsp: cli:0xc1d00001 obj:0x00730000 ctrl cmd0x00731343 failed: 0x00000001
nouveau 0000:01:00.0: drm: [DRM/00000009:kmsOutp] [DP_TRAIN retain:0 lttprs:0 post_lt_adj:0 nr:X bw:XX0000] (ret:-5)
                                                                                              #^ X's are different every time, the vibe I get is this is some sort of automated adjustment process?

# Here are the configs I tried, along with some commentary about the errors

  1) video=DP-1:2560x1440@60D video=DP-2:1920x1080@60d
  2) video=DP-1:2560x1440@60e video=DP-2:1920x1080@60d
  # ^ Longer boot time, correct DP-1 resolution, DP-2 disabled after ":: Triggering uevents..." DP-2 not enabled by plasma
  3) video=DP-1:2560x1440@60D video=DP-2:1920x1080@60D
  # ^ Renders the original problem, with the addition of the nouveau errors
  4) video=DP-1:2560x1440@60D video=DP-2:1920x1080@60
  5) video=DP-1:2560x1440@60D
  # ^ DP-1 renders at 640x480, nouveau errors, only applies settings after ":: Triggering uevents..."

I'm out of coffee and I'll come back to this later

Last edited by Cyantum (2025-12-15 13:30:22)

Arch Linux

#1 2025-12-08 18:53:28

Systemd/Udev boot resolution issue on multihead

#2 2025-12-09 18:11:20

Re: Systemd/Udev boot resolution issue on multihead

#3 2025-12-09 20:05:44

Re: Systemd/Udev boot resolution issue on multihead

#4 2025-12-10 14:13:09

Re: Systemd/Udev boot resolution issue on multihead

#5 2025-12-11 17:02:42

Re: Systemd/Udev boot resolution issue on multihead

#6 2025-12-11 17:09:06

Re: Systemd/Udev boot resolution issue on multihead

#7 2025-12-13 16:09:03

Re: Systemd/Udev boot resolution issue on multihead

Board footer