Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
My mp3.1 connected to Apple LED Cinema Display needs the patch to get isight working. Uses the Cinema Display camera. So all slightly confusing! The update did not seem to affect my system.

I didn't know that an Apple LED Cinema Display does have also a built-in apple webcam.
And that's weird and interesting how you using only a DVI or DP cable can also communicate with an internal iSight (embedded in the external cinema display) through an IOUSBHost driver.

But I meant typically when someone buy a Mac mini the intent is to plug it to LED TV or a MacPro to a cheaper third party display w/o embedded webcam.
 
Last edited:
  • Like
Reactions: webg3
I didn't know that an Apple LED Cinema Display does have also a built-in apple webcam.
And that's weird and interesting how you using only a DVI or DP cable can also communicate with an internal iSight (embedded in the external cinema display) through an IOUSBHost driver.

But I meant typically when someone buy a Mac mini the intent is to plug it to LED TV or a MacPro to a cheaper third party display w/o embedded webcam.
The Apple LED CinemaDisplay has a USB connection integrated into the single cable. This connects to the LED cinema USB hub. The end of the cable is terminated in a mini display port and USB connector and both these connect to the mp3.1. So it is technically a usb webcam, just included in the display. Sys Pref report it under usb as a Display iSight. Audio is also connected this way.
 
Infact, except any Mac/Macbook with an embedded LCD, every other Mac mini, Mac Pro don't have any internal USB iSight/Webcam hardware integrated, anyway there are two weird facts:

1) Why someone should accept and install a patch for an USB internal hardware (Webcam) that is not physically present?
I mean if can plug a USB printer, an external USB drive, then surely can plug also an external USB Webcam without any additional iSight patch.

2) Why "auto-patch updater" prompts a patch for a machine that doesn't have any internal webcam hardware?

Even if they seem not related in any way, I guess there is a minimum chance that a legacyiSight patch could cause a random KP on a non-targeted machine.
The iSight/Webcam patch is simply an injector kext that adds a device ID to AppleUSBVideo.kext. It will not cause a kernel panic under any circumstances. The kernel panic experienced was not related to this patch at all, and was simply the usual kernel panic people have been experiencing with 10.14.4.
 
The iSight/Webcam patch is simply an injector kext that adds a device ID to AppleUSBVideo.kext. It will not cause a kernel panic under any circumstances. The kernel panic experienced was not related to this patch at all, and was simply the usual kernel panic people have been experiencing with 10.14.4.

I thought it was an entire IOUSBHostFamily.lext replacement or some other, anyway seems I don't have any AppleUSBVideo.kext in any of my IOUSB*.kext plugins or in the Extensions folder, maybe this AppleUSBVideo.kext it's a very legacy plugin I didn't noticed before.
 
As much as I like Firefox(and all its useful extensions), I must admit that it is way too hard on my old hardware resources, so after the extensions went belly-up I saw it as an opportunity to get rid of it. And I am very glad I did, the system works much better and cooler with Safari/Safari Technology Preview(I also reduced the RAM from 8GB to 4GB as its plenty for my use). In order to replace some extensions I discovered some very good command line tools.

A MB5,1 w/8GB and 840 EVO SSD on .3 runs cool in FF but in .4 FF ramps up the fan and Safari crashes. FF v66.0.4 is worth a try?

Macbook5,1 on Mojave APFS.png
 
Does anybody know how to get recovery partition to work? I tried reapplying the patch from USB, that didn't work. After that I tried to add my board id and identifier to PlatformSupport on the recovery drive, and that also didn't work.
I have a MacBook5,1 with an HFS+ formatted drive on 10.14.4, which I updated from 10.14.3 using a new USB beacause its HFS+.
 
  • Like
Reactions: K two
Does anybody know how to get recovery partition to work? I tried reapplying the patch from USB, that didn't work. After that I tried to add my board id and identifier to PlatformSupport on the recovery drive, and that also didn't work.
I have a MacBook5,1 with an HFS+ formatted drive on 10.14.4, which I updated from 10.14.3 using a new USB beacause its HFS+.

If it's an HFS+ drive, then open your Mojave Terminal and copy/paste one line at once (they are three lines the third one is longer):

