I disabled dithering on Apple silicon + Introducing Stillcolor macOS M1/M2/M3
DisplaysShouldNotBeTVs But when Stillcolor is on, it's been verified through a capture card that as long as the monitor itself truly flicker-free (as in true 8-bit with no FRC on the monitor's side either, not just PWM-free), the display output will be totally still.
I wonder if this conclusion may be premature, since the capture itself was reportedly at 10-bit color, whereas the vast majority of monitors are no more than native 8-bit. This seems to be a factor we cannot ignore. I would be willing (even happy) to be proven wrong.
On another note, the ability to force an arbitrary color depth on macOS would be huge. My desktop monitors are all 6-bit + FRC, but I would be perfectly happy with a stable 6-bit image with none of these games macOS is playing. The most comfortable screen I’ve looked at in a while was an older HP Windows 10 laptop with a 6-bit screen.
- Edited
I just tested the mac mini again with the blackmagic recorder (bmd) and I can confirm it is now recording the expected dithering and no dithering when stillcolor is activated. Seems like on that PC with windows 11 their are some extra factors I'm missing. The elgato is missing technical documentation or I could not yet find any on the possible addition of noise or something like compression artifacts to recordings.
Update: I made sure to record set the pixel format to 8 bit uncompressed YUV for the bmd and stillcolor still works to enable/disable dithering.
- Edited
Got instant front temple ache when I tested the high bandwidth usb-c to displayport cable just to make sure the thunderbolt ports are working on this used mini. Now using the bandwidth limited HSwE cable I can only run at 30hz on the 144Hz Lg. With stillcolor on I still see some kind of mirage/shimmer effect. Maybe the inversion or just me being tired lol (and recovering from the 10 bit eizo) Time will tell.
The monitor is 8 bit + FRC with HDMI "deep color" turned off. I haven't been using this monitor for couple weeks so maybe I have to adapt to it.
I don't have the 10 bit eizo anymore. Couldn't stand a single day of usage unfortunately and I think not due to dithering.
- Edited
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.
- Edited
This is only day two of using the mac running sonoma 14.4 connected to LG with HDMI deep color disabled on the monitor side. I will also avoid using any high bandwidth cables. Quite comfortable. If you are going to try this, probably avoid the "redwoods from above" wallpaper. Just use the default wallpaper (sonoma horizon) and also use apps that have mostly pure white background (like document apps and foobar2000 music player) to be even more safe. Even with stillColor disabled, their is no dithering visible using the capture card method in the pure white background of those apps.
I think a 8 bit or 10 bit non frc combined with high refresh rate could be ideal.
Thank you aiaf and others contributing to this discussion! Super technical and super educational.
aiaf Super interesting. You really pushed this into new territory for everyone. Awesome work. Even if it stops at some dead end this is quickly approaching a point where people can decide to team up and put money in some pool for whoever has the right skillset and time. The important part is figuring out what should be done and where. Everything else is just resource allocation 
Guess one of the bigger risks is if Apple decided that exposing access to some of these methods can cause warranty issues or hardware damage if it gets widespread adoption, and simply patches them up like jailbreaking. But then again widespread adoption might be the best way to make it an issue that can't be ignored anymore.
- Edited
languidicity My hypothesis based on Blooey's test image is that the MBA screens are native 8 bit with no FRC with dithering solely done by the GPU.
(Based on a separate observation, I believe the TCON applies a gamma/color correction curve post-dither, but may or may not do any additional dither on these machines.)
I realized last night that I now have a camera that can do high-speed (240Hz) capture, so I'm going to try to take some recordings of the screen this weekend to try to validate these hypotheses.
Awesome answer, thank you. Whatever happens and wherever all of this goes I would like to echo the sentiment of others and also thank you and everyone else in this thread and on this forum - not least of course @aiaf - for all of this progress. The knowledge, insight and remarkably convivial, collaborative approach on display here (pun intended!) is truly exceptional.
- Edited
aiaf Awesome. It really was too much of a mind bender trying to work out both 10-bit and 8-bit possibilities. I see what you mean about the TCON only supporting 8-bit output. The marketing for the DP808 says:
it supports 30-bit input and global dimming for DisplayHDR 400 performance
And the VESA Certification for DisplayHDR 400 says:
True 8-bit image quality – on par with top 15% of PC displays today
One thing that gives me encouragement regarding Apple perhaps 'locking out' these workarounds at some point is that even though things seem to be more stringent than years ago macOS, unlike iOS, is obviously still a full desktop OS that's way more open/configurable with precedent already set in the Apple Silicon era by apps that expose or modify low level OS stuff like modifying battery charging behaviour, overriding the maximum SDR brightness on MacBook Pro's (which is potentially far more of a 'risk' from a warranty POV than disabling dithering surely?), etc. It's not quite the same thing but I use Loopback to override or 'hijack' CoreAudio for my music production - or at least I did when I had a Macbook 
All of this is permitted by Apple as these apps have been around for years at this point. I think there's plenty of reason for hope.
aiaf Amazing!
It would be great to figure out how to affect the negotiation itself. If you do a modeswitch (on liquid retine displays this can actually happen only when there is a refresh rate change as there is only the native resolution, every resolution alternative is scaled) the values return to default? Modifying these on-the-fly probably affects the process that creates color data from the framebuffer but without the connection renegotiated it seemingly just results in erroneous data to be produced (that's why the color artifacts).
I am not sure how the color/gamma/calibration correction LUT looks like in the TCON's memory - but if the table can map any input color data to levels that require FRC to produce on the panel, limiting the bandwidth and forcing a lower connection color depth won't actually help that much - so reading, understanding and changing the LUT might not be something that can be avoided for the proper results. It might be good to consider that changing the LUT might be a bit risky business and one that I think Apple should not actually allow from user space to happen (it could be regarded as a security risk as a malicious software could actually semi-brick the display) - so if it is possible now, as the practice might get widely known, Apple might block it in the future (as this happened with some of similar exploits in the past).
- Edited
Blooey the fun part is that the only time Apple ever mentions VESA is in the marketing for the Pro Display XDR VESA Mount. Otherwise I don't think they particularly care about complying with VESA. They spec their displays to their own standards with their own marketing lingo.
waydabber I tried changing the refresh rate while in "2-lane eDP mode", and the image corrected itself back to full bandwidth. So that apparently doesn't work. Perhaps if we can patch _IOAVVideoColorBitDepth to always return 1 (IOKit's enum for 8bpc) and patch _IOAVVideoColorBitDepthScalar to return 8 for 2 (enum for 10bpc), these might force anything else that uses these internally to use 8 bits.
Re. LUT, well the TCON's logic can be as simple as if 24-bit signal detected -> skip FRC module. Additionally, the LUT can be as simple as an array of <= 1024 0/1 values for each RGB channel to decide whether or not to dither on a particular sub-pixel value. Or it could be a type of bit template. I think we'll find out soon, and it will give us a hint about how these particular FRC algos works. Did you have success rounding the pixel buffer's 10-bit colors to 8 bits?
Edit: if the FRC algo has a spatial dithering step that works on the average of values of a cluster of pixels, let's say on a 4x4 square, then I don't think rounding down 10-bit colors to 8 bits (inside a 10-bit container) will help much, unless you have large areas of single colors that don't change frame to frame.
I 100% agree about touching the TCON. This is why I don't want to deal with EEPROM. Risk of bricking the display is very real.