headkaze

Yes, LVDS must always be index 0. The full document you should read is IntelFramebuffer.bt

Yes unfortunately if I can't find a 3rd party Bluetooth device in IORegistry I'll call "system_profiler SPBluetoothDataType -xml" to see if there are any native Bluetooth devices. I try to avoid calling shell commands as much as possible for this reason but I have yet to find a reliable way to get a list of native Bluetooth devices on a system. In the Hackintool function getNativeBluetoothDeviceInfo() I need to find devices that Chipset is not determined to be a "THIRD_PARTY_DONGLE". The problem is macOS will open the USB device in exclusive mode so I cannot simply discover the chipsetID and determine it the way bluetoothd does. Once we have the ChipsetID we know that bluetoothd simply checks against a list of hard-coded id's: const char *getBluetoothChipset(int chipsetID) { const char *result; if (chipsetID > 1999) { switch (chipsetID) { case 2000: return "APPLE_M1"; case 2001: return "APPLE_M2"; case 2002: return "APPLE_M2_5"; default: return "Unknown Chipset"; } } else { result = "THIRD_PARTY_DONGLE"; switch (chipsetID) { case 0: return result; case 1: result = "BCM_4350C2"; break; case 2: result = "BCM_20702A3"; break; case 3: result = "BCM_20702B0"; break; case 4: result = "BCM_4350"; break; case 5: result = "BCM_4350A0"; break; case 6: result = "BCM_4350C5"; break; case 7: result = "BCM_20703A1"; break; case 8: result = "BCM_20703A2"; break; case 9: result = "BCM_43430"; break; case 10: result = "BCM_43452"; break; case 11: result = "BCM_4355B3"; break; case 12: result = "BCM_4355C0"; break; case 13: result = "BCM_4355C1"; break; case 14: result = "BCM_4355"; break; case 15: result = "BCM_4357"; break; case 16: result = "BCM_4364"; break; case 17: result = "BCM_4364B0"; break; case 18: result = "BCM_4364B3"; break; case 19: result = "BCM_4377"; break; case 20: result = "BCM_4378"; break; case 21: result = "BCM_4387"; break; default: return "Unknown Chipset"; } } return result; }

Any chance you can run it in Xcode to determine where it's hanging?

Should be fixed in the latest release

Please try v3.7.5

My guess is an exception is occurring on startup. Can you run it from Terminal and post the log here.

Thanks for your updated kexts.plist I'll add it to the next release. Being hosted on Github anyone can make an update and perform a pull request for me to merge and release to everyone.

Please try science.firewolf.rtsx and science.firewolf.rtsf. It probably does work with the short version but I prefer it's more specific. If it works I'll add it.

You need to add the bundle id's to the kext.plist.

You need to add the bundle id's. When you get these working I'll add them to the repo.

It was a double de-allocation bug that only showed up for some users. Either way it's fixed now

@SavageAUS @jsl2000 Can you guys please try 3.6.1. I'm guessing I fixed the issue but I don't have Monterey installed to test it just yet.

Thanks for the heads up. I'll have a look asap.

I agree with your point so I've changed it back. Please check out 3.6.0.

Yes but it only shows the hex dump of the connectors. You can take a look at the "struct FramebufferCFL" entry in IntelFramebufer.bt to see how the data is structured in Coffee Lake.bin and then search for the framebuffer id. Attached is a screenshot showing the id and connector data highlighted.