diskutil mount "Recovery HD"

sudo nvram boot-args="-no_compat_check"

sudo cp /S*/L*/Prelinked*/prelinkedkernel /Volumes/"Recovery HD"/com.apple.recovery.boot/


reboot hold CMD+R and should work.
 
Last edited:
If it's an HFS+ drive, then open your Mojave Terminal and copy/paste one line at once (they are three lines the third one is longer):

diskutil mount "Recovery HD"

sudo nvram boot-args="-no_compat_check"

sudo cp /S*/L*/Prelinked*/prelinkedkernel /Volumes/"Recovery HD"/com.apple.recovery.boot/


reboot hold CMD+R and should work.
Thanks jackluke, saw the prelinkedkernel when I had it mounted and wondered if I had to copy that over.
 
  • Like
Reactions: jackluke
This might not be the ideal place to post this (although I am working with Mojave on a MacPro 3,1), but I thought I'd share...

Why the High Sierra nVidia Web Driver Will Never Work on Mojave (long post, sorry - TL;DR at the end)

Like many folks, I dove down the rabbit hole of trying to make my modern GeForce card work under Mojave (with the added twist of doing it on a MacPro 3,1, just to make sure it wasn't too easy). Unlike most of those folks, I have a fair amount of reverse-engineering experience, and was not about to let an inter-corporation spat deprive me of both Mojave and a full-featured GPU experience. I dug until I finally found an impenetrable layer of granite.

First, the installer tries to ensure you're using High Sierra (trivial to bypass). Next, the NVDAStartupWeb kext checks the OS version at runtime (also trivial to fix). The first real hurdle is in the HS GeForceWeb kext; the virtual method table for IOAccelEventMachine2 doesn't match Mojave's version. A bit of research showed that in an unusual move, an existing method (IOAccelEventMachineFast2::stop()) was replaced with a RESERVED method - that typically goes the other way (newer version fills a RESERVED slot with a new method). Fortunately, GeForceWeb doesn't actually call that method, so I could patch the symbol table and get the kernel to link. Huzzah! ...maybe.

Booting with the patched GeForceWeb was disappointing; at about 60% of the boot progress bar, a spinner appeared and never stopped spinning. Undaunted, I experimented with copying over the High Sierra SkyLight framework (bad move), then the HS CoreDisplay framework (got the login screen to come up, but infinite loop of death followed). These generated enough log data for me to dig deeper.

I'll spare you the rest of the saga, but at the bottom I found that several data structures have changed between HS and Mojave. One of these, called MTLIOAccelResource, is a fundamental Metal object; once again, the changes are unusual. They added two members to the structure, they revised two existing members to be bitfields instead of integers (resulting in a smaller structure), and they moved a data element (resourceID) within the structure (very unusual). It's normal to reserve space in public data structures to allow for changes over time, but it's common practice to never mess with existing elements (either their size or placement), in order to preserve backward-compatibility. Given that this interface is at the driver level, they seemingly weren't concerned with that sort of compatibility; drivers apparently aren't supposed to be functional across OS versions. In any case, a HS graphic driver will be using a MTLIOAccelResource object that is utterly incompatible with the Mojave system, resulting in all sorts of internal chaos (which is exactly what I observed). And because of the additional data elements (one being a pointer, just to make things worse - MTLIOAccelDevice<MTLDevice> *weakDevice), it's non-trivial (read: damn near impossible) to write a shim that handles the differences between the HS GeForceMTLDriverWeb kext and the Mojave Metal system.

It's possible that the movement of the resourceID element was a simple oversight, a rookie mistake, a fat-finger error ("Compiler error? Oops, I must have accidentally deleted that line, I'll just paste it back in somewhere near here"). It's also possible that there's some technical reason that made it necessary, although I can't think of any that make sense. <tinfoilHat>It's also possible that the "feud" between Apple and nVidia was such that Apple wanted to ensure that there was no way for the existing drivers to work on Mojave, forcing nVidia to... (what?)</tinfoilHat> Regardless of intent, by adding and rearranging elements, they created an effectively insurmountable incompatibility.


TL;DR: Under Mojave, the Metal data structures are fundamentally different from HS, so HS drivers touching the Mojave Metal system just can't work. Plus, there's no reasonable way to write an interface layer to smooth over those differences. nVidia users just need to hope that Apple and nVidia can come to terms at some point. OR, if nVidia could be persuaded to release (or "leak") unsigned Mojave drivers - or even just selected components (perhaps "for experimental use only" or some such) - there's a community of us out here that would be more than happy to make them usable... (even on fusty old Macs...)

(While I have the floor, many thanks to @dosdude1 and the rest of the contributors here for making it possible to use High Sierra and Mojave on an old Mac. My cheese grater would probably be living up to its nickname without your efforts.)
 
The iSight/Webcam patch is simply an injector kext that adds a device ID to AppleUSBVideo.kext. It will not cause a kernel panic under any circumstances. The kernel panic experienced was not related to this patch at all, and was simply the usual kernel panic people have been experiencing with 10.14.4.

Thank you for clarifying that point. ...I was here scratching my head.
34+ continuous days with No KP's on my Mac mini 3,1
so I thought the patch did something bad.

I have now had 2 more random KP's in the last 30 or so hours.
Guess I am going back to 10.14.3
until Dosdude1 & his Guru's that be,
pull a Proverbial Rabbit out of the 10.14.5 Hat !!!

Thank you
 
  • Like
Reactions: ASentientBot
A MB5,1 w/8GB and 840 EVO SSD on .3 runs cool in FF but in .4 FF ramps up the fan and Safari crashes. FF v66.0.4 is worth a try?

View attachment 835787

I am not quite sure why we have a very different experience on an identical hardware. It is not likely that my Kingston SSD has a better controller than your 840 EVO does. I will stay with Safari for the time being as the system seems to like it better.
 
Thank you for clarifying that point. ...I was here scratching my head.
34+ continuous days with No KP's on my Mac mini 3,1
so I thought the patch did something bad.

I have now had 2 more random KP's in the last 30 or so hours.
Guess I am going back to 10.14.3
until Dosdude1 & his Guru's that be,
pull a Proverbial Rabbit out of the 10.14.5 Hat !!!

Thank you
To me it´s still a mystery why some of you experience such a lot of KPs on 10.14.4 and I have a whole bunch of different unsupported machines running without one KP with it.
 
Manual package install -- this can be a nuisance, but it does work. Take the macOS installer and open Contents/SharedSupport/InstallESD.dmg. Copy the Packages folder somewhere you can edit. pkgutil --expand the OSInstall package, open Distribution file and make the InstallationCheck() function just always return true. Then pkgutil --flatten the folder back to a package in the same directory. Open that by double-clicking (should launch Installer.app) and then install to a partition. Then (not sure why this is necessary, but it is) copy /Volumes/Mojave/usr/standalone/i386/boot.efi to /Volumes/Mojave/System/Library/CoreServices to make it bootable. That should get you the same result as installing from a bootable USB.

I also have a (pretty minimal, but potentially helpful) overview of the whole manual patching process here (for MacBook7,1 specifically) that you or others may find useful.

You might also try using @0403979's patcher (haven't used it myself, but he's a knowledgeable and helpful dude so it's worth a try). Or, try creating the installer with createinstallmedia + a bootloader (Clover?). Just trying to list all the non-dosdude1 solutions here since that doesn't seem to play well with your hackintosh.

