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.

          @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?

          • aiaf replied to this.

            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.

              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.

                Very happy to have found this thread and Stillcolor. It's massively improved the performance of e-ink monitors connected to my MacBook. Much appreciated 🙂

                Also wanted to add to the some of advice above to switch ProMotion devices to 60Hz. I get less eyestrain leaving ProMotion on but forcing it to stay at 120Hz. My hacky method…

                1. Install the https://tracesof.net/uebersicht/ widget manager
                2. Install the https://tracesof.net/uebersicht-widgets/#SmoothAnalogClock_widget widget

                ^ as long as the hands of the clock are turning and on a screen it maxes out the refresh rate

                This is optional, but I then made the clock all black (I have a pure black desktop), the height of my dock, and placed it the bottom left of my screen by editing the widget code. So it's always on screen, but not visible for me as long as all my windows are above the dock.

                Only tested it on a 16" MacBook M3 Max using Quartz Debug from 'Additional_Tools_for_Xcode_15'.

                It adds around 8% load to the GPU on my MacBook, and battery performance still seems fine to me.

                  My friend who tried stillcolor on Mac said he also gets banding with stillcolor off BUT when using quick shade to dim the screen🤔

                  Rowe interesting concept! I tried this with 1 external display connected, and the Quartz fps shot up to 240, I guess adding up fps of both displays.

                  I can note no changes in Blooey gradient banding while 120fps is in effect which means that ProMotion does not reduce bpc.

                  This trick should work with an inconspicuous menu bar item that animates at 120fps+.

                  • Rowe replied to this.
                    dev