I'll reply for
@MyTosh - The answer is Yes - tested and running great on the following systems:
- 2015 Macbook Pro with 10.13.6; 10.14.2; and 10.14.3
- 2013 Mac Pro (trashcan) 10.12.6; 10.13.4; 10.13.6; 10.14.2; and 10.14.3
Screenshot attached
(can you tell I'm eager to figure this out?
).
Also attached is a screenshot that has a VRS8 (with driver installed) and the UAD Apollo daisy chained to the VRS8 (with NO driver installed. It's weird how VRS8 behaves as if there is no driver attached.
Are you saying the PCIe card is working in the Mac Pro?
@MyTosh said other people were not able to get it to work.
run these following command on the Mac Pro, MacBook Pro, and Hackintosh:
Code:
ioreg -lw0 > ioregMacPro.txt
ioreg -lw0 > ioregMacBookPro.txt
ioreg -lw0 > ioregHackintosh.txt
zip the resulting .txt and post here.
I tried to unload the kext as per your instructions yesterday but was unsuccessful.
My instructions were to remove the kext. Did you do that?
EDIT:
@joevt I also ran a test, where I attach the VRS8 to the Macbook Pro and did a IORegistry dump. Take a look at the screenshot. That
net_egosys_driver_VRS8Audio and everything that it includes gets attached to the
PCI1412,1724@0 on a real mac, versus the driver failing to load on a Hack.
I wonder why it didn't get attached to PCI1412,1712@1 as that is one of the IOPCIPrimaryMatch. Maybe the subsystem-vendor-id and subsystem-id of that function don't match the IOPCISecondaryMatch?
The info.plist has "0x52413031&0xFFFFFFFF". "&0xFFFFFFFF" is redundant because that is the default mask for IOPCIMatch, IOPCIPrimaryMatch, and IOPCISecondaryMatch. That shouldn't be a problem.
Your screen shots shows the subsystem-vendor-id and subsystem-id of PCI1412,1712@1 as formatted as "10" and "AR" instead of "31 30 00 00" and "41 52 00 00". I think they are the same values (hex vs ascii) and anyway, I think the code reads the values from the registers directly instead of those IORegistry properties so it shouldn't be a problem.
As an experiment, I would try removing IOPCISecondaryMatch from the info.plist. And for Thunderbolt, I would try removing the VRS8AudioDriver personality or adding the IOPCIPauseCompatible and IOPCITunnelCompatible properties to it.
The net_egosys_driver_VRS8Audio::initHardware(IOService*) function appears to look for properties "IOPCITunnelled" and "Thunderbolt Path" and "Depth" but I don't know what happens if they are found or not found.
Either the Thunderbolt in a hackintosh has to look more like the Thunderbolt in a real Mac (having those missing properties) or the driver needs to be fixed to be more forgiving of the environment. Really, there driver should not be looking for those properties.
Maybe a codeless kext (just an info.plist) can be created to add the missing properties to the right places.