Jump to content

Hackintool v3.x.x

headkaze

By headkaze,
in Hackintosh Tools

 Share
1,057 posts in this topic

Recommended Posts

headkaze
headkaze
Posted
  • Author
Posted (edited)
15 hours ago, duffs said:

ok. So it looks like it's working, but it takes around 3 to 6 minutes to load.

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;
}

 

Edited by headkaze
  • Like 1
Link to comment
Share on other sites
  • 3 weeks later...
deeveedee
deeveedee
Posted
Posted (edited)

@headkaze Happy New Year!

 

I was reading the Hackintool 3.8.4 context-sensitive help for patched framebuffer Indices (below) and am more confused about connector indices than before I read your help.  In your help, you give an example "Say, we have 2 active ports" where connectors 0-3 are listed with indices 1, 2, 3, -1.   Why is this list of 4 connectors with 1 dummy connector only considered to be 2 active ports and not 3 active ports and a dummy?

 

EDIT: Is it because LVDS connector type must always have Index 0 (connector with type LVDS but non-zero Index is ignored)?

 

Hackintool 3.8.4 Context-Sensitive Help for patched framebuffer Indices

Spoiler

1031042093_ScreenShot2022-01-06at12_49_49PM.png.7c554d947b0949bb241ac9ef2855d39e.png

 

Edited by tonyx86
Updated Hackintosh version to 3.8.4
Link to comment
Share on other sites
headkaze
headkaze
Posted
  • Author
Posted
On 1/6/2022 at 1:03 PM, tonyx86 said:

@headkaze Happy New Year!

 

I was reading the Hackintool 3.8.4 context-sensitive help for patched framebuffer Indices (below) and am more confused about connector indices than before I read your help.  In your help, you give an example "Say, we have 2 active ports" where connectors 0-3 are listed with indices 1, 2, 3, -1.   Why is this list of 4 connectors with 1 dummy connector only considered to be 2 active ports and not 3 active ports and a dummy?

 

EDIT: Is it because LVDS connector type must always have Index 0 (connector with type LVDS but non-zero Index is ignored)?

 

Hackintool 3.8.4 Context-Sensitive Help for patched framebuffer Indices

Yes, LVDS must always be index 0.

 

The full document you should read is IntelFramebuffer.bt

  • Like 3
  • Thanks 1
Link to comment
Share on other sites
  • 2 weeks later...
miliuco
miliuco
Posted
Posted
43 minutes ago, kaoskinkae said:

Why the SSDT-EC-USBX.aml when creating it is called like that when it should be SSDT-USBX.aml since the EC is not included since the new versions?

OpenCore package has SSDT-EC-USBX.aml and SSDT-EC.aml but not SSDT-USBX.aml. I haven't read anywhere what you are saying.

  • Like 1
Link to comment
Share on other sites
miliuco
miliuco
Posted
Posted (edited)
3 hours ago, kaoskinkae said:

perfect public

 

I see, waiting for @headkazecomment.

 

I've been checking old versions, e.g. 3.6.0 and 3.4.0, and SSDT-EC-USBX file is always the same, only USBX part, it seems that Hackintool has built the same SSDT since the beginning.

We know that SSDT-EC-USBX is recommended for Skylake desktops and newer and AMD CPUs, SSDT-EC is for Broadwell and older. I don't know why Hackintool builts this so named SSDT-EC-USBX file. But I'm sure Headkaze has a valid explanation for it.

Edited by miliuco
Link to comment
Share on other sites
kaoskinkae
kaoskinkae
Posted
Posted
On 1/30/2022 at 1:30 AM, miliuco said:

@kaoskinkae

Your issue has been useful, Headkaze is going to add EC device to this SSDT. Really I haven't noticed this detail, you're more observant than me 🙂

You know that with the yotube channel and facebook and telegran in Spanish I don't stop investigating and giving support

image.png

  • Like 1
Link to comment
Share on other sites
  • 2 months later...
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

Is there a reason why there is no "Comet Lake" category in the dropdown menu for the creating Framebuffer patches or is the data just not implemented yet?