Good luck, hope that helps. If you're still stuck, you might try /r/hackintosh or InsanelyMac forums too. I've gotten good advice there in the past. Sorry for the longish post.

@ASentientBot, I have installed the patched Mojave 10.14.4 (Patcher v 1.3.1) on my HackBookPro 7,1 (Penryn T9300, NVidia NVS 140m). The system appears to boot fine, but after the screen blanks during the boot cycle (Apple Logo), the screen remains black. This same system runs vanilla High Sierra 10.13.6 without any problems. I applied all suggested patches (include Legacy Video). Booting in verbose mode does not suggest any problems.

Do you have any suggestions that I could try to get the NVS 140m display to work with the patched legacy video drivers? Thank you for any suggestions.
 
Straight through the same motions as with Beta 4.

View attachment 835832
and @jackluke and @K two

Thanks to you both for taking the first dive. I would have too, except I'm away from my test box. Both b4 and b5 have meaningless release notes (recycled from b3) so I think these are mainly internal bug fixes and we are very close to a public release.
 
I am not quite sure why we have a very different experience on an identical hardware. It is not likely that my Kingston SSD has a better controller than your 840 EVO does. I will stay with Safari for the time being as the system seems to like it better.

I used Install macOS Mojave v.4.4.10 and Patcher v.1.3.1. I do notice FFv.66.0.4 is only slightly more resource consuming on average but the Safari ensemble seems to use more in peaks per the Activity Monitor. I will revisit Safari in .5 when it's out.

