I disabled dithering on Apple silicon + Introducing Stillcolor macOS M1/M2/M3

WhisperingWind

Interesting point! I think we might be talking about different components - you're talking about the ISP and camera, I'm talking about the display pipeline. "Quadra Bayer" might be the same name used for different purposes in different hardware blocks. According to the Asahi Linux firmware overview, the ISP is a separate coprocessor, while the scaler appears to be part of the DCP.

On a related note, looking at AppleM2ScalerCSCDriver::start(), the log strings like "[IOSA][Boot ] MSR Driver Waiting for IOSurfaceRoot" suggest that MSR stands for hardware blocks, each implementing a different dithering algorithm. The driver waits for IOSurfaceRoot at boot, which further ties it to the display pipeline.

I think the Quadra Bayer dithering algorithm, in the case of the scaler, could be used for handling 2x2 blocks from the ISP and repacking them for display (whatever that means) - the IOSurfaceAcceleratorCapabilitiesQuadraBayerRepacking property in the code hints at this - but I haven't dug that deep.

xenu

WhisperingWind
Here's what Venice.ai says about the terminology from the log message "[IOSA][Boot ] MSR Driver Waiting for IOSurfaceRoot" , which seems to pertain to memory shared between CPU and GPU:

IOSA: Stands for IOSurface Accelerator, which is part of macOS's graphics framework
MSR Driver: This is the Memory Status Register driver, which handles certain hardware-level operations
IOSurfaceRoot: This is a core service in macOS that manages surface buffers (used for graphics rendering, video playback, etc.)

Regarding the Bayer sensor, converting to RGB involves a spatial operation called demosaicing, but I suspect the dithering was for temporal changes i.e. to smooth out sudden changes. That's my guess based on a Chinese patent I found last week.

WhisperingWind

The TCON firmware update process is designed so that before flashing the chip, the system requests a personal "ticket" from Apple's servers. This ticket is cryptographically tied to a specific chip instance and to the hash of the firmware's executable code. If the executable code is modified, its hash changes - and the server will simply refuse to issue a ticket, returning an error. In other words, Apple maintains a database of original hashes for the executable portion of the firmware, and without signed authorization, flashing the chip won't work. The question is at what level this protection is implemented - software, hardware?

Before going through authorization, I created an XML document specifying the hardware parameters (like marcan did, but with my own device's parameters) and the hash of the firmware's executable code. Then I sent the request using the cURL utility, including this XML document in it:

curl -X POST -H "Content-Type: application/xml" --data-binary @auth_request.xml "https://gs.apple.com/TSS/controller?action=2"

The server responded with a ticket. Meaning, success.

Then I changed a single character in the firmware executable code hash (simulating the fact that if the firmware executable code changes, its hash changes too) and resubmitted the request. This time I got the error:

STATUS=94&MESSAGE=This device isn't eligible for the requested build.

Modifications are rejected. It’s a brick wall.

I specifically said "firmware executable code" for a reason - what gets flashed to the TCON isn't just the executable code. The update file that Apple provides also contains configuration settings and LUTs. They are located in separate sections and have their own hashes (perhaps Apple doesn't track changes to them).

In the end, we're left with a lot of "ifs": if the FRC table is in the LUT section, if it can be tweaked to disable FRC, and if libAppleTCONUpdater.dylib will then allow it all to be flashed to the TCON.

libAppleTCONUpdater.dylib

This library is designed for flashing the TCON and features an AppleTCONUpdaterExecCommand function. There is no documentation for the API provided by the library. It had to be reverse-engineered.

At the first stage, the 'queryInfo' command is used to return the data required to obtain a ticket. In the second stage, using the 'performNextStage' command, the function must be passed the firmware file contents and the ticket. And this is the stage where the chip flashing is supposed to occur.

Newscreensarehorrible

WhisperingWind Awesome information.

macsforme

WhisperingWind Based on this information, do you suspect that the display TCON firmware is not downgraded during a DFU restore/revive of the machine? This might explain irreversible strain after an upgrade, notwithstanding a DFU downgrade

Edit: Related question, any idea if older TCON firmware versions are still signed and possible to restore, independent of the OS version?

xenu

I got my Linux box to read IMG4 files, using the img4tool which is here: https://github.com/tihmstar/img4tool.git
Compiling that requires also compiling maybe 4 dependencies that are in his repo.
Looking in the Universal_Mac_26.5_25F71's directory Firmware/dcp, I tried a random driver file t8142dcp_restore.im4p, which is for the M5's DCP.
Saving the payload and running strings on it, I see things like:
iomfb_RuntimeProperty_enableDither enableDither ColorDitherRemovalSupport ColorDitherRemoval SetColorDitherRemoval

This suggests that enableDither should be functional on the M5 Macs.

xenu

@aiaf Looking in the driver files, I see these runtime options:

iomfb_RuntimeProperty_enablePulseWidthMaximization
iomfb_RuntimeProperty_pixelBacklightModulationForceState
iomfb_RuntimeProperty_requestPixelBacklightModulation

