Bugzilla – Bug 1214259
Unable to use 4k resolution using the DisplayPort on ryzen 9 7900
Last modified: 2023-09-24 19:09:43 UTC
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0 Build Identifier: The new motherboard (MSI B650 Carbon WiFi), as most of the others, has two monitor ports: an HDMI and a DisplayPort. My monitor is a Samsung LU28E590 with freesync capability. The problem is that I'm unable to use 4k resolution when the monitor is attached to the DP, while it works fine using the HDMI port. Tests I made that makes me conclude this is a linux/kernel problem and not an hw problem: - the problem is there even using wayland - the monitor on DP works fine if I install windows on the same PC - the same monitor on another PC with a discrete radeon card works correctly on the DP - another 4K monitor I had access to is working correctly even on the DP I tried thumbleweed to be sure to have latest kernel (6.4.9), mesa and desktops (tried both with KDE and gnome). Reproducible: Always Steps to Reproduce: 1.install the system 2.enter graphic mode 3.verify the resolution of the desktop is 2560x1440 instead of 3840x2160 Expected Results: I should be able to use native 4k resolution as it happens under windows (or using a discrete VGA instead of the CPU integrated one)
Created attachment 868795 [details] content of /sys/class/drm/card0-HDMI-A-1/edid This is the EDID file of the monitor when attached to the HDMI port, and working correctly
Created attachment 868796 [details] content of file /sys/class/drm/card0-DP-1/edid This is the EDID file of the monitor when attached to the DP, not working correctly
I see the EDID informations do not correspond if I attach the same monitor to the two different ports: even the model and serial number are not the same! The correct serial number is the one reported on the HDMI interface. Now the thing becomes too technical for me, is this simply a case of bad EDID or some kind of bug related on how to retrieve the information from the monitor? Or is it a sw bug on the monitor side? In either case some help on how to fix the problem, maybe with a custom edid to put in /lib/firmware/edid would be very appreciated!
I am not an expert, but this looks like a kernel/amdgpu driver DP issue in combination with the specific monitor. I don't have the monitor in question and I have not tried this, but you should be able to save the EDID from the HDMI port e.g.: - Boot with HDMI connected: sudo mkdir -p /usr/lib/firmware/edid sudo cp /sys/class/drm/card0-HDMI-A-1/edid /usr/lib/firmware/edid/LU28E590.bin - Then shutdown, reboot with DP connected and specify this extra kernel parameter at GRUB: "drm.edid_firmware=DP-1:edid/LU28E590.bin" if you are not sure DP-1 is the specific DP connector used, just use: "drm.edid_firmware=edid/LU28E590.bin" Then see if the 4K resolution is now applied. If none of this works maybe we can spot something in boot/debug logs. - Connect DP - Enable debugging of drm: add "drm.debug=0x1e" to the kernel parameters at GRUB - Save the output "dmesg" command, and attach the output to Bugzilla - possibly also share output of xrandr Repeat the same with HDMI connected and also share the dmesg/xrandr with HDMI connected.
Hello Vasilis and thank you very much for your input: very appreciated! I tried the various proposed steps but unfortunately they did not help. Actually after a few reboots (I did a lot) sometimes it's possible to set the monitor in 4K but *only* at 30hz, rendering it useless (the refresh is way too slow to be usable). I attach the huge kernel log hoping that can be useful: I'm unable to make any sense out of them, unfortunately. If I can provide more useul information just ask!
Created attachment 868810 [details] kernel debug with monitor on the HDMI port
Created attachment 868811 [details] kernel debug with monitor on the DP port
This is the output of xrandr while using the HDMI port: Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384 HDMI-A-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 608mm x 345mm 3840x2160 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98 2560x1440 59.95 1920x1200 60.00 1920x1080 60.00 50.00 59.94 30.00 24.00 29.97 23.98 1600x1200 60.00 1680x1050 59.88 1600x900 60.00 1280x1024 75.02 60.02 1440x900 59.90 1280x800 59.91 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.03 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DisplayPort-0 disconnected (normal left inverted right x axis y axis) DisplayPort-1 disconnected (normal left inverted right x axis y axis) DisplayPort-2 disconnected (normal left inverted right x axis y axis) This is instead the output while using wayland, always with HDMI: Screen 0: minimum 16 x 16, current 3840 x 2160, maximum 32767 x 32767 XWAYLAND1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 610mm x 350mm 3840x2160 59.98*+ 2048x1536 59.95 1920x1440 59.97 1600x1200 59.87 1440x1080 59.99 1400x1050 59.98 1280x1024 59.89 1280x960 59.94 1152x864 59.96 1024x768 59.92 800x600 59.86 640x480 59.38 320x240 59.52 2560x1600 59.99 1920x1200 59.88 1680x1050 59.95 1440x900 59.89 1280x800 59.81 720x480 59.71 640x400 59.95 320x200 58.96 3200x1800 59.96 2880x1620 59.96 2560x1440 59.96 2048x1152 59.90 1920x1080 59.96 1600x900 59.95 1368x768 59.88 1280x720 59.86 1024x576 59.90 864x486 59.92 720x400 59.55 640x350 59.77
This is the xrandr output using DP: Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384 HDMI-A-0 disconnected (normal left inverted right x axis y axis) DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 607mm x 345mm 2560x1440 59.95* 1920x1080 60.00 59.94 1680x1050 59.95 1600x900 60.00 1280x1024 60.02 1440x900 59.89 1280x800 59.81 1280x720 60.00 59.94 1024x768 60.00 800x600 60.32 56.25 640x480 60.00 59.94 And this one is the output using wayland (always using DP): Screen 0: minimum 16 x 16, current 2560 x 1440, maximum 32767 x 32767 XWAYLAND0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 610mm x 350mm 2560x1440 59.91*+ 1920x1440 59.90 1600x1200 59.87 1440x1080 59.87 1400x1050 59.86 1280x1024 59.89 1280x960 59.94 1152x864 59.78 1024x768 59.68 800x600 59.86 640x480 59.38 320x240 59.52 1920x1200 59.88 1680x1050 59.85 1440x900 59.89 1280x800 59.81 720x480 59.71 640x400 59.20 320x200 58.96 2048x1152 59.90 1920x1080 59.88 1600x900 59.82 1368x768 59.88 1280x720 59.86 1024x576 59.90 864x486 59.45 720x400 59.55 640x350 59.77
btw, the loading of the edid file seems to fail with this error: [drm:retrieve_link_cap [amdgpu]] Rx Caps: amdgpu 0000:12:00.0: Direct firmware load for edid/LU28E590.bin failed with error -2 amdgpu 0000:12:00.0: [drm] *ERROR* [CONNECTOR:84:DP-1] Requesting EDID firmware "edid/LU28E590.bin" failed (err=-2) amdgpu 0000:12:00.0: [drm:update_display_info [drm]] [CONNECTOR:84:DP-1] Supported Monitor Refresh rate range is 40 Hz - 60 Hz amdgpu 0000:12:00.0: [drm:update_display_info [drm]] [CONNECTOR:84:DP-1] Assigning EDID-1.4 digital sink color depth as 10 bpc.
(In reply to Alex from comment #10) > btw, the loading of the edid file seems to fail with this error: > > [drm:retrieve_link_cap [amdgpu]] Rx Caps: > amdgpu 0000:12:00.0: Direct firmware load for edid/LU28E590.bin failed with > error -2 > amdgpu 0000:12:00.0: [drm] *ERROR* [CONNECTOR:84:DP-1] Requesting EDID > firmware "edid/LU28E590.bin" failed (err=-2) Strange. Error -2 is ENOENT (no such file or directory). I assume /usr/lib/firmware/edid/LU28E590.bin is where you actually saved the HDMI EDID? From the DP kernel log: [drm:create_validate_stream_for_sink [amdgpu]] Mode 3840x2160 (clk 594000) failed DC validation with error 10 (No DP link bandwidth) The amdgpu driver refused to set this mode with DP. In the HDMI log there is no such problem. I belive the driver does some bandwidth calculations to see if a mode should be allowed. In this case there is no bandwidth information provided? Likely this is because of the bad EDID. On the other hand, I am not sure if substituting a DP EDID with an HDMI EDID is sane. It also wouldn't hurt to try with more up-to-date TW kernel 6.4.x, I see you are using 6.2.0-27-generic. Or even a bleeding-edge kernel (but make sure you keep a old kernel too, if something breaks) https://en.opensuse.org/openSUSE:Kernel_of_the_day Finally, what kind of cable is your DP cable? Is it DP-to-DP, or something else? If it is not DP-to-DP e.g. DP-to-HDMI some people report issues when using "passive" cabled instead of "active" cables (an active cable does signal conversion itself), but I don't have first-hand experience with such an effect. I am afraid I am running out of ideas, hopefully graphics developers will jump in soon with other ideas.
Interesting related read on sway: https://github.com/swaywm/sway/issues/7367 and related amdgpu bug (which disappeared on 6.3, so maybe try newer kernel than your current 6.2): https://gitlab.freedesktop.org/drm/amd/-/issues/2365 Finally, I forgot to say there is a kernel warning related to DP (in the DP kernel log, function dp_retrieve_lttpr_cap), so this could also be a potential issue, but not necessarily related to enabling the 4K mode. This has been reported upstream, and it still happens on 6.4: https://gitlab.freedesktop.org/drm/amd/-/issues/?search=dp_retrieve_lttpr_cap&sort=created_date&state=opened&first_page_size=20
The file is in the correct position of the file system, but reading a bit around it seems like it must be added to the initramfs, I didn't try yet. I will wait until a kernel fixing that error is out first: do you know if the fix will be applied to 6.5?
(In reply to Alex from comment #13) > I will wait until a kernel fixing that error is out first: do you know if > the fix will be applied to 6.5? I don't know if there is a fix for the kernel warning (last link of comment#13) yet unfortunately. If I find something, I will let you know.
This looks like a kernel issue. Reassigning.
does anybody know if the fix made it in kernel 6.5?
Honestly speaking, I don't know. At best try it out from OBS Kernel:stable repo :) And, if the problem persists: care to report the issue to the upstream devs via gitlab.freedesktop.org issues?
It seems like they are reported there already, Vasilis linked a page with the summary. For example this one: https://gitlab.freedesktop.org/drm/amd/-/issues/2355
(In reply to Alex from comment #18) > It seems like they are reported there already, Vasilis linked a page with > the summary. > > For example this one: https://gitlab.freedesktop.org/drm/amd/-/issues/2355 This entry merely reports about some spurious kernel warning, and it doesn't tell the exact problem you have. Maybe better report your problem individually, and mention the possibly relevance with the entry above.
I tried kernel 6.5.4 and the oops is still there :-(