Monitor order changes randomly after kernel 7.1.13 → 7.2.x, breaking saved scale and Tiling Shell layout (GNOME, NVIDIA, 2x DisplayPort)

Ask Fedora
1

Summary

Since updating from kernel 7.1.13 to the 7.2.x series, on random boots the internal order in which GNOME Shell/mutter enumerates my two monitors changes. This causes two symptoms:

  1. The saved scale for my primary monitor (1440p) resets from 100% to 125% (an old value I no longer use).
  2. The Tiling Shell extension swaps the tiling layout between screens (the layout that should be vertical on the 1440p shows up on the 1080p instead, and vice versa).

With kernel 7.1.13 this never happened, even switching between Windows and Fedora many times. With both 7.2.4 and 7.2.5 it happens consistently across multiple reboots.

Environment

  • Fedora Linux 44, GNOME, Wayland session
  • Kernels tested: works fine on kernel-7.1.13, fails on kernel-7.2.4-200.fc44 and kernel-7.2.5-200.fc44
  • GPU: NVIDIA RTX 4080 Super, proprietary driver 610.57.04 (RPM Fusion, akmod-nvidia)
  • 2 monitors, both connected via DisplayPort: GIGABYTE AORUS FO27Q2 (2560x1440, primary) and ASUS MG248 (1920x1080, rotated to portrait)
  • A third display (Samsung TV over HDMI) is forced off via the video=HDMI-A-1:d kernel boot parameter (set previously to fix an unrelated GDM login issue). Confirmed via journalctl that this connector never activates, so it is not involved in this issue.

Evidence (journalctl -b 0)

Within the same boot, only 5 seconds apart, the monitor order reported by GNOME Shell changes:

[tilingshell] updateMonitorName: monitorsDetails=[{"name":"ASUSTek...","index":0},{"name":"GIGA-BYTE...","index":1}]
...(5s later)...
[tilingshell] updateMonitorName: monitorsDetails=[{"name":"GIGA-BYTE...","index":0},{"name":"ASUSTek...","index":1}]

This matches the pattern described in mutter issue ‘Order of monitors changes when monitors are turned on’ (GNOME/mutter #2989), but in my case it reproduces consistently after moving from 7.1.13 to 7.2.x, not from manually turning monitors on/off.

Steps to reproduce

  1. Boot Fedora 44 on kernel 7.2.4 or 7.2.5 with 2 monitors connected via DisplayPort from power-on.
  2. Reboot several times.
  3. On some boots, the 1440p monitor’s scale shows as 125% instead of the saved 100%, and/or the Tiling Shell layout appears swapped between screens.

What I’ve already ruled out

  • Not a bad monitors.xml: the correct values are saved, but an old/incorrect saved configuration gets applied intermittently.
  • Not the third HDMI display: it’s forced off via kernel parameter and journalctl confirms it never activates.
  • Manually reconfiguring the displays each time does not fix it permanently.

Possibly related

This might be connected to a broader kernel regression rather than something NVIDIA-specific — see Dual monitor setup broken after Fedora updates, where a different user with an AMD Radeon RX 6700 XT (amdgpu, KDE Plasma) also reports multi-monitor breakage right around the same 7.1.x → 7.2.x kernel transition, and a related thread there mentions the same happening going from ~6.19 to 7.2. Different symptoms and different GPU vendor, but the same kernel version range, which suggests the root cause may be in generic DRM/KMS kernel code rather than in a specific driver.

Has anyone else with NVIDIA + multiple DisplayPort monitors noticed this behavior change starting with the 7.2.x kernel series? Should I open a formal kernel Bugzilla, or is this more likely on the akmod-nvidia/RPM Fusion side?

EDIT: I need to correct something in my original post. I went ahead and actually installed kernel-7.1.13-200.fc44 from Koji to test it directly (rather than relying on memory), and the issue reproduces there as well — same scale reset (100% → 125%) and same Tiling Shell layout swap.

So this is NOT specific to the 7.2.x series as I originally claimed. It happens on 7.1.13, 7.2.4, and 7.2.5 alike. My apologies for the incorrect lead — it was based on not having rebooted enough times on 7.1.13 to hit the bad case, rather than an actual difference in behavior.

Given this, it looks less like a kernel regression and more like a pre-existing, probabilistic race condition in how mutter/GNOME Shell enumerates monitor order at boot (see the journalctl evidence in my original post — the monitor order flips within the same boot, 5 seconds apart). The kernel version doesn’t seem to be the deciding factor; it may just come down to boot-to-boot timing luck.

Still interested in hearing if anyone has found a way to make mutter’s monitor enumeration deterministic, or a known workaround for extensions (like Tiling Shell) that key off array index instead of a persistent monitor identifier.