Has anyone tried altering these to see what happens e.g. on the Macbook Pro's that have PWM?

Of the 270 iomfb runtime options that I found, I do see some that might possibly be related to FRC, like:

iomfb_RuntimeProperty_supportHDR
iomfb_RuntimeProperty_maxAvgBpp
iomfb_RuntimeProperty_maxPeakBpp
iomfb_RuntimeProperty_wideGamutPassthrough
iomfb_RuntimeProperty_disableDisplayOptimize

Here's a curious warning message:
"Timing only possible with DSC + fractional bpp"
An LLM says DSC is Display Stream Compression.

Some folks complain that the contrast of the Macbook displays is too intense. These might be relevant:

iomfb_RuntimeProperty_contrastEnhancerCorrectionFactor
iomfb_RuntimeProperty_contrastEnhancerStrength

AshX

macsforme

Revive will not always restore the firmware. DFU restore (hard drive is wiped) is the only way to ensure you get a full firmware + OS restore. I highly doubt there is an irreversible change. The only times I see an older OS with a newer firmware version is:

DFU revive
Downgrading OS without an IPSW file aka via a regular downloaded
Installing a newer “security update” version of an older OS, which will always be packaged with the current firmware in the latest version of MacOS at the time of that security update’s release

#3 is why if you pull up System Information you’ll see a lot of people running the latest version of Sequoia, but they’re running MacOS Tahoe’s firmware. This also can occur if you have 2 versions of MacOS installed on the same hard drive/system. However, a lot of people who had strain on Tahoe resolved it downgrading to Sequoia or Sonoma without going through the IPSW process.

Regarding the MiniLED Macs, they’re going to have way more compensatory mechanisms compared to an Air or the M1/M2 Retina Macs. That display panel is far more complex than the other LCDs, so I’m sure there are going to be more opportunities for something to “go wrong” compared to the regular Liquid Retina panels.

WhisperingWind

macsforme

Based on this information, do you suspect that the display TCON firmware is not downgraded during a DFU restore/revive of the machine?

I came across a bug report in the idevicerestore repository (a utility for installing macOS/iOS from IPSW). One of the Asahi Linux creators, marcan, reported that when restoring UniversalMac_11.4_20F71_Restore.ipsw on his Apple Silicon MacBook, he encountered an error:

ERROR: Got unknown updater name 'AppleTCON'.

The bug was closed, adding TCON firmware restore support to idevicerestore. This suggests Apple's own tool likely sends an 'AppleTCON' updater command during DFU restore/revive. So the TCON firmware restoration should work in DFU mode.

As for downgrading to an older version, libAppleTCONUpdater.dylib contains a method:

AppleTCONDP855Device::isFWComponentsUpdateRequired

that checks if an update is needed. This applies to my TCON Parade DP855.

If versions differ, update is allowed (regardless of newer/older).

I am not 100% sure DFU uses this library, but I think it does - since this library parses the XML firmware file that contains the firmware for the update, and the TCON driver does not.

Related question, any idea if older TCON firmware versions are still signed and possible to restore, independent of the OS version?

The only way to know for sure is to send a request to Apple's server for a ticket with the hash of the desired firmware. If the ticket is granted, then everything is fine.

That said, I compared the TCON firmware files for macOS 12 and macOS 26 - they are identical for my 13" M1 MBP. It seems TCON firmware isn't updated often; it might even be the same as it was on day one.

WhisperingWind

