[Guide] Intel Framebuffer patching using WhateverGreen

[headkaze]

I'd rather transition to a patching method that is NOT conditional on existing data in the kext ig-platform table. Doing the same without using find/replace, requires 27 property injections (3x for header data, and 6x per each of the 4 connectors). Yuck!

How is the find/replace in WhateverGreen any different to how you were using it with your KextsToPatch patch?

I'd rather transition to a patching method that is NOT conditional on existing data in the kext ig-platform table. Doing the same without using find/replace, requires 27 property injections (3x for header data, and 6x per each of the 4 connectors). Yuck!

I'll look into the necessary changes for WhateverGreen, and submit a PR when ready.

I'd rather the patching code remain simple and your fringe case require 27 property patches (or just use the find/replace method like you had before). But be my guest and submit a PR if you like.

Side note: It was a bit of a surprise to have all connectors patched by default to HDMI. This computer has 2x DP, and 1x HDMI. Took me a bit of head scratching to figure why all connectors had changed to HDMI without my doing any patching to the framebuffer! Eventually figured I needed -igfxnohdmi to turn off this default/undesired behavior of WhateverGreen.

I'm not entirely sure why it's the default to patch that. You could always post on the insanely forums and ask there.

 

[RehabMan]

How is the find/replace in WhateverGreen any different to how you were using it with your KextsToPatch patch?

Not different.
But with the transition to WhateverGreen.kext, I'd like to get away from matching patches with versions/changes of the system kexts themselves.
I want to replace the entire connector data unconditionally.

I'd rather the patching code remain simple and your fringe case require 27 property patches (or just use the find/replace method like you had before). But be my guest and submit a PR if you like.

Will do.
I don't see it adding any extra complexity.
Removing the leading LVDS connector for computers without LVDS displays is not fringe.

I'm not entirely sure why it's the default to patch that. You could always post on the insanely forums and ask there.

Probably too late to change now, that it is already that way in the field (therefore new versions must retain that behavior to avoid surprising those that are now dependent on it).

 

[headkaze]

Removing the leading LVDS connector for computers without LVDS displays is not fringe.

Why can't you just change the "type" of connector then?

I don't see it adding any extra complexity.

One way you could do it is to add a famebuffer-con-data / framebuffer-con-offset which just overwrites the connector data at the offset (with the offset being optional with a default of 0). That should cover your needs.

 

[RehabMan]

Why can't you just change the "type" of connector then?

The other data associated with that connector also needs to change. In addition to Type,... Index,BusId,Pipe,Flags also change.

One way you could do it is to add a famebuffer-con-data / framebuffer-con-offset which just overwrites the connector data at the offset (with the offset being optional with a default of 0). That should cover your needs.

Did it with "framebuffer-conX-alldata" which specifies the data, X being starting connector index.
Already coded and tested.

Allows you to do this:

Will submit a PR when I have it ready (probably tomorrow).

As you can see, injections cut from 27 to 5.

 

[headkaze]

Did it with "framebuffer-conX-alldata" which specifies the data, X being starting connector index.

Sounds fine to me. I've never encountered a patch like that but it makes sense to support it for this case. The only thing I don't like about it (along with the search/replace method) is people not understanding the data they're patching. Anyway once it gets merged with master I'll add support to Intel FB-Patcher and update the guide.

 

[snDr37]

Hi Guys,

Thanks for the nice work.

I pulled and compiled the last versions of lilu an whatevergreen from github and after some trail and error I got working.

I also seem to be a fringe patcher, because I have about the same framebuffer patch as RehabMan.
(thanks RehabMan for facilitating the fringe patchers among us.)

I had this working fine in Clover Kext to Patch:
find: <ff000000 01000000 20000000 01050900 00040000 87010000 02040a00 00040000 87010000 03060a00 00040000 87010000>
replace: <01050800 04000000 87010000 02040900 00080000 87010000 03060a00 00040000 87010000 ff000000 01000000 20000000>

The strange thing is that I only got the WhatereverGreen's patching to work when I used "Arbitrary" deviceProperties at device address 00:02:00

Neither the RehabMans AddProperties method or Headkaze's Device/Properties method gave any results.
The patches and the result of the patches didn't show up in the IGPU deviceProperties in ioregestry-explorer.


Any idea, what is going wrong, or what I could be doing wrong?
The used patches are the same, only the methods differ. (see below)

grtz,
Sander.

PS: @headkaze: I think the name of one or more patch instructions is not really covering their function.
fi: [framebuffer-con0-enable] is enabling the patch of con0, the name suggests it enables con0.

In my example I had to add:
framebuffer-patch-enable = 01000000
framebuffer-con0-enable = 01000000

just to enable 1 patch...

If I may suggest:
framebuffer-patch-disable
framebuffer-con0-patch-disable

both defaulting to false if not present.

 

[RehabMan]

I also seem to be a fringe patcher, because I have about the same framebuffer patch as RehabMan.
(thanks RehabMan for facilitating the fringe patchers among us.)

LOL.

The strange thing is that I only got the WhatereverGreen's patching to work when I used "Arbitrary" deviceProperties at device address 00:02:00

Neither the RehabMans AddProperties method or Headkaze's Device/Properties method gave any results.
The patches and the result of the patches didn't show up in the IGPU deviceProperties in ioregestry-explorer.

Keep in mind that Devices/AddProperties requires config.plist/Graphics/Inject/Intel=true.
And that the Device/Properties 'gfxutil style' shown in post #1 requires a version of Clover that supports it (previous versions, Device/Properties has to be a binary data representing that data, created by gfxutil).

Also, all of these methods are mutually exclusive... so don't try to mix them. Clover will only honor one of them if you try to use more than one method.

PS: @headkaze: I think the name of one or more patch instructions is not really covering their function.
fi: [framebuffer-con0-enable] is enabling the patch of con0, the name suggests it enables con0.

In my example I had to add:
framebuffer-patch-enable = 01000000
framebuffer-con0-enable = 01000000

just to enable 1 patch...

If I may suggest:
framebuffer-patch-disable
framebuffer-con0-patch-disable

both defaulting to false if not present.

I second that notion (eg. default is enabled, with optional disabler properties instead of required enabler properties).

 

[headkaze]

Did it with "framebuffer-conX-alldata" which specifies the data, X being starting connector index.

The way I'm thinking of implementing this in Intel FB-Patcher is if you have modified 3 or more connector fields then it will switch to this method of patching.

 

[Sebinouse]

Framebuffer patching in Mojave
Binary patching framebuffers in Clover is no longer a viable method in Mojave.

@headkaze
Can you tell me more about this KextToPatch is broken in Mojave ? (only for FB ?)

 

[snDr37]

The way I'm thinking of implementing this in Intel FB-Patcher is if you have modified 3 or more connector fields then it will switch to this method of patching.

Maybe you could just add an option to "Patch Options" to select this method manually, that would be just as easy. (IMHO)


An advantage of the alldata-patch is that one can use the data from the clover kext-to-patch they probably already have.