Major Findings on eDP Timing Controllers (TCONs) used by Apple
Parade Technologies is a Taiwan-based semiconducter developer that has been supplying Apple with eDP TCON, USB, HDMI components for close to 15 years or longer.
I've scoured the web and compiled a partial list of eDP TCONs used in Macs and iPads
Check it out here https://gist.github.com/aiaf/f26345f72b4756d5940dc54f41229ed3
Of note is that Apple often uses customized versions of off-the-shelf TCONs like the DP627HDE used in 2012 and 2015 iMacs, which is based on DP672. And DP665 used in 2017 & 2014 iMacs which is likely a customized version of DP663.
You can check which TCON your M-series Mac likely uses by running ioreg -lw0 | grep TCON
My M3 Max 16" returns a hit for AppleParadeDP855TCON
I don't know what kind of TCONs vanilla suffix-less M1 MacBooks use. Mac minis obviously do not use eDP TCONs because they do not have built-in displays.
What to make of this?
- All of the eDP TCONs on Parade's website feature FRC support
- None of the eDP TCONs have support for 10-bit panels (in the spec sheets you'll see it as "Supports COG /COF 6/8 color depth"
- None of Parade's Source Drivers have support for anything over 8-bit, if we assume Apple uses those too.
- Max input to some of these TCONs is 30-bit, most are 24-bit.
I've concluded that the DP855 used in M1 iMacs, M1 Pro/Max, and probably all M2 and M3 MacBooks is a customized version DP808 which features HB3 link rates, and the closest resolution and refresh rate support.
The DP808 was introduced in July 2020 and notably only supports 120Hz at 24-bit input color depth. Is this the reason ProMotion is not always in effect as reported by some users? And is this the reason for DCP dithering?
So it is very highly likely, I'd say with 95% confidence that none of Apple's devices have native 10-bit panels.
The Good News
We now at least have the comfort of knowing that Mac built-in panels are at most 8-bit+FRC (some could be 8-bit only, or 6-bit+FRC)
On the newer TCONs, like the DP808, Parade says "Stores LUT contents in EEPROM to support Gamma Correction, Color Engine, and FRC".
Let's see what the IO Registry tells us about our TCON
This EEPROM can possibly be read and modified by newly discovered IOAVDisplayMemory private methods in IOKit such as IOAVDisplayMemoryRead and IOAVDisplayMemoryWrite. Or by possibly using/modifying the driver code somehow.
Edit: this EEPROM is likely the reason screen swaps show shadowy artifacts and disable True Tone. These can be fixed using Apple's System Configurator which probably directly modifies the TCON's memory https://www.ifixit.com/News/73288/m2-macbook-pro-screen-swaps-are-kinda-haunted
The Bad News
This is hard and time consuming reverse engineering work, and whether it's easily or doable at all from user space remains to be known. I don't think I have the bandwidth to pursue this.
The easier and more logical path is to force a 24-bit to the TCON.
Configuring eDP
Thanks to @waydabber 's hints, it turned out the IOKit exposes a large number of private IODP* methods which allow DisplayPort configuration from user space.
I managed to reverse engineer a few and was able to limit the number of eDP lanes to the embedded display from 4 to 3/2/1. Managed to also limit the link rate to HBR and HBR2.
Limiting link rate had the effect of cutting off colors to the screen (I could still see brightness from various elements and the mouse). It's almost like a brightness mode. Using unconventional values leads to DCP panic and laptop restarting panic(cpu 0 caller 0xfffffe002007be18): DCP PANIC - ASSERT!AppleDCPLPDPTXPort.cpp:2130 unsupported link rate: 13500000000 - dcpdp-controller-epic(35)
Limiting number of lanes made the colors glitch and behave erratically.
This all suggest that the input was still at 10-bit and that changing transmission bandwidth at such a low level did not trigger any kind of event that negotiated color depth.
There's still a lot of work to do.
I will share code and media later.
Note that none of this is related to DCP dithering. That is 100% a real thing and has nothing to do with TCON FRC.
I've also discovered a new method in IOKit to control dithering _IOAVVideoInterfaceSetColorDitherRemoval which also returned unsupported function. This is likely the top-most abstraction to toggle enableDither.
