AMD Raphael [iGPU] Black screen and nonsensical display resolution

[Ruslan-Riazantsev]

Hello, the issue is not of a huge importance to me, but I'd like to give as much useful information about it as I can. I have little experience with creating issues and giving feedback, so please bear with me, and let me know what else I can do to make it easier and more beneficial for the project.

I have the next system:
Operating System: CachyOS Linux
KDE Plasma Version: 6.6.0
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.19.3-2-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor
Memory: 32 ГіБ of RAM (30.5 ГіБ usable)
Graphics Processor 1: AMD Ryzen 5 7600X 6-Core Processor
Graphics Processor 2: AMD Radeon RX 6900 XT
Matherboard: ASUS [ROG STRIX B650E-E GAMING WIFI]

I use 42" 4k 120Hz LG C2 TV as my main and only display. When I discovered the Reddit thread about the work that have been done here I've got ecstatic about it! I've read that RX 6000 GPUs are not supported yet, but my iGPU should be fine, if I am not mistaken, so I reconnect my display to the HDMI port on my motherboard and decided to give it a try.

Here is EDID information:
EDID info.txt

I've tried to use CachyOS Kernel Manager to build the stable 6.19.3 kernel with the patch file that was generated by your workflow described here
After removing the conflicting CachyOS patch and successfully building the kernel, after which I switched my display settings to 1920x1080 and 60 Hz and made a reboot, but I wasn't able to login into Plasma, and even Plasma Login Manager didn't show up.

It was mostly a flickering black screen, and sometimes TV showed warning about unsupported resolution or something like that. When I pressed the green button several times on the remote the information panel appeared (I don't know its proper name), but the resolutions and refresh rate were changing constantly in nonsensical ranges (from 60 Hz and lower to 500+ Hz, and from lower than HD to some 320x32000 and 16000x32000).

I am not sure how to get dmesg when my display is black and flickering, and I wasn't able to switch to a VT as well, but if you need any other information, or you can give any tips how to make this issue more detailed - don't hesitate to let me know!

[mkopec]

Commit 707f66d might help

[Ruslan-Riazantsev]

@mkopec Still no lack with the most up-to-date stable branch, but I discovered that I can boot and login when my HDMI cable is connected to my RX 6900 XT. Here is some info from dsmesg and from "journalctl -b -1 --system".

dsm.log

journalctl.log

I have switched between iGPU and dGPU several times (2 or 3, don't remember exactly). I have also noticed that if I disable any kind of VRR (Freesync, etc) the iGPU outputs 0Hz and no relolution, but when I enable it - the refresh rate is now never higher than 60, but resolutions are still have no sense (like 360x25k and constantly changing).

With the fixed refresh rate I get a black screen and eventually lose signal, and with VRR enabled - black screen with strange resolutions and eventual warning from TV for "Unsopported format" or something similar.

So I'd say there is definitely some progress in terms of refresh rate (now it's never more than 60 for iGPU) and everything works as with regular CachyOS kernel for my dGPU. If Ican provide any more info for you - let me know!

[mkopec]

Hmm ported some fixes from dcn32 to dcn314, might also help: b7afac7 a7def98

[Ruslan-Riazantsev]

@mkopec not much changed. I was able to boot only with HDMI connected to dGPU and as soon as I switched to iGPU either a black screen of nothing and a lost signal in 5-10 seconds (VRR disabled), or another black screen with ever-changing resolutions and refresh rates. I am not sure, but seems like 500+ Hz returned as well.

What I've noticed is that soon after the boot even dGPU were artifacting and flickering, but seem to normalize after several switches.

dsm.log
journalctl.log

[mkopec]

So I came up with a way to debug this, it's not convenient but I tried my best to make it straightforward: https://github.com/mkopec/dcn_regdump

Basically you (or someone else with a DCN 3.1.x based APU) would need to boot up a Windows VM with the GPU passed through, and run the script on the Linux host (for example via SSH) while the Windows VM is running and HDMI is connected and working properly. This is the fastest way to see what Windows does differently and what I need to do in Linux.

[mkopec]

Actually, I got the register dumps for DCN 3.1.5, so it would be enough if you ran https://github.com/mkopec/dcn_regdump on Linux while HDMI is plugged in . That would tell us exactly what Linux didn't set properly

[Ruslan-Riazantsev]

Actually, I got the register dumps for DCN 3.1.5, so it would be enough if you ran https://github.com/mkopec/dcn_regdump on Linux while HDMI is plugged in . That would tell us exactly what Linux didn't set properly

Sorry I didn't have time to setup a VM with the GPU pass-through (haven't tried it once, so I needed a bit more time to research how to do it). It is nice to hear this is not needed anymore.
Must I run it with the patched kernel, or a regular one should work too?

[mkopec]

On the patched kernel :)

[Ruslan-Riazantsev]

On the patched kernel :)

Thanks :)

Since my TV is my only display I still can't boot into Plasma directly with the HDMI connected to the MB, so I booted connected to my RX 6900 XT, ran script once, then prepared everything for the second run, switched the HDMI port and ran it again. The screen was black so I hope script finished successfully.

dcn_regdump_RX6900XT.20260225-033559.log
dcn_regdump_with_HDMI_plugged_in.20260225-033857.log

[mkopec]

hmm i looked up your motherboard, it seems it only supports 4K60 which would imply it can only do TMDS signaling

Now the question is, does Windows actually attempt to use FRL, and if so, which rate.

There should be some VBIOS bits I should be able to use to detect if FRL is actually supposed to be enabled on the given board, but I don't know the bit definitions so for now everyone gets FRL even if it's not actually supported by the hardware. Hence you getting crazy data sent to the display.