The MB5,1 is an amazing old Mac.
 
  • Like
Reactions: avz and pkouame
@ASentientBot, I have installed the patched Mojave 10.14.4 (Patcher v 1.3.1) on my HackBookPro 7,1 (Penryn T9300, NVidia NVS 140m). The system appears to boot fine, but after the screen blanks during the boot cycle (Apple Logo), the screen remains black. This same system runs vanilla High Sierra 10.13.6 without any problems. I applied all suggested patches (include Legacy Video). Booting in verbose mode does not suggest any problems.

Do you have any suggestions that I could try to get the NVS 140m display to work with the patched legacy video drivers? Thank you for any suggestions.

@ASentientBot My HackBookPro now boots into Mojave. Everything appears to be working. It seems that patched Mojave is pickier about the Mac Model for laptops. I changed my Mac Model to MacBookPro 4,1 (instead of 7,1) and Mojave booted right up. Thanks for your help!
 

Attachments

  • Screen Shot 2019-05-07 at 6.34.19 PM.png
    Screen Shot 2019-05-07 at 6.34.19 PM.png
    49.8 KB · Views: 164
This might not be the ideal place to post this (although I am working with Mojave on a MacPro 3,1), but I thought I'd share...

Why the High Sierra nVidia Web Driver Will Never Work on Mojave (long post, sorry - TL;DR at the end)