First attempt at flashing the Parade DP855 TCON (13" M1 MBP): No luck

This post kicks off a series where I'll be poking around the TCON flashing process. If it turns into more than a couple of posts, I'll move it to its own thread.

I wrote a small app that uses libAppleTCONUpdater.dylib. The app retrieves TCON information, populates an XML request to obtain a ticket from Apple, receives the ticket, and passes it along with the contents of the firmware file to libAppleTCONUpdater.dylib. The app was thrown together in a couple of hours - it's hacky, and just meant to test the hypothesis.

I also bumped the firmware-ver and bundle-ver version numbers in the firmware file to confirm that the update took place.

ThelibAppleTCONUpdater.dylib library writes a log during the update process; here's the most interesting part:

[TCON LOG]: Dev:deviceid A41032

[TCON LOG]: FW Update Options I:1 S:0

[TCON LOG]: Update to 0x01:0x45

[TCON LOG]: Download comp:0x0000 NumBlocks:16

[TCON LOG]: Download comp:0x5501 NumBlocks:1

[TCON LOG]: Download comp:0x5502 NumBlocks:2

[TCON LOG]: Download comp:0x5503 NumBlocks:1

[TCON LOG]: Download comp:0x5504 NumBlocks:1

[TCON LOG]: Download comp:0x550b NumBlocks:2

[TCON LOG]: Fuse SDOM (1:0)

[TCON LOG]: Reset option 2

[TCON LOG]: AppleTCONUpdateController::execCommand: Exiting execCommand: command = performNextStage, result = 0x0

Great, so it looks like the firmware data is successfully written to the chip, which is why the library returns result = 0x0 (spoiler: there's a catch). A quick note: "Download" here doesn't mean downloading from the network; this is a common term in the microcontroller firmware world for sending data over the bus.

When libAppleTCONUpdater.dylib performs the firmware update, it calls methods from AppleDPDisplayTCON.kext behind the scenes:

AppleParadeDP855TCON::readRegisters(unsigned int, unsigned char*, unsigned int)

AppleParadeDP855TCON::writeRegisters(unsigned int, unsigned char const*, unsigned int)

Nearly 18,000 calls to the writeRegisters method!

I reverse-engineered AppleParadeDP855TCON::writeRegisters. The code shows direct hardware communication via I2C with the DP855 controller. I2C is a simple communication bus commonly used to connect microcontrollers with peripherals like sensors, displays, and memory chips.

This looks like real hardware interaction!

But after rebooting the Mac, neither firmware-ver nor bundle-ver in the I/O Registry had changed.

I also modified the EDID to avoid possible version mismatches. The EDID is present in two sections of the firmware update file. I changed the display name in both places. Then I read the EDID back using BetterDisplay (it reads directly over the I2C bus) after flashing. The EDID did not change.

Bottom line: There is a suspicion that the data is being written only into the TCON SRAM (volatile memory), and then the controller itself is supposed to commit that data into its internal flash memory (non-volatile memory). But for some reason that does not happen.

Newscreensarehorrible

WhisperingWind Nice, love the updates.

WhisperingWind

The TCON controller is simply ignoring us 🙂

libAppleTCONUpdater.dylib writes data into a buffer in kernel space, and the address of this buffer is passed to the TCON controller. The TCON controller then uses this address to independently read the data directly from memory. The library then polls the TCON, asking, "Did you read the data?". But the controller always responds with error 0x2e4: kIOReturnNotReady.

libAppleTCONUpdater.dylib does not switch the TCON into the mode required for flashing (that is not its job). It is just a transport. Therefore, the controller is not in a state ready to accept the firmware.

I tried disabling the built-in display via CoreGraphics, thinking that the TCON might be able to accept the firmware in this mode. However, in this case, the controller simply shuts down. Closing the lid or booting into Recovery Mode didn't fix the issue either.

The only option left is to try the idevicerestore utility in DFU revive mode. On the bright side, the source code is available, so we can at least get full logs and understand exactly how DFU works.

WhisperingWind

How to Turn a MacBook into a DIY Mac Mini in 5 Minutes 🙂

Target Mac (the one in recovery mode) requests certain update components from the Mac running idevicerestore or Apple Configurator according to a special protocol. When it waits for the TCON firmware, it sends an AppleTCON message with the tag FirmwareData. idevicerestore running in Update mode (updates firmware/OS without erasing user data) receives this message, but it does not contain the FirmwareData tag. As a result, the firmware is not sent to the target Mac.

When I modified the idevicerestore code to always send the firmware, the flashing still didn't occur.

Okay, got it. Trying full erase mode. But I decided to do this in Apple Configurator. I prepared the firmware, modifying the LUT [tables] section. In theory, there’s nothing critical in there - the worst that could happen is some messed-up colors - so if something went wrong, I could always re-flash the original firmware and bring the TCON back to life.

But no such luck. After flashing, the TCON chip stopped functioning properly. The built-in screen’s backlight wouldn’t turn on. Some information about the chip disappeared from the I/O registry: the firmware version and, most importantly, the Nonce - a pseudo-random number generated each time one attempts to re-flash the chip, which must be sent to Apple in a request for a ticket. This means the chip can no longer be re-flashed via DFU.

I tried reading the TCON registers. The register memory is readable, meaning the chip is alive and functioning, but some error prevents it from completing initialization and turning on the display backlight.

I need to take the MacBook to a service center where the TCON firmware can be restored from an original dump. But given that I hardly use the internal display, I’ve decided to ignore it for now and use it as a "Mac Mini."

What are the downsides?

If I open the closed lid after the OS has already booted, DCP tries to initialize the TCON, which doesn't respond. This triggers an assertion in the DCP code and an instant kernel panic.
Stillcolor sometimes freezes when trying to disable dithering on the internal display.
BetterDisplay freezes if it tries to read the display's EDID via the I2C bus (yep, there's a function for that).

Point 2 was fixed in Stillcolor's code. I also added a feature to disable the built-in display to avoid having two desktops - though I always use my Mac with the lid closed and connected to an external monitor anyway, so it's not like it really matters.

Otherwise, the Mac functions just like it used to.

xenu

Trying these on the M5 Air by modifying Stillcolor, I get not permitted on embedded or external display for all of them:

supportHDR (set to NO)
wideGamutPassthrough (set to NO or YES)
disableDisplayOptimize (set to YES)
maxPeakBpp (set to 8)
enablePulseWidthMaximization (set to NO)
contrastEnhancerStrength (set to 0 or 10)
contrastEnhancerCorrectionFactor (set to 0 or 10)

« Previous Page