[Guide] Intel Framebuffer patching using WhateverGreen

[RehabMan]

Technically integer's are supported (they will convert to 4 byte data internally) but data is the recommended way.

I looked in the WhateverGreen code and didn't see any handling for OSNumber.
Didn't realize that Clover was doing some conversion here.
Of course, if you inject with ACPI, you can inject as integer (Number as seen in ioreg), and since there is no handling in WhateverGreen, it won't work.
So technically, WhateverGreen cannot deal with integers that it finds in ioreg... but integers you put in config.plist/Devices/Properties will be converted to 32-bits of Data type.

Good to know...

That said, it is a bit more readable using integers:
(example from my NUCi7KYK)

Note result in ioreg is still Data, which is why it works (conversion done before WhateverGreen deals with it):

 

[headkaze]

That said, it is a bit more readable using integers

Originally I had the examples using integer's but a few developers asked me to change them to use data to avoid confusion. So you may see some people still using them.

Did you add a requirement for framebuffer-con0-enable to be set to use framebuffer-con0-alldata? If so I need to update my example.

Also I see framebuffer-con0-19260000. Can you please explain the purpose of this patch type?

 

[RehabMan]

Did you add a requirement for framebuffer-con0-enable to be set to use framebuffer-con0-alldata? If so I need to update my example.

It was always a requirement, just like other conX properties.

Also I see framebuffer-con0-19260000. Can you please explain the purpose of this patch type?

Is actually, framebuffer-con0-19260000-alldata (Xcode is just truncating due to column width).

see pr #7: https://github.com/acidanthera/WhateverGreen/pull/7

(you may be interested in pr #8 too)

Both won't come until 1.2.3.

 

[headkaze]

see pr #7: https://github.com/acidanthera/WhateverGreen/pull/7

Okay I think I'll leave out framebuffer-con0-XXXXXXXX-alldata explanation in the guide to avoid confusion since it has a special-case usage.

 

[Kinxz]

Connector patches are zero-based. So to patch the first connector use "con0".

I also recommend people try Intel FB-Patcher (with Framebuffer->macOS 10.13.6 (17G2112) menu option). It has a GUI that makes patching easier.

Values for the properties must be specified as type <data>. You're trying to use <integer> (shown as Number in Xcode), which is not supported.

See examples in post #1.

I changed it to con0 and converted the values to type <data> but it still doesn't work. Looks like it is booting up, but no output on display when getting to the login screen.

 

[RehabMan]

I changed it to con0 and converted the values to type <data> but it still doesn't work. Looks like it is booting up, but no output on display when getting to the login screen.

What patch(es) were you previously using with KextsToPatch?

 

[Kinxz]

What patch(es) were you previously using with KextsToPatch?

On my High Sierra partition I am using this config, with IntelGraphicsFixup kext.

 

[headkaze]

I changed it to con0 and converted the values to type <data> but it still doesn't work. Looks like it is booting up, but no output on display when getting to the login screen.

Looking in Intel FB-Patcher I see that connector 0 for that frame has an index of -1. That could be disabling the port.

 

[Kinxz]

Looking in Intel FB-Patcher I see that connector 0 for that frame has an index of -1. That could be disabling the port.

Indeed, I updated the config.plist and changed the index, but still no success

 

[headkaze]

On my High Sierra partition I am using this config, with IntelGraphicsFixup kext.

To match that patch you should be setting portcount to 4 and removing pipecount entry.