Stop the Apple Studio Display flickering at 5K on T2 Macs - #9796
Open
phedoreanu wants to merge 2 commits into
Open
Stop the Apple Studio Display flickering at 5K on T2 Macs#9796phedoreanu wants to merge 2 commits into
phedoreanu wants to merge 2 commits into
Conversation
The display advertises an HBR2 DisplayPort link through its Thunderbolt tunnel. 5120x2880@60 does not fit HBR2 uncompressed, so amdgpu turns on DSC, and that path flickers, glitches and blacks out on the Radeon Pro in T2 MacBooks. The panel trains fine at HBR3, where 5K needs no compression. omarchy-hw-apple-display-link pins HBR3 on every connector whose EDID names a Studio Display, through amdgpu's debugfs link_settings, and simulates a replug when the compositor had already lit the panel over the compressed link. A oneshot service runs it at boot and a udev rule on every DRM hotplug. The T2 setup installs both; a migration covers existing installs.
When the Studio Display comes back through Thunderbolt, udev raises several DRM change events within a few milliseconds and each one starts the service. The early runs find the connector not yet connected and exit at once, and after five of them systemd's default start rate limit blocks the later ones, which are exactly the runs that would have pinned the link. The display then stays on the compressed HBR2 link and flickers. Seen on a MacBookPro16,1 after a resume. Turn the rate limit off; the script is idempotent and cheap.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Plug an Apple Studio Display into a T2 MacBook Pro with the Radeon Pro (a MacBookPro16,1 here) and it comes up at 5120x2880@60, then flickers, glitches and periodically blacks out. 3840x2160 is stable.
The display advertises an HBR2 DisplayPort link through its Thunderbolt tunnel (
Reported: 4 0x14in amdgpu's debugfs). 5K@60 does not fit HBR2 uncompressed, so amdgpu enables DSC, and that HBR2+DSC path is what glitches:dsc_clock_enis 1 while it flickers. The panel trains fine at HBR3, where 5K needs no compression. Someone hit the same thing on the same machine and worked it out first: https://discuss.cachyos.org/t/29495Fix
omarchy-hw-apple-display-linklooks for connected connectors whose EDID names a StudioDisplay and writes4 0x1eto that connector'slink_settingsin debugfs, which retrains the link at HBR3 right away. If the compositor had already set the 5K mode over the compressed link, it simulates a replug throughtrigger_hotplugso the mode gets set again over the new link. The preferred rate sticks to the connector until reboot, so it survives replugs and suspend.A oneshot service runs the helper at boot and a udev rule starts it on every DRM hotplug.
fix-t2.shinstalls both on new T2 installs and a migration installs them on existing ones. The helper does nothing without a Studio Display and skips connectors that have no amdgpu debugfs files, so it is inert on other GPUs and other displays.Verified
On the MacBookPro16,1:
Current: 4 0x1e,dsc_clock_en0, 5120x2880@60 with no flicker since. Putting the link back to HBR2 with DSC on and firing a real hotplug throughtrigger_hotplughad udev start the service and land the display on HBR3 without DSC. Simulated unplug/replug and a suspend cycle kept the preference. Camera, speakers, microphone and brightness throughomarchy brightness displaykeep working.test/shell.d/apple-display-link-test.shruns the helper against a fake sysfs and debugfs tree (pins only connected Studio Displays, leaves other monitors and internal panels alone, replugs only a stream that stayed compressed) and the migration with stubbedlspci,sudo,systemctlandudevadm(installs, idempotent, skips non-T2)../test/cliandtest/shell.d/t2-hardware-test.shpass.