Link to comment
Share on other sites
joevt
joevt
Posted
Posted
11 minutes ago, 5T33Z0 said:

Is there a reason why there is no "Comet Lake" category in the dropdown menu for the creating Framebuffer patches or is the data just not implemented yet?

I don't think any Macs used Comet Lake.

macOS doesn't have Comet Lake drivers? See Intel Graphics Drivers at:

 https://forums.macrumors.com/threads/intel-graphics-and-5120x1440-testing-in-big-sur.2244174/

 

OpenCore has notes for Comet Lake so I guess it's supposed to work.

 https://dortania.github.io/OpenCore-Install-Guide/config.plist/comet-lake.html#starting-point

 

If you're using Comet Lake in a Hackintosh, what drivers does it say are loaded? 

kextstat | grep -i graphics

Maybe it uses Coffee Lake (CFL)?

Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted (edited)

@joevt Thanks for the explanation and the links.

 

As for GREP it spits out these results: 

steezo@iMac ~ % kextstat | grep -i graphics
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
  110   11 0xffffff7f9b13e000 0x2f000    0x2f000    com.apple.iokit.IOGraphicsFamily (585.2) 17732FC2-63ED-3059-B006-A492D276F99C <14 8 6 5 3 1>
  111    5 0xffffff7f99950000 0x4000     0x4000     com.apple.AppleGraphicsDeviceControl (6.3.6) 1151AFDA-B186-34D1-9675-D0901B34BE02 <110 14 8 7 6 5 3 1>
  113    0 0xffffff7f99dcd000 0xc1000    0xc1000    com.apple.driver.AppleIntelCFLGraphicsFramebuffer (16.0.5) 36017EC6-D31F-3F2E-9AD1-0D9E68ECF2E2 <112 111 110 42 14 13 8 7 6 5 3 1>
  124    0 0xffffff7f9a6ad000 0xb9000    0xb9000    com.apple.driver.AppleIntelKBLGraphics (16.0.5) D8AE3E77-5EEA-3DE4-8753-AADD31988F03 <112 110 87 14 8 7 6 5 3 1>
  136    1 0xffffff7f9993c000 0x1000     0x1000     com.apple.driver.AppleGraphicsControl (6.3.6) AEAE3F49-2C66-3BD0-BAA4-90BB45C99CCC <8 6 5 3 1>
  137    0 0xffffff7f99958000 0xa000     0xa000     com.apple.driver.AppleGraphicsDevicePolicy (6.3.6) 9AD8C808-E931-32FF-8826-BA30B5BDB3D1 <136 111 110 14 13 8 7 6 5 3 1>
steezo@iMac ~ %  ioreg -lw0 | grep "AAPL,ig-platform-id"
    | |   | |   "AAPL,ig-platform-id" = <07009b3e>
steezo@iMac ~ %  kextstat | grep Intel | egrep "Graphics|Framebuffer"
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
  113    0 0xffffff7f99dcd000 0xc1000    0xc1000    com.apple.driver.AppleIntelCFLGraphicsFramebuffer (16.0.5) 36017EC6-D31F-3F2E-9AD1-0D9E68ECF2E2 <112 111 110 42 14 13 8 7 6 5 3 1>
  124    0 0xffffff7f9a6ad000 0xb9000    0xb9000    com.apple.driver.AppleIntelKBLGraphics (16.0.5) D8AE3E77-5EEA-3DE4-8753-AADD31988F03 <112 110 87 14 8 7 6 5 3 1>

 

Edited by 5T33Z0
Link to comment
Share on other sites
joevt
joevt
Posted
Posted
1 hour ago, 5T33Z0 said:

@joevt Thanks for the explanation and the links.

 

As for GREP it spits out these results: 

