Contribute
Register

[Release] Hackintool v3.x.x

Yeah it was a long shot as we're dealing with a completely different framebuffer kext, frame and layout. Who created the original patch? Did they create it through trial and error or is there some method to the madness? I'd do a bit more research into it and maybe it can tell us more about why the patch is the way it is and possibly what you need for the new patch.

PS It would also be worth adding your GPU to your profile.

EDIT: I just noticed a bug in Intel FB-Patcher. It does not appear to be adding the framebuffer-patch-enable entry. I will do an update and release soon.

It was a trial and error process by someone.
And to be honest the patch doesn't really fully work, meaning:
- I have acceleration on 10.13 only on the HDMI port I have attached at boot
- Dual monitor doesn't work
- If I switch to the second HDMI port after boot the image doesn't show up
- If I boot with 2 monitors connected only one works
- Removing any of the 3 patch lines compromises the whole patch. Either I have all of 3 enabled or they don't work
I think it's an improper implementation and we're yet to find a proper setup in both 10.13 and 10.14.
Is there a way to gather info in Windows on how the iGPU is configured?

Thanks for your help!
 
Last edited:
just wanted to update my progress again with this amazing tool. my DisplayPort was kernel panicking my system on boot. After like 2 days I figured out it was because of that SKLframebuffer patch. Now I applied it to kernel kext and patches. Ran FB patcher and was able to figure out my Displayport was not showing up on Fbpatcher's connectors list. all I did was change the -1 to a 3 and bam my DisplayPort popped up. lol just applied the patch to my config and now I can boot into high serria and Mojave on my intel graphics (as I wait for my Vega 64 to come lol) with my DisplayPort pluged in!.
 
I think it's an improper implementation and we're yet to find a proper setup in both 10.13 and 10.14.
Is there a way to gather info in Windows on how the iGPU is configured?

Yeah I don't think it's the correct patch but he obviously stumbled upon something that semi-worked for your system. Unfortunately we don't know much about these values except what has been reversed engineered by developers in the community. The best documentation we have is in IntelFramebuffer.bt (look at the ConnectorInfo struct). Pipe for example "Appears to be used for grouping ports" and BusId is the GMBUS (Graphic Management Bus) used to access/control devices connected to the GPIO pins.

For a moment I thought the patch was just re-ordering the connectors so I was going to suggest you just click-drag the order of the connectors for the 0x3E9B0007 frame in FB-Patcher but there is more to it than that. I can only imagine the number of times he changed the patch and rebooted until it actually worked.

Anyway the point of writing Intel FB-Patcher is so that anyone can tinker with the values and hopefully discover some way to get their system working to share with others.

It might be worth trawling through Linux source code and Intel documentation such as intel-gfx-prm-osrc-bxt-vol07-display.pdf.
 
Last edited:
Something interesting I just discovered about the pipe value. I've only ever seen values of 3, 8, 9, 10 and 11. If you look at these values in binary you will see only the first 4 bits are used. So I'm thinking this is actually a bitfield value.
Code:
Pipe|Bits|Type(s)
3   |0011|DP, HDMI
8   |1000|DP, LVDS
9   |1001|DP, HDMI, DigitalDVI
10  |1010|DP, HDMI
11  |1011|DP

So a good start would be to find out what each bit means. Something to do with display pipe A/B/C/D perhaps? See this blog post for possibly more info related to this.
 
Last edited:
I think I am going to try a system reinstall.
 
Last edited by a moderator:
So I'm thinking this is actually a bitfield value.
Code:
Pipe|Bits|Type(s)
3   |0011|DP, HDMI
8   |1000|DP, LVDS
9   |1001|DP, HDMI, DigitalDVI
10  |1010|DP, HDMI
11  |1011|DP

Come to think of it, it may not be a bitfield, if you take the first two bits you have 00 (0), 01 (1), 10 (2) and 11 (3) we could infer that they are pipe A, B, C and D respectively. Not sure about the other two bits though.
 
Last edited:
It was a trial and error process by someone.

Your motherboard is a Gigabyte B360N right? It has 2 HDMI ports and that's it. So I would try and patch something like this (attached) or some variation of it. If it doesn't work maybe try setting more values back to defaults. But I think this is closer to what you need.

If we could find out what ports are used for the B360N's HDMI connectors (A, B, C or D) then it might help us figure out which values we need to make it work. I'm not sure where we could find such detailed documentation though.
 

Attachments

  • 3KextsPatch.png
    3KextsPatch.png
    468.3 KB · Views: 401
Last edited:
Your motherboard is a Gigabyte B360N right? It has 2 HDMI ports and that's it. So I would try and patch something like this (attached) or some variation of it. If it doesn't work maybe try setting more values back to defaults. But I think this is closer to what you need.

If we could find out what ports are used for the B360N's HDMI connectors (A, B, C or D) then it might help us figure out which values we need to make it work. I'm not sure where we could find such detailed documentation though.
Hi, thanks very much for your extended help!!

Yes, exactly. My Board is the gigabyte B360N WiFi with 2 HDMI ports!!
In a couple of my tests I tried setting the number of ports to 2 and DP to HDMI in the Patch / Advanced tab.
But I'm not sure it's the way to go. I don't know the app.
I'm going to test these new settings soon and report.

Thanks again!
 
Version 1.4.7 Released
- Added support for new WEG -igfxfbdump boot flag using File->Import->IOReg Dump menu
 
Back
Top