RX 9070 XT + KDE Wayland: 4K 160 Hz fails on DP 1.4, 4K 120 Hz works

Santo C01 · Yesterday 02:22:05

Post
Hi,
I originally posted about this in the Newbie Corner, but after doing more troubleshooting I think this may be a more specific AMDGPU / DRM / KDE Wayland modesetting issue, so I am posting it here where it may be more appropriate.
I recently changed my GPU to an AMD Radeon RX 9070 XT. My main monitor is an ASUS ROG Strix XG27UCG, connected through DisplayPort.
The monitor normally operates at 3840×2160 (4K) and supports refresh rates up to 160 Hz.
It also has an ASUS feature called Dual Mode. This allows the monitor itself to switch between its native 4K high-refresh mode and a 1920×1080 high-refresh mode intended for competitive gaming.
I mention Dual Mode to explain the capabilities/configuration of the monitor. I have not yet tested Dual Mode with the RX 9070 XT, so I am not reporting any Dual Mode problem with AMD.
I previously used this monitor with an NVIDIA GPU and experienced an issue when changing Dual Mode, but that was under a completely different GPU/driver stack. I therefore consider that a separate issue and do not want to use it as evidence for the current AMD problem.
Current problem with the RX 9070 XT
With the current AMD setup:
- 3840×2160 @ 60 Hz works
- 3840×2160 @ 120 Hz works and is stable
- 3840×2160 @ 160 Hz is problematic
When I select 160 Hz, the desktop becomes extremely slow/glitchy and the display configuration does not behave correctly. Returning to 120 Hz restores normal operation.
During previous attempts to use the problematic configuration, I captured the following errors:
amdgpu 0000:03:00.0: [drm] *ERROR* Unsupported screen format RA24 little-endian (0x34324152)

kwin_wayland: Atomic modeset commit failed! Invalid argument

kwin_wayland: Applying output configuration failed!

0000:03:00.0 is my RX 9070 XT, so the DRM error is associated with the discrete AMD GPU.
DisplayPort configuration
The ASUS XG27UCG offers a maximum DisplayPort setting of DisplayPort 1.4, and I currently have DP 1.4 selected in the monitor OSD.
The cable is a VESA-certified UGREEN DisplayPort 2.1 cable, advertised as UHBR10 / 40 Gbit/s and supporting DSC. It is backward-compatible with DisplayPort 1.4.
So the current connection is:
AMD Radeon RX 9070 XT
│
│ DisplayPort
▼
VESA-certified UGREEN DP 2.1 cable
│
▼
ASUS ROG Strix XG27UCG
DisplayPort 1.4 mode

I understand that the DP 2.1 cable does not make the monitor itself operate at DP 2.1. The connection should simply operate according to the DP 1.4 capability of the monitor.
During troubleshooting I discovered that the monitor had previously been configured for DisplayPort 1.2 in its OSD. I changed this to DisplayPort 1.4 and have left it there.
The 160 Hz problem, however, remained.
Troubleshooting already performed
I have already tested:
- Changing the monitor from DP 1.2 to DP 1.4
- Disabling VRR/Adaptive Sync
- Testing 8-bit color
- Testing lower refresh rates
- Using 4K 120 Hz as the stable baseline
Neither disabling VRR nor using 8-bit color solved the 160 Hz problem.
The important reproducible difference at the moment is:
3840×2160 @ 120 Hz → stable
3840×2160 @ 160 Hz → problematic

Since 4K160 has substantially higher bandwidth requirements than 4K120 over the monitor's DP 1.4 connection, I am wondering whether the transition to the higher-bandwidth mode involves DSC or another part of the AMDGPU display path that is exposing the problem.
I am not assuming DSC is the cause. I am mentioning it only because it may be one of the technical differences between the working 120 Hz configuration and the problematic 160 Hz configuration.
The Atomic modeset commit failed! Invalid argument message also makes me wonder whether this could involve the interaction between AMDGPU/DRM and KWin's atomic modesetting.
System information
OS: Arch Linux
Desktop: KDE Plasma
Display server: Wayland

GPU: AMD Radeon RX 9070 XT
GPU architecture: gfx1201
GPU PCI address: 0000:03:00.0

