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.
