[Guide] Intel Framebuffer patching using WhateverGreen

[headkaze]

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.

The reason I wanted to use the port-number value instead of AppleIntelFramebuffer@X was because I wanted the user to be able to either drag and drop connectors to change the order or change the index value and it would show visually which connector the display would move to.

So from what you've investigated the general rule is SNB/IVB: port-number + 3 = Connector Index and HSW+: port-number + 4 = Connector Index?

 

[Mison]

Attached is a shell script you can run which will download and compile the latest Lilu + WhateverGreen and place the kexts into a folder called Debug and Release.

Hi,your script work well with Xcode9.4.1.But when I update Xcode to 10.0,the script build failed.
Are there some error in the sctipt that cannot be compiled by Xcode 10.0?

 

[RehabMan]

The reason I wanted to use the port-number value instead of AppleIntelFramebuffer@X was because I wanted the user to be able to either drag and drop connectors to change the order or change the index value and it would show visually which connector the display would move to.

But the connector (eg. framebuffer@X) is always determined by position within the connector array.

So from what you've investigated the general rule is SNB/IVB: port-number + 3 = Connector Index and HSW+: port-number + 4 = Connector Index?

Except for index 0, which is port-number=0.
I should probably also test the VGA connector (06020000 00010000 09000000) and see if it ends up port-number=9.

 

[headkaze]

But the connector (eg. framebuffer@X) is always determined by position within the connector array.

Yes but say I have a display on con0 / framebuffer@0 and swap con0 data with con1 and reboot then the display will now be on con1 / freambuffer@1 right? If I'm to show that graphically in Intel FB-Patcher I can't use the connector index -> framebuffer@X otherwise when you swap con0 data with con1 and refresh the NSTableView the display will still show as being on con0.

 

[RehabMan]

Yes but say I have a display on con0 / framebuffer@0 and swap con0 data with con1 and reboot then the display will now be on con1 / freambuffer@1 right? If I'm to show that graphically in Intel FB-Patcher I can't use the connector index -> framebuffer@X otherwise when you swap con0 data with con1 and refresh the NSTableView the display will still show as being on con0.

Correct. Your app would need to become aware of the patching that is affecting the ioreg result.

You should also deal with the case of the user adding a connector that didn't exist in the native connector array. This can happen in two ways: adjusting port count and patching the unused slot(s) at the end, or by replacing an existing connector with data representing a connector that wasn't there at all in the native connector array. That might be a bit tricky...

The patch data for WhatefverGreen is in ioreg, so you could take that into account... That would not handle the case of patching via KextsToPatch though (hopefully users abandon KextsToPatch for framebuffer patching).

 

[headkaze]

You should also deal with the case of the user adding a connector that didn't exist in the native connector array. This can happen in two ways: adjusting port count and patching the unused slot(s) at the end, or by replacing an existing connector with data representing a connector that wasn't there at all in the native connector array. That might be a bit tricky...

You can edit all the connector data in the app including adding a previously disabled connector. Yes and you would have to increase the port-count. Not sure about the pipe-count value though. Does that need to be changed also?

The patch data for WhatefverGreen is in ioreg, so you could take that into account... That would not handle the case of patching via KextsToPatch though (hopefully users abandon KextsToPatch for framebuffer patching).

I could read in the WhateverGreen data from the IGPU entry in ioreg and display the user's current patches but I think that might get a little confusing for the user. I really only wanted to show where the display would move to if they changed connector data in the event they wanted to re-organize the order of connectors (and possibly disable unused ones).

 

[RehabMan]

You can edit all the connector data in the app including adding a previously disabled connector.

Great. But I still don't understand why you're looking at ioreg as you mention below you're not displaying the user's current patches...

Yes and you would have to increase the port-count. Not sure about the pipe-count value though. Does that need to be changed also?

I usually look at existing framebuffer data that has the same number of active connectors and follow that guidance.
I don't really understand the relationship between pipe count, port count, and memory count. The patterns you see in existing data doesn't really make much sense.

I could read in the WhateverGreen data from the IGPU entry in ioreg and display the user's current patches but I think that might get a little confusing for the user.

It is probably a good option to have... maybe a menu item or button that 'apply current patches'.

I really only wanted to show where the display would move to if they changed connector data in the event they wanted to re-organize the order of connectors (and possibly disable unused ones).

But if you're always starting from native data (not taking into account patches already present/active due to WhateverGreen patching), then what does current ioreg matter?

 

[headkaze]

Great. But I still don't understand why you're looking at ioreg as you mention below you're not displaying the user's current patches...

To show the user what displays are connected and to what connectors.

I usually look at existing framebuffer data that has the same number of active connectors and follow that guidance.
I don't really understand the relationship between pipe count, port count, and memory count. The patterns you see in existing data doesn't really make much sense.

IntelFramebuffer.bt has a lot of explanations but pipe count is one of the data elements it does not seem to explain.

It is probably a good option to have... maybe a menu item or button that 'apply current patches'.

It's a good idea I'll definitely consider it.

But if you're always starting from native data (not taking into account patches already present/active due to WhateverGreen patching), then what does current ioreg matter?

I read a lot of data out of ioreg to display info about the system. I'm just trying to make the process of patching as easy as possible. I wrote this tool originally to help me (and other users) try different patches to see if we could fix the 3 minute black screen issue. So far no luck but since others have found the tool useful I'm continuing to add features and update it.

 

[RehabMan]

To show the user what displays are connected and to what connectors.

In order to do that, you will absolutely need to take into account patches applied.

IntelFramebuffer.bt has a lot of explanations but pipe count is one of the data elements it does not seem to explain.

Yeah, I've read through that file...

I read a lot of data out of ioreg to display info about the system. I'm just trying to make the process of patching as easy as possible. I wrote this tool originally to help me (and other users) try different patches to see if we could fix the 3 minute black screen issue. So far no luck but since others have found the tool useful I'm continuing to add features and update it.

Hope you find a fix for the 3-minute blackout problem.
Might want to dump some of the critical IGPU registers during that time (and after).
AppleIntelInfo.kext could be easily modified for that purpose.

 

[headkaze]

Might want to dump some of the critical IGPU registers during that time (and after).
AppleIntelInfo.kext could be easily modified for that purpose.

That's a great idea, thanks I'll give that a try.