aiaf Amazing!

It would be great to figure out how to affect the negotiation itself. If you do a modeswitch (on liquid retine displays this can actually happen only when there is a refresh rate change as there is only the native resolution, every resolution alternative is scaled) the values return to default? Modifying these on-the-fly probably affects the process that creates color data from the framebuffer but without the connection renegotiated it seemingly just results in erroneous data to be produced (that's why the color artifacts).

I am not sure how the color/gamma/calibration correction LUT looks like in the TCON's memory - but if the table can map any input color data to levels that require FRC to produce on the panel, limiting the bandwidth and forcing a lower connection color depth won't actually help that much - so reading, understanding and changing the LUT might not be something that can be avoided for the proper results. It might be good to consider that changing the LUT might be a bit risky business and one that I think Apple should not actually allow from user space to happen (it could be regarded as a security risk as a malicious software could actually semi-brick the display) - so if it is possible now, as the practice might get widely known, Apple might block it in the future (as this happened with some of similar exploits in the past).

      aiaf AppleParadeDP855TCON is also on Macbook M2 Air 13.

          Blooey the fun part is that the only time Apple ever mentions VESA is in the marketing for the Pro Display XDR VESA Mount. Otherwise I don't think they particularly care about complying with VESA. They spec their displays to their own standards with their own marketing lingo.

          waydabber I tried changing the refresh rate while in "2-lane eDP mode", and the image corrected itself back to full bandwidth. So that apparently doesn't work. Perhaps if we can patch _IOAVVideoColorBitDepth to always return 1 (IOKit's enum for 8bpc) and patch _IOAVVideoColorBitDepthScalar to return 8 for 2 (enum for 10bpc), these might force anything else that uses these internally to use 8 bits.

          Re. LUT, well the TCON's logic can be as simple as if 24-bit signal detected -> skip FRC module. Additionally, the LUT can be as simple as an array of <= 1024 0/1 values for each RGB channel to decide whether or not to dither on a particular sub-pixel value. Or it could be a type of bit template. I think we'll find out soon, and it will give us a hint about how these particular FRC algos works. Did you have success rounding the pixel buffer's 10-bit colors to 8 bits?

          Edit: if the FRC algo has a spatial dithering step that works on the average of values of a cluster of pixels, let's say on a 4x4 square, then I don't think rounding down 10-bit colors to 8 bits (inside a 10-bit container) will help much, unless you have large areas of single colors that don't change frame to frame.

          I 100% agree about touching the TCON. This is why I don't want to deal with EEPROM. Risk of bricking the display is very real.

              This might not be adding much useful information to the topic at hand, but I thought I would experiment by overriding EDIDs to report 6-bit color depth instead of 8, and see what it would do. This was on my older Mac Pro 5,1 Intel system, macOS High Sierra, GTX 1080 FE, NVIDIA web drivers, and two 1080p 6-bit+FRC monitors (an unusual setup, so I'm unsure how far to extrapolate this).

              There was definitely a difference, and not in a good way. The instability of the picture was perceptibly worse, and I could almost consciously see the dithering/flickering in real-time. Looking at the gradient image by @Blooey, the differences between 6, 7, and 8-bit (and arguably higher) were still very apparent. Furthermore, SwitchResX still reported millions of colors for both displays, and the System Information app still reported 24-bit color (ARGB8888) for both displays. Poking around in the platform SDK headers for CoreGraphics, it appeared that the only options may be ARGB8888, ARGB2101010, and two variants of YCbCr 4:2:0. So, we may be unable to reduce the base framebuffer depth below 8-bit. However, if we find a method to disable the temporal dithering on Intel macOS, that would still be huge.

              One interesting thing was that on the lock screen, the color depth was visibly reduced, but only on one of the screens (right side):

                macsforme edids are tied to serial number of the display. In some cases monitors have the same serial and it turns into a giant mess with monitor placement. I've done this previously as well. But I never tried forcing a super slow refresh rate. Might be interesting. A bit harder to figure out the right way to do that with edids as timings are somewhat complex, but if you're up for it just search for edid timing calculator or something. There are other interesting things related to timings as well.

                  Donux is that a Touch Bar model?

                  Going back to this post by @DisplaysShouldNotBeTVs

                  DisplaysShouldNotBeTVs Do you think that the M1 MacBook Air, M1 MBP 13" with Touch Bar and M2 MBP 13" with Touch Bar (the lower-end ones that don't have MagSafe) could potentially be a way around this?

                  These 3 specific laptops are the only Apple Silicon laptops that are only marketed to display at "millions of colors", unlike the M2/M3 Air and all of the 14"/16" Pros with no Touch Bar, which all include "billions of colors" in their spec sheet.

                  Can anyone check which TCON model these use?

                  ioreg -lw0 | grep TCON

                  There are a couple of possibilities here for those specific low-end models with "millions of colors":

                  1. Native 8-bit panels that receive an 8/10-bit input signal to the TCON

                  2. 6-bit+FRC panels that receive an 8/10-bit signal to the TCON

                  We can make an informed guess based on the capabilities of the TCON.

                  It's just that now I don't see a reality where any Apple product uses a TCON that doesn't have FRC built in. Would love to be proven wrong. TCON FRC is so cheap and easy.

                        aiaf

                        Macbook Pro 15' Intel 2018

                        MacOS Big Sur 11.7.2

                        | |   |   | |   "CFG_USE_TCON" = Yes

                        | |   |   | |     "ATY,Tolten" = {"aty_config"={"CFG_USE_CP2"=Yes,"CFG_USE_SCANOUT"=Yes,"CFG_NVV"=2,"CFG_PTPL2_TBL"=<280000002700000026000000250000002400000023000000210000001f0000001d0000001b000000190000001700000015000000130000001100000006000000>,"CFG_USE_AGDC"=Yes,"CFG_USETCON"=Yes,"CFG_DIAG_LED"=2},"aty_properties"={"MM_EnableHEVCEncode"=No,"PP_SclkDpmTuning4"=2621696,"PP_SclkDpmTuning3"=1181184,"MM_EnableHEVCDecode"=No,"PP_MclkDpmTuning1"=575488,"PP_SclkDpmTuning2"=2621696,"PP_MclkDpmTuning0"=2319366,"PP_SclkDpmTuning7"=2621952,"PP_SclkDpmTuning1"=2621696,"PP_SclkDpmTuning6"=2621696,"PP_EnableLoadFalconSmcFirmware"=1,"PP_Falcon_QuickTransition_Enable"=1,"PP_SclkDpmTuning0"=2647040,"PP_SclkDpmTuning5"=2621696}}

                        | |   |   | |     "ATY,Palena" = {"aty_config"={"CFG_USE_TCON"=Yes,"CFG_USE_SCANOUT"=Yes,"CFG_USE_FBC"=Yes,"CFG_PTPL2_TBL"=<2800000027000000260000002500000024000000230000002200000021000000200000001e0000001a0000001600000013000000100000000d0000000a000000>,"CFG_NVV"=2,"CFG_USE_CP2"=Yes},"aty_properties"={"MM_EnableHEVCEncode"=No,"PP_SclkDpmTuning4"=3932416,"PP_SclkDpmTuning3"=3932416,"MM_EnableHEVCDecode"=No,"PP_MclkDpmTuning1"=527360,"PP_DisableClockStretcher"=1,"PP_SclkDpmTuning2"=3932416,"PP_MclkDpmTuning0"=3957766,"PP_SclkDpmTuning7"=2622464,"PP_SclkDpmTuning1"=5900302,"PP_SclkDpmTuning6"=2623488,"PP_EnableLoadFalconSmcFirmware"=1,"PP_Falcon_QuickTransition_Enable"=1,"PP_SclkDpmTuning0"=5923858,"PP_SclkDpmTuning5"=2627590}}

                        | |   |   | |     "ATY,Yelcho" = {"aty_config"={"CFG_USE_CP2"=Yes,"CFG_USE_SCANOUT"=Yes,"CFG_USE_TCON"=Yes},"aty_properties"={"PP_Falcon_QuickTransition_Enable"=1,"PP_EnableLoadFalconSmcFirmware"=1}}

                        | |   |   | |     "aty_config" = {"CFG_USE_PSR"=No,"CFG_NO_HDCP"=No,"CFG_USE_LPT"=No,"CFG_INT_SSPC"=25,"CFG_USE_CPSTATUS"=Yes,"CFG_GEN_FLAGS"=0,"CFG_NO_SLS"=No,"CFG_USE_FBC"=No,"CFG_NO_MST"=No,"CFG_FORCE_MAX_DPS"=No,"CFG_NO_PP"=No,"CFG_USE_AGDC"=Yes,"CFG_USE_TCON"=Yes,"CFG_UFL_CHK"=No,"CFG_USE_DPT"=Yes,"CFG_PULSE_INT"=Yes,"CFG_USE_HDMI20"=Yes,"CFG_USE_STUTTER"=Yes,"CFG_NO_MSI"=No,"CFG_UFL_STP"=No,"CFG_USE_FEDS"=Yes,"CFG_FB_LIMIT"=0,"CFG_TRANS_WSRV"=Yes,"CFG_USE_SCANOUT"=Yes,"CFG_PAA"=0,"DALUseUrgencyWaterMarkOffset"=0,"CFG_USE_FBWRKLP"=Yes,"DALReadDelayStutterOff"=4,"CFG_NODM"=Yes,"CFG_USE_SRRB"=No,"CFG_FORCEMAXDPM"=No,"CFG_CAA"=0,"CFG_APER_MODE"=1}

                        | |   |   | |     "ATY,Forrahue" = {"aty_config"={"CFG_USE_CP2"=Yes,"CFG_USE_SCANOUT"=Yes,"CFG_TPS1S"=Yes,"CFG_NVV"=2,"CFG_PTPL2_TBL"=<820000007c00000076000000700000006a000000640000005e00000058000000520000004c00000046000000400000003a000000340000002e00000028000000>,"CFG_USE_AGDC"=Yes,"CFG_USE_TCON"=Yes},"aty_properties"={"PP_DisableMCDownLoadFeature"=1,"PP_Falcon_QuickTransition_Enable"=1,"PP_EnableLoadFalconSmcFirmware"=1}}

                        | |   |   | |     "ATY,Sinu" = {"aty_config"={"CFG_USE_CP2"=Yes,"CFG_USE_SCANOUT"=Yes,"CFG_NVV"=2,"CFG_PTPL2_TBL"=<820000007e0000007a00000076000000720000006e000000660000005e000000560000004e000000460000003e000000360000002e000000260000000a000000>,"CFG_USE_AGDC"=Yes,"CFG_USE_TCON"=Yes,"CFG_DIAG_LED"=2},"aty_properties"={"PP_DisableMCDownLoadFeature"=1,"MM_EnableHEVCEncode"=No,"PP_SclkDpmTuning4"=1181184,"PP_SclkDpmTuning3"=787456,"MM_EnableHEVCDecode"=No,"PP_MclkDpmTuning1"=527360,"PP_SclkDpmTuning2"=787456,"PP_MclkDpmTuning0"=2319366,"PP_SclkDpmTuning7"=2621952,"PP_SclkDpmTuning1"=787456,"PP_SclkDpmTuning6"=2621696,"PP_EnableLoadFalconSmcFirmware"=1,"PP_Falcon_QuickTransition_Enable"=1,"PP_SclkDpmTuning0"=1008640,"PP_SclkDpmTuning5"=2621696}}

                        | |   |   | |     "ATY,Berbice" = {"aty_config"={"CFG_USE_CP2"=Yes,"CFG_USE_SCANOUT"=No,"CFG_NVV"=2,"CFG_PTPL2_TBL"=<230000002200000021000000200000001f0000001e0000001d0000001c0000001b0000001a000000190000001700000015000000130000001000000006000000>,"CFG_USE_HDMI20"=No,"CFG_USE_TCON"=No,"CFG_USE_FBC"=Yes},"aty_properties"={"MM_EnableHEVCEncode"=No,"PP_SclkDpmTuning4"=1967622,"PP_SclkDpmTuning3"=5898240,"MM_EnableHEVCDecode"=No,"PP_MclkDpmTuning1"=527360,"PP_DisableClockStretcher"=1,"PP_SclkDpmTuning2"=5898240,"PP_MclkDpmTuning0"=3957766,"PP_SclkDpmTuning7"=1968128,"PP_SclkDpmTuning1"=5900302,"PP_SclkDpmTuning6"=1968128,"PP_EnableLoadFalconSmcFirmware"=1,"PP_Falcon_QuickTransition_Enable"=1,"PP_SclkDpmTuning0"=5923858,"PP_SclkDpmTuning5"=1968128}}

                        Macbook Pro 14' M3

                        MacOS: Sonoma 14.1.2

                        https://pastebin.com/raw/S3KdxmdV

                        • aiaf replied to this.

                            madmozg thanks for the additional data point. Unfortunately this particular test only works notebook M-series Macs, and possibly not all of them.

                                aiaf I've posted for M3 as well, will post for M1 later.

                                  aiaf Sorry I misunderstood. Shouldn't post info for my model 🙂 Was thinking that you are collecting data from all current models.

                                  • aiaf replied to this.

                                      Sentiny no not at all, it's always good to have additional data points. We just haven't seen any reports on the bare M1 yet.

                                          aiaf Sentiny mentioned the M2 Air model of which there is no touch bar version.

                                            Hunter20 Intel arc a770 LE uses a TCON chip and supposedly does not dither on default settings. Unsure what tcon model it is..

                                              ryans

                                              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.

                                                  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)

                                                      DisplaysShouldNotBeTVs

                                                      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.

                                                        dev