Monitor: ASUS ROG Strix XG27UCG
Resolution: 3840×2160
Maximum refresh rate: 160 Hz
Connection: DisplayPort
Monitor DisplayPort setting: DP 1.4

Cable:
UGREEN VESA-certified DisplayPort 2.1
UHBR10 / 40 Gbit/s
DSC support
Backward compatible with DP 1.4

My current known-good configuration is:
3840×2160 @ 120 Hz
DisplayPort 1.4

This configuration is stable.
For completeness, the monitor also supports the Dual Mode mentioned above, but again, I have not tested Dual Mode with the RX 9070 XT yet. I intend to test that separately rather than mixing the results with the current 4K160 issue.
I would appreciate any advice about additional DRM, AMDGPU or KWin debugging information I should collect while reproducing the 160 Hz problem.
In particular, I would like to determine whether this is related to AMDGPU, DSC/high-bandwidth DisplayPort operation, KWin atomic modesetting, or another part of the Linux display stack.

Lone_Wolf · Yesterday 10:26:39

Please use code /code tags for program output and list /list tags for listed outputs , see https://bbs.archlinux.org/help.php#bbcode .
Using those makes posts better readable and vastly increases the chance of getting responses .

For clarity :
Have you tested with another wayland compositor like weston or a simple X11 environment to verify if this is kde / wayland specific ?

Moderator note

I've closed and dustbinned the topic in newbie corner to avoid confusion.

Santo C01 · Today 01:34:19

Thanks, and sorry about the formatting. I’ll use the proper code and list tags for terminal output from now on.
I have not yet tested the monitor at 4K 160 Hz under another Wayland compositor or under X11. So far, all of my testing has been under KDE Plasma/KWin on Wayland.
4K 120 Hz is stable in the same configuration, while selecting 4K 160 Hz is where I encountered the modeset failure.
I’ll test 160 Hz outside KWin/Wayland next to determine whether the issue is KDE-specific or occurs at the DRM/AMDGPU level as well.

Santo C01 · Today 12:19:28

Thanks for the suggestion. I tested the issue with Weston 15.0.1 to determine whether it was specific to KDE/KWin.

The result appears to reproduce outside KWin as well.

Monitor: ASUS XG27UCG
GPU: AMD Radeon RX 9070 XT
Connection: DisplayPort 1.4
Weston: 15.0.1
KDE Plasma/Wayland is my normal environment.

First, I checked the monitor EDID. The ASUS advertises 3840x2160 at approximately 160 Hz:

DTD 1: 3840x2160 159.977477 Hz
Pixel Clock: 1420.600 MHz

H: 3840 48 32 80
V: 2160 3 5 52
HSync: +
VSync: -

Inside Weston I also checked the modes with wayland-info. Weston could see the 160 Hz mode, but the current mode remained 59.997 Hz:

name: DP-3
description: XG27UCG

3840x2160 @ 59.997 Hz
flags: current preferred

3840x2160 @ 159.977 Hz

I then tested the exact 4K160 timing advertised by the monitor using this ~/.config/weston.ini:

[output]
name=DP-3
mode=1420.600 3840 3888 3920 4000 2160 2163 2168 2220 +hsync -vsync
max-bpc=8

After starting Weston with that configuration, all displays went black.

At the same time, the kernel logged the following AMDGPU DisplayPort errors:

amdgpu 0000:03:00.0: [drm] *ERROR* dpcd_set_link_settings:1123: core_link_write_dpcd (DP_DOWNSPREAD_CTRL) failed
amdgpu 0000:03:00.0: [drm] *ERROR* dpcd_set_link_settings:1128: core_link_write_dpcd (DP_LANE_COUNT_SET) failed
amdgpu 0000:03:00.0: [drm] *ERROR* dpcd_set_link_settings:1156: core_link_write_dpcd (DP_LINK_BW_SET) failed

amdgpu 0000:03:00.0: [drm] *ERROR* dpcd_set_link_settings:1123: core_link_write_dpcd (DP_DOWNSPREAD_CTRL) failed
amdgpu 0000:03:00.0: [drm] *ERROR* dpcd_set_link_settings:1128: core_link_write_dpcd (DP_LANE_COUNT_SET) failed
amdgpu 0000:03:00.0: [drm] *ERROR* dpcd_set_link_settings:1156: core_link_write_dpcd (DP_LINK_BW_SET) failed

