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

VSABALAIEV78

I mean "DFC", my bad. I turned off all features that "improves" image and used only base monitor settings.
+ 2x scaling (if monitor resolution is 3840 × 2160, I use 1920 × 1080 macos scaling)
+ Disable font smoothing via https://www.fontsmoothingadjuster.com/

more info you can find here reg resolutions and fonts https://tonsky.me/blog/monitors/#integer-scaling

With this, I can work and do not feel any issues with my eyes

jordan

VSABALAIEV78 ahh okay I thought there was a workaround with turning off FRC lol

aiaf

EDID Jackpot

Using the IPSW for macOS Sonoma 14.3, I located the firmware used by TCONs inside /Firmware/DP855. It ships with various versions of the firmware for every panel configuration.

Additionally, it not only includes the firmware payload, but also payloads for a barebones EDID, TCON_CONFIG, FW_CONFIG, NVM_IMAGE, FC_BIST_CONFIG, and a LUTS_CONFIG (not for iMacs).

I managed to extract the EDIDs into the correct format. The EDID binaries had 256 bytes of extraneous/empty data at the start which I had do strip.

Download the EDIDs

This is surprising because I believe there was a kind of agreement that embedded panels do not use EDIDs.

Observations

In "Video Input Definition" Color Bit Depth is 8 in every EDID
Only supports RGB 4:4:4
Only 1 timing is available, and the pixel clock corresponds with 8bpc at 60Hz at the available resolution (please correct me if I'm wrong)

Now this is good news because my attempt to read the TCON's memory directly failed. I now have the LUTS and firmware but it will be some time before I can gain additional insight.

async

aiaf Awesome. I fiddled around with ipsw yesterday trying to find the actual drivers but got stuck. What commands did you user for this?

waydabber

aiaf Hi there - EDIDs that can be extracted with an I2C read from the built-in display on Apple Silicon (still nice find, it's super useful to have them all in a neat package!). Moreover, you can even override the EDIDs on the fly (the successful override will be rewarded with a blink and a subsequent I2C read will confirm - strangely enough - that the altered EDID is read), however nothing meaningful actually happens (changing timings like refresh rate, resolution, bit depth etc does nothing). The override goes away upon lid close/open. Read/write EDID for built-in screens is disabled in BetterDisplay (for Apple Silicon, on Intel it is enabled), but I can provide a build with this enabled in case you want to experiment with what happens with on-the-fly EDID overrides (unlike Intel, I know of no mechanism to override an EDID at boot time for Apple Silicon, although it would be nice if one could figure that out). I did not experiment with it that much as it made no sense at the time.

My theory is that this EDID is only provided for compatibility reasons (it is obviously not complete, an EDID for a normal HDR capable display with VRR support and various additional refresh rates would look completely different), probably used only in some baseline operating mode (like during boot early on or recovery mode maybe). Not sure though. It is possible that changing the EDID at firmware level (I am not sure this can be accomplished) could yield different results. I did not try an I2C EDID write (which is tested to work with dongles and some external displays on Apple Silicon, 99.999% this is disabled or does not work like this for the built-in display - but did not dare to try it nevertheless).

aiaf

async the .bin files (e.g. X1712.bin) inside /Firmware/DP855 are just XML-format plists, rename them and open in Xcode or whatever text editor. Each <data/> element is a base64-encoded binary with 256 bytes of padding at the start. Strip that using dd if=file-in.bin of=file-out.bin bs=256 skip=1 or whatever other tool you have at your disposal and you'll get the real binary.

async

aiaf Thanks. Looking into it again. Used this, but I was digging around in the kernelcache and stuff. Didn't actually realize that mac has ipsw files as well. https://github.com/blacktop/ipsw

aiaf

async you can load the IPSW kernelcache and dyld caches directly using Hopper. For im4p, you just need to strip 25 bytes of header data and then load it into Hopper.

async

Stumbled upon this, that was a rather nice resource to give an overview of a lot of things.

https://book.hacktricks.xyz/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture

https://book.hacktricks.xyz/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-iokit

Blooey

waydabber (unlike Intel, I know of no mechanism to override an EDID at boot time for Apple Silicon, although it would be nice if one could figure that out). I did not experiment with it that much as it made no sense at the time.

Could it be that Apple is reading directly from Displays Preferences, with no intermediate standardized configuration formats? The reason I say this, is this developer was able to force RGB mode on M1 Macs when all previous and deeper level approaches had failed. He simply added the mode to the System Preferences plist.

Interestingly for us, in his preference, he adds a BitDepth of 8, and apparently everything works he expects. Minding this could be Apple’s confusing use of 8 meaning 10-bit, and 4 meaning 8-bit.

Has anyone tried this approach to modifying display BitDepth on Apple Silicon?

aiaf

waydabber thank you for the insights! I agree with you, I doubt the EDID influences anything. It reports color bit depth as 8 already- so what are we going to even change? Like you I'm also not courageous enough to do any I2C/SPI writing to the TCON yet. Maybe if I have a throwaway notebook, but not my main machine...

waydabber

Blooey editing the windowserver configuration file is a known and old method to influence which color mode is being used when multiple color mode options are available for external displays. Using EDID overrides to force RGB is an alternative (and probably somewhat better) way which also works fine for External displays.

The problem here is forcing the internal display to do something else than it does now. The config file approach won't work for sure as for the internal display only one color mode available for each available timing therefore no change in a config file can force an alternative choice (which has different encoding, bit depth etc). Btw the bit depth for the sole available color mode is already reported as 8-bit (note: this is connection bit depth, not the framebuffer depth) so purely for that purpose I am not sure a change like that is needed. Color encoding is already RGB of course so no improvement needed there either.

As far as I understand (but @aiaf will probably correct me 🙂) we now mostly think that connection is fine and there is no need to change that + with GPU temporal dithering off things are potentially vastly improved - the major concern now is whether various color correction and gamma tables in the TCON's firmware force the panel to choose colors for which it needs to use FRC or something similar (which would negate the advantages of turning the GPU side temporal dithering off).

aiaf

Blooey I tried the <LinkDescription/> trick for the embedded panel too, just to leave no stone unturned etc, my impression is that is did nothing. But perhaps it's worth re-trying thoroughly with other options set too like PixelEncoding, and EOTF, etc.

Additionally the DCP firmware has telling strings such as

" [AppleDCPDPDisplay.cpp::%d] DCPAV[%d] %s::%s added timing and color element for embedded display"

So it seems that the ColorElement for the embedded panel is decided by the DCP very early on. Will have to spend some time inside this particular method to figure out where the data is coming from.

waydabber re. connection bit depth, there's a small chance it's already at 8bpc, but how are we seeing @Blooey's gradient with all these finer gradations in the 10-bit section? Some kind of gamma/brightness dithering/trickery?

I don't know if it's 10 or 8 because 1. here's what I get from AllRez:
current mode by CGSGetCurrentDisplayMode (private) = 43 = { 43: id:0x0000.02b 1496x967@60.000Hz 60Hz (dens=2.0) pixels:2992x1934 resolution:220x220 64bpp 16bpc 3cpp rowbytes:11968 IOFlags:(Valid,Safe) flags:(Valid) depthFormat:7 encoding:--------RRRRRRRRGGGGGGGGBBBBBBBB refreshRate.unk0.unk1:003c0000.0000.00000001 };

I mean depthFormat 7? What does that even mean? Yet the encoding shows 8-bit RGB. Sometimes the depthFormat is 8 and the encoding shows --RRRRRRRRRRGGGGGGGGGGBBBBBBBBBB under conditions I have yet to quantify.

I'm around 70% satisfied with my embedded panel with Stillcolor. There's still PWM of course. And the increasingly likely possibility of TCON FRC.

Blooey

waydabber Btw the bit depth for the sole available color mode is already reported as 8-bit

I didn't know that we had confirmed an 8-bit connection to the TCON. When I dump all the available modes for my built-in, using the private methods of AllRez, it returns only 10-bit modes.

So if we know the connection to the TCON is 8-bit, then it just wouldn't be possible for the TCON to produce the color depth I am seeing with the test image. The TCON would require a 10-bit input to simulate 10-bits with 8+FRC. Some other system outside of the display is still applying dithering with Stillcolor enabled. I initially worried that Preview.app is likely applying spatial dithering, but Stillcolor users with M2 MacBook Airs are seeing the test image bit-depth break down to the 8-bit level with Stillcolor, using Preview.app.

waydabber the major concern now is whether various color correction and gamma tables in the TCON's firmware force the panel to choose colors for which it needs to use FRC or something similar (which would negate the advantages of turning the GPU side temporal dithering off)

I think this would also be a problem if GPU side dithering is on. Temporal dithering should break down if a sub-pixel changes value every frame. As in from a previous dither. So I can only guess that Apple gets around this by applying the inverse of the TCON gamma to their dithered output, so their dither passes through. Either that, or the result appears acceptable enough, and they just rolled with it.

Rikl

aiaf

Any chance there is an enablePWM somewhere?

waydabber

Blooey I didn't know that we had confirmed an 8-bit connection to the TCON. When I dump all the available modes for my built-in, using the private methods of AllRez, it returns only 10-bit modes.

Yeah, maybe not 100% but both the sole available ColorMode data in the I/O Registry for the display and the extracted EDID seems to point that way. Which would mean that interim colors are produced at the GPU side with dithering (but: even 8 bit depth can result in FRC if color reproduction reintroduces dithering at hardware side).

To me it seems like by turning of GPU dithering clear bandings appear on some of the subtle effects macOS is applying using software (for example around the notch there is a nearly invisible, very subtle shadow effect by default - it's bands become visible with dithering off, mostly visible with non fully uniform bright moving backgrounds, but you need to really know what to look for).

On mini-LED screens PWM is still used to modulate LEDs for local dimming (on M1 and M2, but some testers this is no longer the case on M3 MBPs with its improved LED backlighting system) so even if we deal with all forms of temporal dithering solutions below a ceratin treshold darker screen areas may still cause fatigue.

aiaf

Rikl there's forcePixelBacklightModulation and requestPixelBacklightModulation and a lot of *BL* properties, but I don't know what their effects are or if they're possible to change or if they're related to PWM. @waydabber is an expert on these matters and you should use BetterDisplay to control anything backlight related, or use an M2/M3 Air which shouldn't have PWM.

waydabber

I think these values come from CGSGetCurrentDisplayMode where depthFormat (CGSDisplayModeDescription.depth) there is (afaik) just a shorthand to the pixel format, it probably has a proper list of associated constant names somewhere. To get the bits per pixels you should be looking at bitsPerSample. CGSGetCurrentDisplayMode deals with the framebuffer only, not the connection. I thought the depth is always 10bpc on newer macOS versions on Apple Silicon (in the past it used to alternate between 8bpc and 10bpc). This is a rather call so there is some uncertainty (in my mind at least) whether all reported values (including `IOPixelEncoding encoding`) are indeed still correct in the Apple Silicon era. Probably @joevt would know more about this.

Note there is a number of versions floating around for CGSDisplayModeDescription, this is the one I've been using where most of its contents is resolved to something useful:

struct CGSDisplayModeDescription {
  uint32_t displayModeNumber; // mode index (0..CGSGetNumberOfDisplayModes - 1)
  uint32_t flags; // similar to IOFlags -> IOFramebufferInformation.flags kDisplayModeSafetyFlags
  uint32_t width; // "Looks like"
  uint32_t height; // "Looks like"
  uint32_t depth; // 4, 7 or 8
  uint32_t rowBytes; // width * bits per pixel / 8
  uint32_t bitsPerPixel; // 32
  uint32_t bitsPerSample; // 8, 10 or 16 - but 16 signifies 8?
  uint32_t samplesPerPixel; // 3
  uint32_t refreshRate; // integer refresh rate
  uint32_t horizontalResolution;
  uint32_t verticalResolution;
  IOPixelEncoding encoding; // --------RRRRRRRRGGGGGGGGBBBBBBBB for 8 bit, --RRRRRRRRRRGGGGGGGGGGBBBBBBBBBB for 10 bit
  uint64_t data2[8];
  uint16_t data0;
  uint32_t data1;
  uint32_t length; // 0xd4 = sizeof(CGSDisplayModeDescription)
  uint32_t fixPtRefreshRate; // 16b.16b refresh rate fixed point
  uint32_t ioModeInfoFlags; // IOFramebufferInformation.flags kDisplayModeSafetyFlags
  IODisplayModeID ioDisplayModeNumber; // 0x8000xyyy
  uint32_t pixelsWide; // actual pixels = double width for HiDPI
  uint32_t pixelsHigh; // actual pixels = double height for HiDPI
  float resolution; // 1 = normal, 2 = HiDPI
};

DisplaysShouldNotBeTVs

waydabber for example around the notch there is a nearly invisible, very subtle shadow effect by default - it's bands become visible with dithering off, mostly visible with non fully uniform bright moving backgrounds

In the case of these shadow bands that appear around the edge of the screen on mini-LED models after disabling dithering, these can be solved by disabling uniformity2D.

This will both remove the bands and also extremely reduce the "slightly fading to darker at the edges" effect that always bothered me about Apple mini-LED panels!

Disabling uniformity2D would also be a good option to include in BetterDisplay as this edge banding can become especially noticeable with lower Software Brightness.

karut

aiaf I think the M1 Air is supposed to have PWM, M2/M3 not

DisplaysShouldNotBeTVs

aiaf These have a high chance of relating to local dimming in some way — because a method to somewhat "freeze" local dimming (that doesn't fully work though, since the backlight will still dynamically change on some greyish areas, most noticeable with very low Software Brightness) is to enable BLMStandbyEnable, which most certainly stands for "backlight modulation standby enable".

However, even with pretty thorough testing with software brightness, test patterns, etc. I couldn't observe any change with my own eyes or my level of strain messing the other two backlight modulation settings.

aiaf

karut my apologies, I'll edit the post

Rikl

karut

Notebook check says that M1 Air loses PWM at 50% brightness and above. You can manage this with BetterDisplay if you need the brightness to be less than that.

Rtings says the M1 Air does not have PWM at any brightness. So who knows.

I don't notice any PWM on my M1 Air. And Stillcolor seems to have stopped the dithering.

Thanks again aiaf.

« Previous Page Next Page »