Internal display lost on hybrid AMD/NVIDIA laptop after mesa 26.1.8 → 26.2.2 (Fedora 44 cosmic-atomic)

Ask Fedora
, , , ,
1

I’m using my laptop together with an external monitor connected via display port. After my last update, the internal monitor is no longer recognized so it stays black.

ASUS ROG Zephyrus G14, AMD Cezanne iGPU + NVIDIA RTX 3060 nouveau

Running Fedora 44 COSMIC Atomic, fully updated as of Sept 17

confirmed via rollback: works on mesa 26.1.8, breaks on 26.2.2

My Investigation

I found that the DRM sees the panel as connected. The internal eDP panel is on card2 (AMD iGPU/amdgpu); the external DP output is on card1 (NVIDIA dGPU/nouveau).

❯ grep -H . /sys/class/drm/card*-*/status
/sys/class/drm/card1-DP-1/status:connected
/sys/class/drm/card2-eDP-1/status:connected
/sys/class/drm/card2-HDMI-A-1/status:disconnected

The Zephyrus has a dedicated NVIDIA graphics card that I have been using with nouveau for a long time without issues.

❯ lspci -k | grep -A3 -i -E "vga|3d controller|display controller"
01:00.0 VGA compatible controller: NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile / Max-Q] (rev a1)
	Kernel driver in use: nouveau
--
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] (rev c4)
	Kernel driver in use: amdgpu

During boot, both screens are still showing the manufacturer logo and the LUKS unlock screen with Plymouth, after the hand off the internal monitor goes dark and only the external monitor is displaying correctly. Disconnecting the external monitor and closing the lid both did not work to reanimate the internal screen.

❯ journalctl -b | grep -i -E "drm.*master"
Sep 17 10:47:10 fedora cosmic-comp[1873]: Unable to become drm master, assuming unprivileged mode
Sep 17 10:47:10 fedora cosmic-comp[1873]: Unable to become drm master, assuming unprivileged mode

If I then rollback to my previous deployment, everything works fine. Out of all the packages upgraded, I can only see the mesa ones being related to graphics.

❯ rpm-ostree db diff 6dc807c47f30d34f89a8611070c2d546c74a039ceefd1fdc97837bc26a72d2ed d300386681cc07277db3026424e82b34763c94b5fe2f9f35678c25cda725ed7e
ostree diff commit from: 6dc807c47f30d34f89a8611070c2d546c74a039ceefd1fdc97837bc26a72d2ed
ostree diff commit to:   d300386681cc07277db3026424e82b34763c94b5fe2f9f35678c25cda725ed7e
Downgraded:
  libtirpc 1.3.8-0.fc44 -> 1.3.7-2.rc1.fc44
  mesa-dri-drivers 26.2.2-6.fc44 -> 26.1.8-1.fc44
  mesa-filesystem 26.2.2-6.fc44 -> 26.1.8-1.fc44
  mesa-libEGL 26.2.2-6.fc44 -> 26.1.8-1.fc44
  mesa-libGL 26.2.2-6.fc44 -> 26.1.8-1.fc44
  mesa-libgbm 26.2.2-6.fc44 -> 26.1.8-1.fc44
  mesa-vulkan-drivers 26.2.2-6.fc44 -> 26.1.8-1.fc44
  python3-boto3 1.43.93-1.fc44 -> 1.43.91-1.fc44
  python3-botocore 1.43.93-1.fc44 -> 1.43.91-1.fc44
  rpcbind 1.3.1-0.fc44 -> 1.2.9-2.fc44
  selinux-policy 44.9-1.fc44 -> 44.8-1.fc44
  selinux-policy-targeted 44.9-1.fc44 -> 44.8-1.fc44

Has anyone else hit this since updating? Should this be filed against mesa directly or is there an existing issue?

2

There is an issue with AMD GPUs since the last update. Its also described in here.
For me, the workaround in here fixed it. But there should be an update in the next days too.

3

While the nouveau driver may meet your needs at present, there are some issues with that reverse engineered open source driver.

Most notable is that it cannot do any hardware acceleration of video graphics and must offload the processing to the CPU instead of managing the rendering on the GPU itself.

Most users find that installing the nvidia driver from the rpmfusion repo is better for graphics performance. Instructions here if you should decide to switch to the nvidia driver.