• OS
  • New attempt to disable dithering on M1/M2 chipsets

Last attempt to disable dithering on M1/M2 devices failed.

Today I spent more time to reverse engineer the Apple silicon drivers.

Could you try to enter to command from the normal mode and check effect of this command:

sudo nvram boot-args="iomfb_disable_dfr_display=1 iomfb_force_block_Dither=1"

enter your password and then reboot the laptop.

    I hope someone with this device can try it. Much thanks for keep working on this @NewDwarf 🙂!

    Do you expect this might work on Ventura as well? Or must be before Ventura.

    Thank you, NewDwarf !

    I entered your command (MacBook Air M2).

    Command

    log show --predicate "processID == 0" | grep Dither

    shows that:

    2023-01-24 01:31:52.026676+0300 0x41b9     Default     0x0                  0      0    kernel: (Sandbox) System Policy: nvram(3507) allow boot-arg-set iomfb_force_block_Dither

    Need time for testing.

    Is there any way to further check that dithering is off?

    Display mode will remain 10 bit?

      JesHD log show --predicate "processID == 0" | grep Dither

      Above command doesn't work for Apple silicon GPU. It is only Intel specific.

      iomfb_disable_dfr_display env variable should skip default initialization for some GPU parameters specific to color management.

        @bkdo Try the commands in the first post here, see if it helps on your M1 / M2.

        4 days later

        NewDwarf Hi there, very interested if this would work.

        Do you have an m1 m2 to machine to test this on yourself?

        Can anybody confirm this works? Is there a more detailed manual on how to do this for non coders?

        Can I try it in the store using terminal for instance?

        thanks @NewDwarf, ive been following this intently. I just tried to new command. will report back tomorrow morning. Usually notice the dithering feeling then. Is there a way to check if the command was run in terminal?

        Edit: just ran the command and rebooted and a swear the screen looks better/different running the same sRGB IEC61966-2.1 profile. Was wondering, in a P3/sRGB example image like this one https://webkit.org/blog-files/color-gamut/comparison.html. Obviously if I keep my sRGB IEC61966-2.1 profile I shouldn't be able to see the differences in the image. Now, if I run the command and set the profile to P3 display, should it still mimmic 8 bit color and prevent me from seeing the differences? When I it now, P3 profile and the above dithering command run and rebooted, im still seeing the differences in the images.

        edit 2: I had previously disabled “csrutil disable” in recovery mode when trying the original method you posted. was wondering if I could re-enable “csrutil" after entering this command?

        NewDwarf After several days of testing (M2 Air Monterey), I still feel eye strain (using different profiles, sRGB IEC61966-2.1 and others). Maybe try some other commands?

          MTNEYE maybe I need to enter this command again and testing (SIP is disabled)

          10 days later

          NewDwarf The new version (1.4.2) of the BetterDisplay has a new function - EDID override support for Apple Silicon Macs. Can it help us?

            Ruoma if I understand correctly, this option allows to overwrite the display EDID, and perhaps it is possible specify that the video output is 8 bit

              10 days later

              At this point I'm honestly hoping for a OLED MBP in 2023/2024. Even if it PWMs at 99% brightness and under, I would be fine to keep it at 100% and used third part/OS tricks to dim the display, assuming it was a true 10(or 12) bit display there for no dithering. I can use I phone X thru 12 at 100% brightness no problem, acutely my preferred device, dim it at all and the PWM starts and its a no go. iPhone 13/14 PWM at 100% and could feel it in the store almost immediately. Also, my 2020 MBP M1 is fine hooked up to one or more external monitors, however when I airplay via my Apple TV 4K on my Samsung 2017? 65" LCD TV, It'd not as bad as the MBP screen but here is some dithering or font smoothing or something that I notice being slightly irritating afterwards. Nowhere near like looking at the actual dithering M1 screen.

              All that being said it seems like they could make it DC dim like any of these new OLED TVs that DC dim with just a slight dip in brightness every 8ms that coincides with the refresh rate and not full PWM. Although, I haven't spent much time in front of one of these, sounds good in theory though..

                MTNEYE I can use the Iphone X too, and it's one of the most comfortable devices that I have with the LG B8, and i tried the 13 pro and 14 pro but i wasn't able to use them or adapt.

                So are you using the 12 or the 12 pro? Have you tried also the 11 pro?

                Thanks

                3 months later

                I tried the command line above after partly disabling SIP on my MBA M1 2020 system (in recovery mode terminal: csrutil enable --without nvram).

                When running the log command after reboot I also see the confirmation, that the boot parameters where somehow at least read into the system:

                2023-06-02 12:11:35.698427+0200 0x2676 Default 0x0 0 0 kernel: (Sandbox) System Policy: nvram(1001) allow boot-arg-set iomfb_disable_dfr_display

                2023-06-02 12:11:35.698431+0200 0x2676 Default 0x0 0 0 kernel: (Sandbox) System Policy: nvram(1001) allow boot-arg-set iomfb_force_block_Dither

                Since I was not sure if this changes anything, I looked with a hand Microscope (up to 60x magnification) on the pixels and also filmed it with 240fps slow motion with my iPhone with and without this option. In both cases I saw no flicker on the pixels.

                It looked in both cases like in this video from Notebookcheck, where they also found no temporal dithering on MBA M1 devices.

                MacBook Air M1 Temporal Dithering Test

                In contrast they found temporal dithering on iPad Pro 11" M2 devices with same method.

                Apple iPad Pro 11" 2022 M2 Temporal Dithering

                I also looked with the tool AllRez from github into the Display and grafics values on my M1.

                In both cases that tool read out that dither is enabled (enableDither = true ?) what is in contrast to what Notebookcheck and I saw under the Microscope (but maybe we have a systematic problem how we look for it ?).

                Here the AllRez output:

                IOMobileFramebuffer: /AppleARMPE/arm-io@10F00000/AppleT810xIO/dispext0@70000000/AppleCLCD2 = {
                
                    IOMobileFramebuffer 0x5317 = {
                
                        IOMFBTemperatureCompensationEnable = false;
                
                        enableDither = true;
                
                        PDCSaveRepeatUnstablePCC = false;
                
                        ...
                
                IOMobileFramebuffer: /AppleARMPE/arm-io@10F00000/AppleT810xIO/disp0@30000000/AppleCLCD2 = {
                
                    IOMobileFramebuffer 0x5153 = {
                
                        APTEnablePRC = false;
                
                        APTEnableLogs = false;
                
                        ...
                
                        PCCTrinityEnable = true;
                
                        enableDither = true;
                
                        IOMFBSupportsXFlip = true;

                @NewDwarf:

                I wonder in what binaries you found the iomfb_disable_dfr_display and iomfb_force_block_Dither ?

                The strings you mentioned in the other thread here like enableDither and iomfb_RuntimeProperty_enableDither I found with Hopper Disassembler in IOMobileGraphicsFamily.kext but not those from this thread here.

                Do you still get eye pain from it?

                There have been displays I have captured slow-mo video showing no flicker and yet still get eye pain. Others have reported the same experience. It seems not all sources can be rooted out via slow-mo capture.

                In the past talking with the CEO of blurbuster, he told me that 240fps is too low, we need at least 5000fps camera to identify dithering.

                  dev