I can confirm this happening to me with a GF 410M on my Sony Vaio running 10.2.5 (upgraded from 10.11.6 just yesterday) To bring the mouse pointer back, you have to somehow stalk your way to Accessibility -> Display -> Cursor Size and set it to the largest size possible, then the cursor will become visible again. Once you did so, you must go to Users & Groups, create a new Administrator-type user, turn on logon screen (in case you are using auto logon), reboot and log in as the new user. You will notice that the cursor is drawn on the screen even if it's small. Now you can re-login as your normal user, delete the extra user and turn the logon screen off. From now on, your mouse pointer will persist regardless of its size, so you can make it small again. OS X can use both software and hardware for mouse pointer rendering -- OpenGL has some special functionality for drawing a mouse pointer. But it can't be used for large objects, so OS X switches back to software rendering once the pointer becomes too large. By creating a new user and enabling the logon screen, you somehow reactivate hardware rendering support for the mouse pointer that's initially switched off if you use Nvidia on 10.12.5 As for the random freezes, you must have Lilu.kext and NvidiaGraphicsFixup.kext loaded in order to avoid them (unless you use an iMac 13.1 or iMac 14-something SMBIOS definition) Most of the time, you won't even be able to see the desktop if you don't use these kexts with most SMBIOSes, but some Nvidias are known to boot more or less successfully even without them. But this doesn't eliminate the need for NvidiaGraphicsFixup.kext that requires Lilu.kext to run. Even with the random freezes gone, my screen freezes when I try to restart or shut down. The freeze also happens when I try to change my color profile or screen resolution, i.e. switch from fixed to scaled. This happens both with Web and Apple drivers. It's curious that even with the picture frozen, I can ssh into the computer from another machine, the music keeps playing and, judging by the logs, OS X continues to function even after the picture becomes stuck. I had to use DisplayMergeNub.kext in order to successfully inject a fixed EDID (screen size and serial need editing for the display to normally function in 10.12.*) I also fixed the brightness slider as per Rehabman's guide: https://www.tonymacx86.com/threads/...rol-using-applebacklightinjector-kext.218222/ The only thing I had to change is the exact name & address of my graphics device in SSDT-PNLF.aml. It used to be _SB_.PCI0.IGPU but my DSDT uses _SB_.PCI0.P0P2.GFX0 so I edited the SSDT accordingly. Given that Nvidia GPUs require some additional properties to be able to handle backlight, I also injected the following values into GFX0: AAPL,backlight-control; @0,built-in; @0,backlight-control; @0,use-backlight-blanking; @0,pwm-info. And my backlight started working. Failing to specify any of these values may result in spontaneous restarts or the brightness slider vanishing / becoming useless. Don't ever specify "display-type" though, which many guides suggest. At least in 10.11.6 and 10.12.5, this will give you a black screen. Display-type will be automatically set to "LCD" by the drivers, but injecting it manually will give you trouble. Even with my EDID and backlight fixed, I'm still getting freezes whenever I try to reboot / change my color profile / change resolution. Desperately looking for a solution. P.S. If you get freezes when plugging an external display with the lower-end Nvidias from the 4XX, 5XX and 6XX series, you can fix this by a proper NVCAP patch. NVCAP is overriden automatically with some sort of nonsense for these cards. This nonsense (that is clearly visible in IOReg) works as a kind of "full auto" mode, but can be troublesome if your graphics card's connectors are too different from a reference design. If you apply a binary patch that substitutes "NVCAP" with "NVZAP" in NVDAStartup.kext and NVDAStartupWeb.kext, then you'll be able to inject a custom NVCAP with Clover like it used to be in the good old days. Specifying just 1 display in the first display group (i.e. LVDS / eDP) and another 1 in the second group (i.e. HDMI / DP) in NVCAP often fixes the "external display freezing" issues. It is also advisable to inject the @X,can-hot-plug property for the external display, and it's generally much better if you also inject a minimal set of IOReg properties defining the name / device-type / connector-type for the secondary display. Nvidia Web drivers are generally more picky than the stock ones, sometimes you can only fix the freezes if you run the Apple drivers.