steezo@iMac ~ %  kextstat | grep Intel | egrep "Graphics|Framebuffer"
  113    0 0xffffff7f99dcd000 0xc1000    0xc1000    com.apple.driver.AppleIntelCFLGraphicsFramebuffer (16.0.5) 36017EC6-D31F-3F2E-9AD1-0D9E68ECF2E2 <112 111 110 42 14 13 8 7 6 5 3 1>
  124    0 0xffffff7f9a6ad000 0xb9000    0xb9000    com.apple.driver.AppleIntelKBLGraphics (16.0.5) D8AE3E77-5EEA-3DE4-8753-AADD31988F03 <112 110 87 14 8 7 6 5 3 1>

Same as my Mac mini 2018 which is Coffee Lake.

 

55 minutes ago, badbrain said:

That's not right:

iMac20,1: https://everymac.com/ultimate-mac-lookup/?search_keywords=iMac20%2C1

iMac20,2: https://everymac.com/ultimate-mac-lookup/?search_keywords=iMac20%2C2

Thanks. I didn't do an extensive search - I was just going by the list of Intel*Graphics drivers. Now we know that Comet Lake uses Coffee Lake graphics drivers. Coffee Lake graphics drivers uses Kaby Lake graphics drivers for the parts that don't have a Coffee Lake version. The frame buffer part is Coffee Lake and so is the VAME part (whatever that is?). The other parts are Kaby Lake.

 

Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

@joevt Thanks. I was asking because a couple of days ago my GPU died and now I have to use the iGPU in the until the new card arrives. While booting with the Framebuffer patch for the iGPU, I notice some stalling before reaching the desktop. My guess it's due to the framebuffer for my i9 10850K isn't optimal, so I was looking into fine tuning it.

Link to comment
Share on other sites
rafale77
rafale77
Posted
Posted

In regards to Comet Lake, using the iMac20,2 SMBIOS, the PCIe section shows this:

 

I am using the headless iGPU framebuffer recommended by WEG: 9BC800003

which can also be found under the Hackingtool patch menu under coffee lake. I am guessing the device name below is purely hackintool cosmetic.

 

Note also some of the CPU devices being reported as a "Xeon" while others are correctly reported as "Comet Lake" by Hackintool... Maybe a database update for Hackintool is needed?

 

image.thumb.png.cdac1d5e996074e62f67d98902cd44f6.png

Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

@rafale77 In my case it's showing the correct CPU description. As far as the Frambuffer is Concerned, hackintool detects the Laptop version of th UHD 630 which irritates me, since it's an i9 CPU.

 

Anyway, the database for the PCI devices is included in the App in the Resources > PCI folder. It's called pci.ids. You can get the latest version of it from The PCI ID repository: https://pci-ids.ucw.cz/

Link to comment
Share on other sites
rafale77
rafale77
Posted
Posted
5 minutes ago, 5T33Z0 said:

@rafale77 In my case it's showing the correct CPU description. As far as the Frambuffer is Concerned, hackintool detects the Laptop version of th UHD 630 which irritates me, since it's an i9 CPU.

 

Anyway, the database for the PCI devices is included in the App in the Resources > PCI folder. It's called pci.ids. You can get the latest version of it from The PCI ID repository: https://pci-ids.ucw.cz/

 

Thanks! Just tried installing it but the result is the same. It is odd that your CPU description is correct and not mine. What framebuffer did you inject? That could be the reason why you are getting a Laptop UHD630.

The only Mac with Comet Lake is the iMac20,x which uses its iGPU headlessly. If you are going to use for display you would be better off using a coffee lake framebuffer like 3E9B0007 and patch the connectors. I have tried both on my machine and it works.

 

Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

@rafale77 I am using the one mentioned in the OpenCore Install Guide for Coemt Lake, when using the iGPU for driving a display: AAPL,ig-platform-id 07009B3E. Which, according to Whatevergreen's Intel HD Faq is for a desktop (0x3E9B0007). That's the one you mentioned. My GPU is dead and I am still waiting for a replacement. So in the meantime I have to use the iGPU. I was shocked how bad its performance is in Davinci Resolve when performing the simplest of tasks.

 

I just realized that you can update the pci.ids file from within Hackintool itself (there's a download icon on th the PCI tab), so there's no need to update it manually.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...