KDE display problem after upgrading Fedora 43 to Fedora 44

Ask Fedora
1

The symptom is that my third display works up to the log in screen, but once I log in, the signal to that display is turned off. Display configuration still shows the display and says it is enabled. But there is no signal reaching the display.

Actually the problem was in the change from kernel 6.19 to 7.2

(Edit: later tested: works in 7.1.13 fails in 7.2.4)

It goes back to working (even in Fedora 44) if I boot into an older kernel.

When it works, kinfo is this:

Operating System: Fedora Linux 44
KDE Plasma Version: 6.7.5
KDE Frameworks Version: 6.30.0
Qt Version: 6.11.2
Kernel Version: 6.19.14-200.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 Ă— AMD Ryzen 7 5800X 8-Core Processor
Memory: 32 GiB of RAM (31.2 GiB usable)
Graphics Processor: AMD Radeon RX 6650 XT

When it fails kinfo is this:

Operating System: Fedora Linux 44
KDE Plasma Version: 6.7.5
KDE Frameworks Version: 6.30.0
Qt Version: 6.11.2
Kernel Version: 7.2.5-100.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 Ă— AMD Ryzen 7 5800X 8-Core Processor
Memory: 32 GiB of RAM (31.2 GiB usable)
Graphics Processor: AMD Radeon RX 6650 XT

Online descriptions of similar KDE problems vary on whether they also saw the display still shown in Display Configuration, but are consistent in saying which files you can delete in ~/.config and ~/.local/share to fix it. But that doesn’t fix it. (Clearly all those similar problems were something different, while now that I know more, I see a bunch of less similar by symptom problems in amdgpu in the kernel change from 7.1 to 7.2 that are likely the same problem).

EDIT: It is now semi-fixed: I discovered that in the new kernel the 3840x2160 HDMI works at 30hz and fails at 60hz, while in the old kernel it works equally well either way. (Maybe due to age combined with not gaming) I can’t actually see the difference. So it is now at 30hz and working. I refuse to call that “solved”. Until I understand the driver change that made this difference, I still hope someone can tell me what is going on or tell me what to test or examine to find out.

3

I recall reports of recent changes affecting handling of some cable/port type combinations, so it might be useful to have details of your configuration. There should be some relevant details in the journal.

4

I don’t know what to look for in the journal. Do you have a more specific suggestion?

5

Start with journalctl <minus><minus>no-hostname -b -p 3 and look for entries related to displays. If that doesn’t reveal the problem, try a) swapping ports and cables, and b) check if the issue affects a new “test user” login, which would suggest a user-specific setting as the source of the problem.

6

-p 3 produces next to nothing including nothing about the display. Less restrictive choices produce too much for me to be likely to spot the issue in.

I did filter the journal for amdgpu and saw no interesting difference between booting a kernel that works vs. one that fails.

I had already tried a new “test user” to rule out any user specific settings.

I have too little flexibility in cable types to make any useful change swapping ports. That is also very unlikely to fix anything. I should try disconnecting the other two displays to see whether the 3840x2160 HDMI works when it is the only display connected. But that is harder to try than you might expect and the information wouldn’t be terribly useful.

7

Cables fail all too often, so it is worth paying for quality and having a spare for at least one monitor.

Searching for your specific monitor might find other reports for the issue.

8

Did you reread my edits to the top post and did you read the related thread found and linked by pg-tips?

It is not a problem in my cable nor specific to my monitor.

The port choice on my card might matter. But that is hard to test. The total refresh load on the card’s memory might matter, and removing the two lower res monitors would cut that load in half, but somewhat hard to test. Under it all, there was some change to amdgpu and/or closely related software in the kernel change from 7.1 to 7.2 that takes away capacity these cards had before that change. I don’t know what testing might provide further clarification of that.

9

Could it be this issue? (I found this on an Arch issue tracker, but I don’t think the kernel will differ importantly here in Fedora.)

From there there is a link to an upstream ticket.

10

I am close to certain that is exactly the issue I have. Thankyou for connecting it to an existing report of a bug that IIUC was already corrected in later code.

So I can keep either a 7.1 kernel or a lower refresh rate until that correction arrives.

Also, IIUC, the fix wouldn’t ever be pulled into 7.2.?? so we are waiting for at least 7.3.

I’m fine with that (only terribly inconvenienced by this BEFORE I understood it). But I expect others are in worse shape. I wouldn’t begin to know who to ask to get the already complete correction pulled in sooner.