The errors repeated several times, and Weston then crashed:

systemd-coredump: Process (weston) of user 1000 dumped core.

#5  libweston-15.so.0
#6  drm-backend.so
#7  drm-backend.so
#8  drmHandleEvent (libdrm.so.2)
#9  drm-backend.so

I removed the custom weston.ini and logged into Weston again. Weston then started normally and all displays worked again.

I also rebooted afterward to make sure the system returned to its normal state. The fresh boot has no failed systemd units:

$ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

The AMDGPU DPCD/link-setting errors are also absent on the clean boot.

So at this point the behavior I see is:

KDE/KWin: selecting 3840x2160 @ 159.98 Hz is rejected.
Weston default configuration: works normally.
Weston sees 3840x2160 @ 159.977 Hz as an available mode.
Weston forced to the monitor's 4K160 EDID timing: displays go black and AMDGPU reports DPCD/link-setting failures.
Removing the forced Weston configuration restores normal operation.

This seems to reproduce the problem outside KDE/KWin and appears to fail while the AMDGPU driver is configuring the DisplayPort link.

Would the next useful step be to collect additional AMDGPU/DC or DisplayPort link-training debug information when attempting the 160 Hz mode?

Santo C01 · Today 12:31:34

One additional observation:

I also tested the ASUS XG27UCG Dual Mode after these tests. Dual Mode switches the monitor to 1920x1080 at approximately 320 Hz.

ASUS XG27UCG
Dual Mode: 1920x1080 @ 320 Hz

I switched into and out of Dual Mode several times under Plasma. 320 Hz worked normally with no visible glitching, and all displays recovered correctly.

During these transitions I did not see the DPCD/link-setting errors that occurred when attempting 3840x2160 @ 160 Hz.

I only saw some transient PowerDevil/DDC read errors:

org_kde_powerdevil: (i2c_ioctl_reader1) Error in ioctl() read, rc=-1

On one transition back from Dual Mode, AMDGPU also reported:

amdgpu 0000:03:00.0: Failed to upload overdrive table, ret:-5
amdgpu 0000:03:00.0: Invalid overdrive table content: OD_UNSUPPORTED_FEATURE (2)
amdgpu 0000:03:00.0: Failed to upload overdrive table!

That Overdrive error did not repeat on the following Dual Mode test.

I mention this because the GPU/monitor combination appears able to handle 1920x1080 @ 320 Hz and repeated display-mode transitions. So the failure seems more specific to the 3840x2160 @ 160 Hz DisplayPort configuration rather than high refresh rates in general.

Lone_Wolf · Today 14:39:53

It's the DP configuration .

https://en.wikipedia.org/wiki/DisplayPo … ncy_limits shows for 3840x2160@160 you need

UHBR10 with 8 bit color mode
UHBR13.5 with 10 bit color bit mode

Both are only available with DP 2.0+ , HBR3 is the best possible with DP 1.4 and that is limited to 120 Hz for your resolution .
Monitor specs indicate it also supports HDM 2.1 and that may allow 3840x2160@160 .

Arch Linux

#1 Yesterday 02:22:05

RX 9070 XT + KDE Wayland: 4K 160 Hz fails on DP 1.4, 4K 120 Hz works

#2 Yesterday 10:26:39

Re: RX 9070 XT + KDE Wayland: 4K 160 Hz fails on DP 1.4, 4K 120 Hz works

#3 Today 01:34:19

Re: RX 9070 XT + KDE Wayland: 4K 160 Hz fails on DP 1.4, 4K 120 Hz works

#4 Today 12:19:28

Re: RX 9070 XT + KDE Wayland: 4K 160 Hz fails on DP 1.4, 4K 120 Hz works

#5 Today 12:31:34

Re: RX 9070 XT + KDE Wayland: 4K 160 Hz fails on DP 1.4, 4K 120 Hz works

#6 Today 14:39:53

Re: RX 9070 XT + KDE Wayland: 4K 160 Hz fails on DP 1.4, 4K 120 Hz works

Board footer