[Release] Hackintool v3.x.x

[headkaze]

As long as it's possible to compare the Actual/detected IGPU Info to the Framebuffer Info I think that will do the Job, could you also include Model/SMBIOS (Current) as well ?

Maybe also put a line separator between the Framebuffer Info and the Current Info just to make it easer to read ?

How about this?

If the list will shows PlatformID/FrameBuffer Info as well as the Current PlatformID/Framebuffer Info would there be any need for the "Mine" button ?

I still think the "Mine" (renamed to "Go to Current") button is useful.

 

[jaymonkey]

How about this?

That looks good buddy ...

looks even better than what we had before ...
Clearer but with the same info laid out in a more concise way with VRAM info on its own tab .... nice !

Cheers
Jay

 

[headkaze]

Hackintool v2.4.1 Released
- Chinese language update

Hackintool v2.4.2 Released
- Changed Framebuffer Info to Selected / Current Framebuffer Info for easier comparison

 

[zzmadd]

Those three are optional VRAM settings. They are controlled by the following checkboxes:

• DVMT pre-alloc 32MB: This is specified by "fbmem" and "stolenmem"
• VRAM 2048MB: This is specified by "unifiedmem"

Some motherboards do not provide a DVMT Pre-Alloc option in BIOS, so bullet #1 solves that problem. And for users of multiple monitors and hi-DPI monitors (4K, 5K) it is better to provide 2048MB of VRAM to the iGPU, hence bullet #2.
View attachment 403480

Just as a follow up.
After redoing the config and updating to Bios 1.10 on the ASRock Z390M-ITX I didn't have any freeze or reboot.

Having said that by adding:
[*]DVMT pre-alloc 32MB: This is specified by "fbmem" and "stolenmem"
Upon reboot the screen couldn't do 4k anymore. I had graphics stuck on 2560x1440.
By removing those two lines I got back to being able to use 4k.

[*]VRAM 2048MB: This is specified by "unifiedmem"
I'm running this option now, let's see what happens beside seeing 2048MB Video memory.

One thing that happens though is after a Final Cut Pro X ProRes + H264 render once I Log Out of the user I get a black screen. If with the same settings I Log In then I Log Out then I can correctly see the Log In window with the Users options.

Thanks!

 

[Henties]

For longer than I can remember, perhaps 2 years now, I have been using the codeless USB configuration method on both of my hacks per my signature. It was a lot of work, reading and sticking all the bits and pieces together "by hand" to make this all work. Recently I decided to have a closer look at Hackintool and was pleasantly surprised to what it can do and took it for a good spin around it's codeless USB kext generation routines. They work very well but still need a bit polishing up. The USBPorts.kext, which was generated for a SMBIOS 14.2 Haswell build, for this particular system definition running Mojave, includes current configuration settings which are not needed and only duplicate what is already available in the OS. The contents of the attached folder "Codeless USB Haswell-14.2.zip" contains two files. one generated by hand and the other by Hackintool 2.4.1 Comparing the 2 files should reveal that the charge current definitions should not be included.
On the Skylake build with system def. 17.1 it is in order to have the current definitions resident in the codeless
USBPorts.kext. With those settings resident one should, if present, remove the SSDT-USBX.aml kext from Clover/patched as that kext also contains these current definitions, thereby avoiding duplication.
My Skylake board uses one XHC controller for USB-2 as well as USB-3 ports and another separate one for two USB-3.1 (red) ports. When one uses the Hackintool generated USBPorts.kext, devices connected to these (red) ports stop functioning. I avoided this problem, at least that is what I seem to recollect, by also including the controller device-id in my version of the codeless USB kexts, thereby limiting the "goings on" to the desired controller only.
Comparing the contents of the 2 kexts present in the attached Skylake zip folder should make it clearer to what I originally needed to do to get my codeless Skylake kext working reliably.
Hope this will be helpful during the further development of the amazing Swiss knife Hackintool.

Greetings

 

[jaymonkey]

@headkaze,

Nice job with the updated IGPU -> Info page in V 2.4.2 ... looks good.
Will update Lilu + Plug-in's guide with new Hackingtool screen grabs.

Cheers
Jay

 

[headkaze]

For longer than I can remember, perhaps 2 years now, I have been using the codeless USB configuration method on both of my hacks per my signature. It was a lot of work, reading and sticking all the bits and pieces together "by hand" to make this all work. Recently I decided to have a closer look at Hackintool and was pleasantly surprised to what it can do and took it for a good spin around it's codeless USB kext generation routines. They work very well but still need a bit polishing up. The USBPorts.kext, which was generated for a SMBIOS 14.2 Haswell build, for this particular system definition running Mojave, includes current configuration settings which are not needed and only duplicate what is already available in the OS. The contents of the attached folder "Codeless USB Haswell-14.2.zip" contains two files. one generated by hand and the other by Hackintool 2.4.1 Comparing the 2 files should reveal that the charge current definitions should not be included.
On the Skylake build with system def. 17.1 it is in order to have the current definitions resident in the codeless
USBPorts.kext. With those settings resident one should, if present, remove the SSDT-USBX.aml kext from Clover/patched as that kext also contains these current definitions, thereby avoiding duplication.
My Skylake board uses one XHC controller for USB-2 as well as USB-3 ports and another separate one for two USB-3.1 (red) ports. When one uses the Hackintool generated USBPorts.kext, devices connected to these (red) ports stop functioning. I avoided this problem, at least that is what I seem to recollect, by also including the controller device-id in my version of the codeless USB kexts, thereby limiting the "goings on" to the desired controller only.
Comparing the contents of the 2 kexts present in the attached Skylake zip folder should make it clearer to what I originally needed to do to get my codeless Skylake kext working reliably.
Hope this will be helpful during the further development of the amazing Swiss knife Hackintool.

Greetings

Thanks, I appreciate you taking the time to let me know. Could you please run "ioreg -l >ioreg.txt" from Terminal on both machines and attach the result here. Hopefully you can stick around and test a new release to see if I can solve this issue with you.

 

[Henties]

Could you please run "ioreg -l >ioreg.txt" from Terminal

Done one from my Haswell build and the other from my Skylake build, both contained in " ioreg txt.zip" attached.
Good luck

 

[jaymonkey]

@headkaze,

Just been updating the Lilu + Plug-in's guide with new screen shots of Hackingtool V2.4.2 and unless i'm mistaken (and its some where else) it no longer shows QI/CI, Metal and VDA Status ?

Maybe add it to Patch -> Info -> Current Framebuffer Info List ?

Cheers
Jay

 

[headkaze]

Just been updating the Lilu + Plug-in's guide with new screen shots of Hackingtool V2.4.2 and unless i'm mistaken (and its some where else) it no longer shows QI/CI, Metal and VDA Status ?

Have you checked out the new Info area?