Contribute
Register

[Guide] Intel Framebuffer patching using WhateverGreen

I just released an update to Intel FB-Patcher which fixes this. If you ever get a chance to test it I'd much appreciate it.

Just tested the new version, the indicators are really helpfull. Another idea from my side would be, if you select FB Port Limit and there is an used connector, it should propaply use that one? Or an option to disable all unused connectors would make it more easy.
 
Okay thanks for that. The only two machines I had to test just happened to match that way. I'll roll out a fix for it.

Sandy Bridge even stranger:
0205, port-number=5
0304, port-number=6
0406, port-number=7

I can check a little later on Ivy Bridge.

I'm starting to wonder if they are just sequentially assigned starting at 5 (except for the special LVDS connector).
I should try mixing up the order and see what happens... (I think I tried that one time, but can't remember the result now).

The best way to map from what you see in ioreg to data in the framebuffer, is to rely on the framebuffer node name, eg. *framebuffer@X. The X directly corresponds to the X in framebuffer-conX-*.

This information was taken directly from the AppleLife forum. Okay I'll change it to FakePCIID_Intel_HD_Graphics

Thanks for the change. It has caused a bit of confusion in some USB guides.

I just released an update to Intel FB-Patcher which fixes this. If you ever get a chance to test it I'd much appreciate it.

There are a lot of things on my list currently, but yeah, eventually I'll try your app.
 
Sandy Bridge even stranger

Hmm, that is strange. Looking at IntelFramebuffer.bt it states:
Code:
    * It is also used for port-number calculation.
     * - LVDS displays (more precisely, displays with CNConnectorAlwaysConnected flag set) get port-number 0.
     * - Other displays go through index - port-number mapping: 1 - 5, 2 - 6, 3 - 7, or fallback to 0.
     */

Which seems to correlate your findings of port-number = index + 4 unless internal in which case it's 0. But perhaps it's something different for SNB?

I'm starting to wonder if they are just sequentially assigned starting at 5 (except for the special LVDS connector). I should try mixing up the order and see what happens... (I think I tried that one time, but can't remember the result now).

It would certainly be useful to know if changing the index changes which AppleIntelFramebuffer the display is located under. If not I may need to use the AppleIntelFramebufer@X value as you suggest.

The best way to map from what you see in ioreg to data in the framebuffer, is to rely on the framebuffer node name, eg. *framebuffer@X. The X directly corresponds to the X in framebuffer-conX-*.

Not sure how to get the AppleIntelFramebufer@X value. Maybe there is a value in AppleIntelFramebuffer that also corresponds to the index? IOFramebufferOpenGLIndex, IOAccelIndex and IOFBDependentIndex look like likely candidates. I could also just use my own index when enumerating them. EDIT: Looks like the X value in AppleIntelFramebufer@X can be obtained by using IORegistryEntryGetLocationInPlane.
 
Last edited:
Hmm, that is strange. Looking at IntelFramebuffer.bt it states:
Code:
    * It is also used for port-number calculation.
     * - LVDS displays (more precisely, displays with CNConnectorAlwaysConnected flag set) get port-number 0.
     * - Other displays go through index - port-number mapping: 1 - 5, 2 - 6, 3 - 7, or fallback to 0.
     */

Which seems to correlate your findings of port-number = index + 4 unless internal in which case it's 0. But perhaps it's something different for SNB?

Different for SNB. Will check Ivy too (maybe it is different too).
I don't think it is useful to attach much meaning to the port-number property.

It would certainly be useful to know if changing the index changes which AppleIntelFramebuffer the display is located under. If not I may need to use the AppleIntelFramebufer@X value as you suggest.

I'll experiment with it (out of order connectors) and report back.
 
Framebuffer patching in Mojave
Binary patching framebuffers using KextsToPatch in Clover is no longer a viable method in Mojave for Skylake and above. Now you need to use Lilu + WhateverGreen.

If my UHD 630 (running in headless mode with Lilu + WhateverGreen on 10.4 GM) is perfectly recognized, do I need to apply the patch?
 
I don't think it is useful to attach much meaning to the port-number property.

Yeah I agree. I did another update to Intel FB-Patcher and now I associate the connector index with AppleIntelFramebuffer@X
 
I'm working on 10.14 and having troubles with loading system. Sometimes it working normally, but sometimes I need to wait 3 min to light up display. It's because of eDP connection in Lenovo Legion Y530.
To patch the LVDS connector for DP I just need to uncheck CNConnectorAlwaysConnected flag and add framebuffer-conX-enable + framebuffer-conX-alldata?
 
I'm working on 10.14 and having troubles with loading system. Sometimes it working normally, but sometimes I need to wait 3 min to light up display. It's because of eDP connection in Lenovo Legion Y530.
To patch the LVDS connector for DP I just need to uncheck CNConnectorAlwaysConnected flag and add framebuffer-conX-enable + framebuffer-conX-alldata?

You can change the LVDS at position 0 to DP with framebuffer-con0-type = <00040000>
Flags can be changed similarly (if needed) with framebuffer-con0-flags.
 
I'm working on 10.14 and having troubles with loading system. Sometimes it working normally, but sometimes I need to wait 3 min to light up display. It's because of eDP connection in Lenovo Legion Y530.
To patch the LVDS connector for DP I just need to uncheck CNConnectorAlwaysConnected flag and add framebuffer-conX-enable + framebuffer-conX-alldata?

The 3 minute black screen is still not resolved. For 10.14 I don't recommend people unset the CNConnectorAlwaysConnected flag since you're just making your internal screen into an external. This was only a stop-gap solution for 10.13 but for 10.14 we just have to wait for now. As soon as the issue is resolved I will be posting about it in this thread. If you discover anything please also feel free to post your results there.
 
Sandy Bridge even stranger:
0205, port-number=5
0304, port-number=6
0406, port-number=7

I can check a little later on Ivy Bridge.

I know you've moved past this and are just using the framebuffer@X idea (which is best), but FYI: Ivy Bridge is the same.

I'm starting to wonder if they are just sequentially assigned starting at 5 (except for the special LVDS connector).
I'll experiment with it (out of order connectors) and report back.

And also, I switched up the order of connectors on this HD4000 laptop (ProBook 4540s), and the port-number assignments follow the connector data. So it is not sequential assignment, but related to the connector data.
 
Back
Top