Like many folks, I dove down the rabbit hole of trying to make my modern GeForce card work under Mojave (with the added twist of doing it on a MacPro 3,1, just to make sure it wasn't too easy). Unlike most of those folks, I have a fair amount of reverse-engineering experience, and was not about to let an inter-corporation spat deprive me of both Mojave and a full-featured GPU experience. I dug until I finally found an impenetrable layer of granite.

First, the installer tries to ensure you're using High Sierra (trivial to bypass). Next, the NVDAStartupWeb kext checks the OS version at runtime (also trivial to fix). The first real hurdle is in the HS GeForceWeb kext; the virtual method table for IOAccelEventMachine2 doesn't match Mojave's version. A bit of research showed that in an unusual move, an existing method (IOAccelEventMachineFast2::stop()) was replaced with a RESERVED method - that typically goes the other way (newer version fills a RESERVED slot with a new method). Fortunately, GeForceWeb doesn't actually call that method, so I could patch the symbol table and get the kernel to link. Huzzah! ...maybe.

Booting with the patched GeForceWeb was disappointing; at about 60% of the boot progress bar, a spinner appeared and never stopped spinning. Undaunted, I experimented with copying over the High Sierra SkyLight framework (bad move), then the HS CoreDisplay framework (got the login screen to come up, but infinite loop of death followed). These generated enough log data for me to dig deeper.

I'll spare you the rest of the saga, but at the bottom I found that several data structures have changed between HS and Mojave. One of these, called MTLIOAccelResource, is a fundamental Metal object; once again, the changes are unusual. They added two members to the structure, they revised two existing members to be bitfields instead of integers (resulting in a smaller structure), and they moved a data element (resourceID) within the structure (very unusual). It's normal to reserve space in public data structures to allow for changes over time, but it's common practice to never mess with existing elements (either their size or placement), in order to preserve backward-compatibility. Given that this interface is at the driver level, they seemingly weren't concerned with that sort of compatibility; drivers apparently aren't supposed to be functional across OS versions. In any case, a HS graphic driver will be using a MTLIOAccelResource object that is utterly incompatible with the Mojave system, resulting in all sorts of internal chaos (which is exactly what I observed). And because of the additional data elements (one being a pointer, just to make things worse - MTLIOAccelDevice<MTLDevice> *weakDevice), it's non-trivial (read: damn near impossible) to write a shim that handles the differences between the HS GeForceMTLDriverWeb kext and the Mojave Metal system.

It's possible that the movement of the resourceID element was a simple oversight, a rookie mistake, a fat-finger error ("Compiler error? Oops, I must have accidentally deleted that line, I'll just paste it back in somewhere near here"). It's also possible that there's some technical reason that made it necessary, although I can't think of any that make sense. <tinfoilHat>It's also possible that the "feud" between Apple and nVidia was such that Apple wanted to ensure that there was no way for the existing drivers to work on Mojave, forcing nVidia to... (what?)</tinfoilHat> Regardless of intent, by adding and rearranging elements, they created an effectively insurmountable incompatibility.


TL;DR: Under Mojave, the Metal data structures are fundamentally different from HS, so HS drivers touching the Mojave Metal system just can't work. Plus, there's no reasonable way to write an interface layer to smooth over those differences. nVidia users just need to hope that Apple and nVidia can come to terms at some point. OR, if nVidia could be persuaded to release (or "leak") unsigned Mojave drivers - or even just selected components (perhaps "for experimental use only" or some such) - there's a community of us out here that would be more than happy to make them usable... (even on fusty old Macs...)

(While I have the floor, many thanks to @dosdude1 and the rest of the contributors here for making it possible to use High Sierra and Mojave on an old Mac. My cheese grater would probably be living up to its nickname without your efforts.)
You definitely deserve a few claps for your sleuthing. As a follower of the entire Apple Nvidia OpenGL Metal saga, my conclusion is: a combination of feud and orchestrated neglect. You seem experienced in such a things, so you know that fundamental "breaking" changes to key driver structures do not happen by accident. Someone tried to force a position and here we are a year after the fact with no drivers and no hope (imho) of any update. The best we can hope for is Nvidia open sourcing their driver code so we (capable few) can take a stab at it, but that isn't likely to happen. Meanwhile my 3,1 is purring along with its GTX680
 
New to the Mac thing. I have used before and know enough to get around, but stuck here. I have a 2010 MBP that I tried putting official High Sierra on. It never recognizes the SSD as a bootable device after trying Internet Recovery. I also tried a USB with High Sierra. Though about going back to older version to try getting it to work, then decided to try Mojave Patcher by @dosdude1 . When I boot from the USB drive, it just stops at a white/grey screen with black Apple logo. No progress bar, even after letting it sit for 30+ minutes. The USB drive itself is 32GB Samsung. I have an aftermarket Kingston Q500 SSD.

I have a 2012 with the same Kingston that restored just fine with Mojave. No issues. I have two of the 2010 model. Both have the same issue with same SSD. Don't really know other specs yet.

I also tried the newest release of the macOS Patcher and it seems to be stuck on the Apple logo, also.

Side note: I have reset the SMC and PRAM.
 
Last edited:
Re: Mac Pro 3,1:
When running Mojave, you CANNOT use a newer AMD video card EVEN IF it is a Metal-compatible card and is supported in Mojave. The newer AMD drivers used in Mojave require the SSE4.2 instruction set, which the MacPro3,1 does not support. There is no way around this at this time.
Has anyone considered making an SSE4.2 emulator kext? Something not unlike Intel's Software Development Emulator, but linked into the kernel with early initialization... Basically, you have the CPU send unrecognized instructions to your handler, where you emulate the SSE4.2 instructions (taking microseconds to do what native SSE4.2 does in nanoseconds). Intel even provides a template for such emulation. Assuming there's a way to reliably have the emulator initialized before the AMD drivers (or anything else using SSE4.2), it should work. Obviously, there's a performance hit (the whole point of using SSE4.2 is to speed things up), but if it enables a more modern GPU to be fully functional, I'd expect the results to be far better than using an old ATI card...

It feels like I'm missing something obvious. Is there any technical reason this is a bad idea? Or is it perhaps just more trouble than it's worth? (Not that that's ever stopped me before... :rolleyes:)

(Apologies if this has already been addressed earlier; I've read quite a bit of this nearly-600-page thread, but not all of it.)
 
  • Like
Reactions: ASentientBot
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.