- Joined
- Nov 4, 2011
- Messages
- 677
- Motherboard
- Gigabyte GA-Z170X-UD3 F23g
- CPU
- i7-6700K
- Graphics
- RX 580
- Mac
NvidiaGraphicsFixup.kext, is used among others, to eliminate booting into displays that remain black/dark. To fix this, one can apply the following boot argument, "ngfxpatch=cfgmap" which is intended to "apply" none into the ConfigMap dictionary for the system board-id in use. This is similar to what AGDPfix is doing with one difference, AGDPfix applies "none" permanently to the ConfigMap dictionary for the system board-id. and it works, whereas NvidiaGraphicsFixup.kext does not, at least not on my Skylake build with High Sierra 10.13.4
Another boot argument that does however sort of work on my Skylake build is "ngfxpatch=pikera" which is replacing board-id with board-ix. So far so good, it does indeed eliminate the black screen problem, and boots my Skylake machine every time with no problems whatsoever, however when one wakes the machine from sleep on a multi-monitor system it is quite noticeable , that the machine is struggling to get the monitors "alive". Most of the times waking from sleep is successful but occasionally the machine just locks up, requiring a reboot.
I have rebuilt Lilu, NvidiaGraphicsFixup, Shiki, AirportBrcmFixup and AppleALC.kext against the latest source code available also using the latest Lilu Debug version against each of the other kexts listed which I am using, however the problem remains.
My workaround is to nevertheless use "ngfxpatch=cfgmap" as a boot argument, although it does not work, nor does it seem to cause any harm either, and use AGDPfix to ensure that I do not boot into a black screen, and it works as well. My computer is responsive, stable and one can observe that when waking from sleep the attached monitors spring to life virtually instantaneously.
On my Haswell build I have no problems when using "ngfxpatch=pikera" as a boot argument, but decided to use "ngfxpatch=cfgmap" with AGDPfix, regardless. On Haswell I need to use AGDPfix as well when using "ngfxpatch=cfgmap".
Something is broken somewhere. I believe that the symptoms that I described would perhaps be called by some hackers as lag experienced with Nvidia drivers, hoping therefore that this posting will assist them generally in improving the performance and stability of their hacks.
Another boot argument that does however sort of work on my Skylake build is "ngfxpatch=pikera" which is replacing board-id with board-ix. So far so good, it does indeed eliminate the black screen problem, and boots my Skylake machine every time with no problems whatsoever, however when one wakes the machine from sleep on a multi-monitor system it is quite noticeable , that the machine is struggling to get the monitors "alive". Most of the times waking from sleep is successful but occasionally the machine just locks up, requiring a reboot.
I have rebuilt Lilu, NvidiaGraphicsFixup, Shiki, AirportBrcmFixup and AppleALC.kext against the latest source code available also using the latest Lilu Debug version against each of the other kexts listed which I am using, however the problem remains.
My workaround is to nevertheless use "ngfxpatch=cfgmap" as a boot argument, although it does not work, nor does it seem to cause any harm either, and use AGDPfix to ensure that I do not boot into a black screen, and it works as well. My computer is responsive, stable and one can observe that when waking from sleep the attached monitors spring to life virtually instantaneously.
On my Haswell build I have no problems when using "ngfxpatch=pikera" as a boot argument, but decided to use "ngfxpatch=cfgmap" with AGDPfix, regardless. On Haswell I need to use AGDPfix as well when using "ngfxpatch=cfgmap".
Something is broken somewhere. I believe that the symptoms that I described would perhaps be called by some hackers as lag experienced with Nvidia drivers, hoping therefore that this posting will assist them generally in improving the performance and stability of their hacks.
