I disabled dithering on Apple silicon + Introducing Stillcolor macOS M1/M2/M3
- Edited
That could be it. Here is what the recorder looks like under display settings in w11.
Went to an Apple Store today. It seemed I could handle the airs, but not the pro’s. Also, the studio display with nano was better than the one without, but the Pro Display XDR was very comfortable, despite still having pwm according to this interesting data sheet:
https://www.apple.com/pro-display-xdr/pdf/Pro_Display_White_Paper_Feb_2020.pdf
- Edited
Ruoma I'm vaguely aware of the information in that data sheet. In addition I don't think I've seen anyone attempt to measure the Pro Display XDR with an oscilloscope. Rather curious what it "looks like".
There are Apple store(s) near me but I don't recall if they have the Pro Display XDR on display and considering my oscilloscope and diode are somewhat bulky and require AC power that might be a problem lol.
photon78s Interestingly, when I enabled 8 bit temporal dithering in colorControl, I am able to recording the the snow like dithering and no dithering when I use colorControl setting to disable dithering . This confirms that colorControl software is working at least to some extend. With the elgato card, colorControl seems to reduce the dithering not completely remove it.
This does make it sound like the Blackmagic is performing correctly. And that the Elgato is also performing correctly in terms of temporal dithering, but has introducing some other form of unrelated noise to every recording. Is it safe to assume the Elgato noise is unrelated, or would we expect to also see that noise on the Blackmagic? I'm unfortunately not very useful on the Windows side of things.
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.