si_edgey

I mounted the disk image (step 1 on page 6)

And then I followed the instructions listed on the page: https://www.tonymacx86.com/threads/guide-installing-3rd-party-kexts-el-capitan-sierra-high-sierra-mojave-catalina.268964/

Starting from the words:

"The Hackintool Method"

and till the words:

"Thats it .. job done ... don't worry that the output is red .. thats completely normal, you should now reboot your system to load the newly installed kexts."

However, instead of that red output I had a message I listed above about system policy. But, as stated in AHK manual, I unblocked the kext in Security and Privacy.

As far as I remember, the kext was listed among loaded kexts even without restarting the computer.

    annv At first, I had this message in Hackertool:

    But probably that's because the kext was initially blocked by security in the Security and Privacy section of the Preferences.

    I think this may be to do with SIP on modern versions of MacOS. Also I think the kext needs to be signed for Catalina..

    For some time now, Apple has required those developing kernel extensions to obtain special security certificates for their KEXTs. In April this year, for Mojave and Catalina, kernel extensions have also had to be notarized, which ensures that Apple has checked each of them for malware as well.

    Main security checks therefore have to be performed when you first install a kernel extension. If it was signed from April 2019 onwards but hasn’t been notarized, Mojave and Catalina will refuse to accept it, and although in some circumstances you might be able to work around that (in Mojave at least), in most cases that is and should be a show-stopper. It means the kernel extension hasn’t been checked for malware by Apple, and you simply shouldn’t trust it: contact its developer and remind them of Apple’s security rules.

    Even when it has been notarized and passes Catalina’s security checks, you still have to add it using the General tab of the Security & Privacy pane – what Apple terms User-Approved Kernel Extension Loading. Although Catalina tends to bombard you with alerts and prompts when installing and first running some software, this is one of the more important, and needs particular care.

    Catalina was to have introduced a further change to the installation of kernel extensions, which required the Mac to restart after the user had approved an extension, before it could be loaded. This was present in most betas, but was removed shortly before 10.15 was released, and it’s unclear whether this applies to the release version, will be re-instated in a future update to Catalina, or has been abandoned altogether. Hopefully Apple will clarify this soon.

    Once a kernel extension has been built into the prelinked kernel, the latter needs System Integrity Protection (SIP), to ensure that nothing else can tamper with its contents. In Catalina, that not only means setting permissions and applying SIP, but storing it on the read-only System volume.

    Good luck and let us know how it goes 🙂.

        diop Also I think the kext needs to be signed for Catalina

        The kext does appear to be signed and notarized, for Mojave at least. If it's showing as accepted / injected then I guess it should be doing its job..? I know very little about MacOS, steep learning curve.

        • annv replied to this.

            diop

            I did not restart Mac, so that requirement might have been removed in release version.

            I wonder if I can be sure the kext is loaded and active, if it's shown among loaded kexts. I'm unsure because I do not feel much difference yet. For instance, the Safe Boot still looks different.

            si_edgey
            According to KextViewr info, the kext is third party, but signed (a closed black lock to the left of the kext name)

            • diop replied to this.

                  annv I wonder if I can be sure the kext is loaded and active, if it's shown among loaded kexts. I'm unsure because I do not feel much difference yet. For instance, the Safe Boot still looks different.

                  I believe if you open a terminal and type 'kextstat', it should show all loaded kexts.

                  • annv replied to this.

                      Yes, it should be loaded.

                      I guess I need to go for a few days with it.

                      Just realized I'm working with the text for quite some time and I do not have a feeling of overworked eyes (like sleepy).

                      Still cannot use the iMac without Gamma Control. The screen is too bright.

                      JTL

                      As far as I understand what is said in that blog, even if the kext loads it does not necessarily disable dithering?

                      Is it possible to see if the kext does/doesn't do its job? Console cannot look back in recent macOS versions. It only starts logging when you launch it.

                        JTL Can the kext be probed/reverse engineered to see how it is disabling dithering or to remove the check?

                        • JTL replied to this.

                            si_edgey On the contrary, this is actually great news because now we know who developed the KEXT. I have tracked him down and am making contact to propose the development of a KEXT for us. I will post updates here as we go on.

                            Another one of the articles on that site is interesting, albeit from 2012..

                            Flailing around the web revealed someone at Disney who has produced tweaks to X's configuration file for use under Linux; unfortunately this doesn't work in OS-X as the dithering is done by the driver.

                            It's probably way out of date but is very interesting to know how even people in the creative industry for huge corporations have needs to disable dithering.

                              Well, as said above, the kext might not do its work, although it loads.

                              After three full days of testing, I can say that I got as tired as before. The same feeling of overworked eyes and head/eye strain/pressure. And I'm pretty sure it's the iMac screen, because I managed to relax somewhat by playing on the iPad 🙂

                              This only shows itself after prolonged periods of intensive work, so I can spend 1-2 hours at the screen quite easily.

                              In the process, I also switched off Gamma Control for a while and returned from HD-709 color profile to the standard iMac profile, and after a short time my eyes started burning. This makes me believe that apart from macOS dithering, the iMac screen has brightness issues.

                                annv After three full days of testing, I can say that I got as tired as before. The same feeling of overworked eyes and head/eye strain/pressure.

                                Ahh thanks for testing @annv, I'm hoping that the kext will lead us to further developments down the line so it's not the end of the world. I'm hoping to have some more news about it soon.

                                  The developer of the kext to disable temporal dithering on MacOS sent me a very interesting reply. Sadly he does not have the time to be able to work with us on this, but he has given some interesting pointers on how we could proceed with another developer, with the caveat that Apple are moving changing kext's to exist more into the userspace than the kernel as has been mentioned above.

                                  • Crucially, they were only able to develop the kext because of a tight relationship between the company he was working for and ATI/AMD, who guided them on how to tweak the right parameters to disable the dithering. They didn't speak to Apple at all, this was done entirely with ATI/AMD as temporal dithering exists at the GPU driver level in MacOS - it's an abstraction the kernel has no interest in handling directly, it just tells the GPU/driver what colour it was where in the framebuffer

                                  • There is a hardware check as a 'dongle' for the kext. This could be bypassed by patching the kext to USB vendor ID that the kext looks for to verify hardware. I think this is where we should focus our attention as once bypassed it will at the very least allow us to rule out temporal dithering as the root cause of our issue in MacOS.

                                  If anyone feels like they can do this or knows someone who can then get in touch and I will forward on everything that was said. Failing that we can crowdfund the development cost from this forum I'm sure.

                                    dev