I disabled dithering on Apple silicon + Introducing Stillcolor macOS M1/M2/M3
- Edited
Ok here is another crazy idea
What if we try to replace the T-con with a different model T-con:
https://www.ifixit.com/Answers/View/627705/Can+I+repair+T-CON+Board
- Edited
Unfortunately, those instructions for Intel Macs don't work.
I get:
Error setting variable - 'boot-args': (iokit/common) not permitted.
I'm wondering if Stillcolor would work there instead.
P.S. Read elsewhere that disabling system integrity protection can do it, so I shouldn't need Stillcolor. But 'll leave this up in case someone else has the same problem.
- Edited
Ananiujitha for dither=0 you have to do it after booting into recovery mode terminal
although dither=0 has varying effects on different Intel macs…
here's my experience with it:
- 2015 MacBook 12-inch (Mojave 10.14.6, Intel HD): Best effect, it seems to have fully and successfully disabled dithering, internal screen feels still now. This screen was already pretty usable compared to other Macs, but still used to have some text shimmer — but now, it's noticeably better and the most comfortable it's ever been.
- 2015 Retina MacBook Pro 15-inch (Monterey 12.6.8, Intel Iris integrated graphics mode): It seemed to disable additional dithering on color profiles and gamma table adjustments (adjusting Software Brightness in BetterDisplay now introduces banding, which it didn't before) but didn't seem to actually fully disable it. Still looks like solid color backgrounds are moving and text is shimmering. Disappointing
- 2018 Retina MacBook Air 13-inch (Mojave 10.14.6, Intel UHD): Did not work at ALL, the log says "dither disabled" but there is no banding even when changing Software Brightness implying that dithering wasn't actually disabled (because it's still obviously showing in-between colors more precisely than the screen is capable of, even when trying to reduce color range by lowering color table brightness.) Screen feels exactly the same with an extreme amount of shimmer
(However, the 2018 Air screen can actually become fully usable with Windows and older display drivers, implying that this is still a problem at the software level, not the screen just being a low quality panel. But unfortunately, dither=0 does not make it any better while on macOS, even on an old version like Mojave)
Thanks.
log show --predicate "processID == 0" | grep Dither
shows that neither setting dither=0 nor enableDither=0 will turn off dithering. So Stillcolor support for Intel Macs may still help.
Dropping this here, as it was a good overview on how to help out exploring the private apis that might be relevant
https://www.jviotti.com/2023/11/20/exploring-macos-private-frameworks.html
@aiaf Did you explore /dyld-cache-arm64e/usr/lib/updaters/libAppleTCONUpdater.dylib?
I'm way out of my league here as I don't have any swift / c background, so I don't know how easy it is to work out and use functions from dylib stuff. Seems to be quite a few functions to read and set options on AppleParadeDP855TCON. I guess in theory it should be configurable where some things can be turned off for debugging, without having to reflash the entire thing?
- Edited
Blooey In case it's helpful, I took a couple of pictures this morning to show the effect of Stillcolor on my MBA M2 15-inch using your test pattern: https://imgur.com/a/uIge5kx
(Ignore the haloing around the white text… that's a demosaicing artifact from my camera.)
Given how strong the banding effect is at 9-bit, 10-bit, etc. with dither OFF, I think it's fairly likely that Stillcolor turns off both GPU and TCON dither (that's assuming there is normally any TCON dither in addition to GPU dither, which I'm not sure there is).
There is a well-known bug in Apple Silicon power management that would probably allow us to investigate whether there is normally any TCON dither; I'll make a post about that in a bit.
- Edited
async just last night actually! I came across it and and an AppleDisplayTCONControl
private framework! Absolute treasure trove!
libAppleTCONUpdater.dylib
This seems to be the kernel code responsible for updating the TCON's firmware either through system software updates or perhaps using the Apple System Configurator. In theory if Apple wanted to turn off TCON dithering they can do so overnight via a software update.
It uses IOAVDisplayMemoryRead
and IOAVDisplayMemoryWrite
heavily. If the TCON firmware is not cryptographically locked down we should in theory be able to reverse engineer this code and write to the device's memory. But we're gonna require Asahi-level reverse engineering chops.
There's functionally different code for handling DP835 (possibly the base M1 TCON model), and DP855.
AppleDisplayTCONControl
At first glance, this private framework is less write-heavy and seems more about dumping data, generating reports and diagnostics. But we have our first confirmed hit of a dithering LUT!
"TCON_LOAD_DITHERLUT"
A debugging string probably used right before loading this particular LUT. There are references to many other LUTs too:
PG LUT
, SCALER LUT
, DEGAMMA LUT
, ENGAMMA LUT
, WPC LUT
, PRC LUT
, IBC LUT
, TRINITY LUT
, CABAL LUT
, BL CAL LUT
, BRIGHTNESS LUT
, KSF COMP LUT
It appears that several of the IOMobileFramebuffer
properties we've seen affect the TCON directly. Most notably PCC*
and APT*
(Apple TCON / Apple Parade TCON?) props.
There are also references to EDID and DisplayPort stuff.
I'm gonna spend some time trying to extract these LUTs and see if this helps us progress.
Here is the ioreg for the M1 Air.
"AppleParadeDP835TCONI2CPLS"=0,
"AppleParadeDP835TCON"=0,
“AppleParadeDP835TCONI2CTps65177"=0,
"AppleParadeDP835TCONI2C"=0,
"AppleParadeDP815TCON"=0,
"AppleParadeDP855TCON"=1,
Thanks for the great work. Makes my Macbook usable at last.