I’m posting this because I went down a long rabbit hole getting an Apple Studio Display working properly at native 5K on Linux. Hopefully this helps the next person searching for “Apple Studio Display Linux flicker”, “5K flickering”, “Studio Display black screen Linux”, “MacBookPro16,1 external display flicker”, “AMD DSC flicker”, etc.
Hardware / Software
Machine:
- Apple MacBook Pro 16-inch 2019
- Model: MacBookPro16,1
- CPU: Intel Core i9-9980HK, 8 cores / 16 threads
- RAM: 64 GB
- GPU: AMD Navi 14 / Radeon Pro 5500M family
- T2 Mac
- Thunderbolt controller: Intel Titan Ridge Thunderbolt 3
- OS: CachyOS / Arch-based Linux
- Kernel tested: 6.18.28-1-cachyos-lts
- Desktop: KDE Plasma on Wayland
- Display: Apple Studio Display 27-inch 5K over Thunderbolt/USB-C
Symptoms
The Apple Studio Display was detected and could run at native 5120x2880@60, but the picture flickered/glitched badly. Sometimes it would black out. The problem was specific to native 5K. Dropping the display to 3840x2160@60 made it stable.
USB features like audio/camera could work separately after Thunderbolt authorization, so this was not simply “the whole display is unsupported”. The display transport itself was the issue.
Things that did not fix it
I tried a lot before finding the actual problem:
- RGB range Full vs Automatic
- 8 bpc instead of automatic/higher color depth
- EDID color profile vs sRGB
- KDE color power settings
- Native 5K lower refresh EDID overrides, including 30/40/48 Hz
- Cloning/importing a known-good older Studio Display EDID
- Disabling the phantom/tiled secondary output
- Checking for kernel/Thunderbolt disconnects
- Running 4K safe mode
- Checking whether audio/camera caused it
Important observations:
- 3840x2160@60 was stable.
- 5120x2880@60 using the normal KDE mode flickered.
- Custom lower refresh 5K modes sometimes displayed briefly, but eventually blacked out.
- Kernel logs often stayed quiet, so it did not look like a full Thunderbolt disconnect.
- The display exposes two DisplayPort-ish outputs on Linux. On my system:
- DP-2 was the main usable output.
- DP-1 was the second tile/phantom output and was disabled.
The key discovery
The issue was the DisplayPort link training / DSC path.
At stable 4K, debugfs showed something like:
Current: 4 0x14 0
dsc_clock_en=0
dsc_bits_per_pixel=0
At default native 5K, KDE selected 5120x2880@60, but debugfs showed DSC was enabled:
Current: 4 0x14 0
dsc_clock_en=1
dsc_bits_per_pixel=256
So the bad path was:
HBR2 + DSC = flicker/glitch/black screen
Then I forced the DisplayPort link to HBR3 before selecting 5K:
sudo sh -c ‘echo “4 0x1e” > /sys/kernel/debug/dri/0000:03:00.0/DP-2/link_settings’
After that, switching to native 5K worked, and debugfs showed:
Current: 4 0x1e 0
Preferred: 4 0x1e 0
dsc_clock_en=0
dsc_bits_per_pixel=0
max_bpc=8
So the working path is:
HBR3 + no DSC = stable native 5K
Manual fix
Your connector path may differ, so first inspect:
sudo find /sys/kernel/debug/dri -path ‘DP-/link_settings’ -print
For me the useful one was:
/sys/kernel/debug/dri/0000:03:00.0/DP-2/link_settings
Force HBR3:
sudo sh -c ‘echo “4 0x1e” > /sys/kernel/debug/dri/0000:03:00.0/DP-2/link_settings’
Then check KDE output IDs/modes:
kscreen-doctor -o
On my system:
- DP-2 mode 18 = 5120x2880@60
- DP-2 mode 19 = 3840x2160@60
- DP-1 should be disabled
- eDP-1 can be disabled for external-only/clamshell use
Apply native 5K:
kscreen-doctor
output.DP-2.enable
output.DP-2.mode.18
output.DP-2.scale.2
output.DP-2.position.0,0
output.DP-1.disable
output.eDP-1.disable
Fallback to stable 4K:
kscreen-doctor
output.DP-2.enable
output.DP-2.mode.19
output.DP-2.scale.1.5
output.DP-2.position.0,0
output.DP-1.disable
output.eDP-1.disable
Persistent workaround
Since debugfs link settings are runtime state, they will not reliably survive reboot/replug. I made a root systemd service that continuously keeps the Studio Display’s DP link forced to HBR3.
Example root script:
#!/usr/bin/env bash
set -euo pipefail
while true; do
for d in /sys/kernel/debug/dri/*/DP-2; do
[ -e “$d/link_settings” ] || continue
echo “4 0x1e” > “$d/link_settings” 2>/dev/null || true
break
done
sleep 1
done
Install it as:
sudo install -m 755 studio-display-hbr3-link-watch.sh /usr/local/bin/studio-display-hbr3-link-watch.sh
Systemd unit:
[Unit]
Description=Force Apple Studio Display DP-2 link to HBR3
After=sys-kernel-debug.mount multi-user.target
RequiresMountsFor=/sys/kernel/debug
[Service]
Type=simple
ExecStart=/usr/local/bin/studio-display-hbr3-link-watch.sh
Restart=always
RestartSec=2
[Install]
WantedBy=multi-user.target
Enable it:
sudo systemctl daemon-reload
sudo systemctl enable --now studio-display-hbr3-link-watch.service
Then use a user-session script after login/plug-in to apply the KDE layout:
#!/usr/bin/env bash
set -euo pipefail
export XDG_RUNTIME_DIR=“${XDG_RUNTIME_DIR:-/run/user/$(id -u)}”
export WAYLAND_DISPLAY=“${WAYLAND_DISPLAY:-wayland-0}”
kscreen-doctor
output.DP-2.enable
output.DP-2.mode.18
output.DP-2.scale.2
output.DP-2.position.0,0
output.DP-1.disable
output.eDP-1.disable
You can run that manually, from KDE autostart, or from a user systemd service after login.
Current working setup
After forcing HBR3 first, my Studio Display is running:
5120x2880@60
scale 2
8 bpc
DP-1 disabled
internal panel disabled
HBR3 active
DSC off
Debugfs confirms:
Current: 4 0x1e 0
Preferred: 4 0x1e 0
dsc_clock_en=0
dsc_bits_per_pixel=0
max_bpc=8
The Studio Display camera still works. Audio/microphone also work after Thunderbolt/USB authorization.
Conclusion
If your Apple Studio Display flickers at native 5K on Linux, don’t only chase EDID, cables, color depth, KDE settings, or refresh rate. Check whether the kernel/GPU is choosing a DSC path.
In my case:
Default 5K = HBR2 + DSC = broken
Forced HBR3 = no DSC = working native 5K
The fix was forcing the DP link to HBR3 before applying the native 5K mode.