Contribute
Register

[GUIDE] General Framebuffer Patching Guide (HDMI Black Screen Problem)

ok at least:
Lilu
VirtualSMC
are also of
different md5

RealtekRTL8111 seems to be not from releases but built from master

As if they were built around 2-3 weeks ago
 
EDIT: After first applying the 10.15.5.02 supplemental update, Catalina booted to a single display (additional displays did not work). After a few reboots, displays are back to normal.

--------------------------------------------

I just installed the Catalina 10.15.5.02 supplemental update on my HP EliteDesk 800 G4 Mini and am now limited to a single display. I did not have this problem with 10.15.5.01.
 

Attachments

  • Screen Shot 2020-06-02 at 11.00.36 AM.png
    Screen Shot 2020-06-02 at 11.00.36 AM.png
    56.1 KB · Views: 74
Last edited:
I've found the "solution", it's a hotfix actually, you have to rollback CFL kext from Apple.

I tried to post it here but the message is bein deleted. So AFAIK there is only one way now - to rollback old famebuffer file, we are waiting for new patch from WEG come

@deeveedee I've tried everything you've proposed (pipes, different FBs)bbut it didn't help (it couldn't actually), thanks for your help, it's really very cool that the community won't leave you alone when you are stuck and ask for help!
 
Hi there, I am having some trouble figuring this out alone.
Usually, I'd avoid asking for help but I really don't know what to do anymore :)

Hardware: i5 9600k (Coffe Lake Refresh) on an ASUS ROG STRIX H370-I.

plaftorm-id: 0x3E9B0007 (But I've tried them all!)
Not spoofing device-id as suggested on WEG's README (But I tried anyway!)
If I set an invalid platform-id then I get HDMI output, but no HW acceleration.

I have tried patching manually by changing the properties in alldata form. I tried every BusID (00 to 06) on every Index (conn0 to conn2). Setting to HDMI (00080000) the one I was testing and DP (00040000) on the other two and rebooting. That's 18 reboots for this test alone, but I think now I'm over 200 reboots just to get this working :D

Then I tried to copy somebody's else configuration (from users with my same mobo), and they all seemed to disable conn1/2 and setting BusID 4 on conn0. First of all, I don't understand how is it possible that copying the framebuffer patches from another user with the same mobo and with same platform-id does not work (Please if somebody can help me to understand this I'd appreciate it!)

The only thing I haven't tried to manually change is pipe values.
I manage to run Hackintool by using TeamViewer and I can see the iGPU is correctly recognized.

At, first I had this configuration:
Index: 1 - BusID: 0x05 - Pipe: 9 - Type 00040000
Index: 2 - BusID: 0x04 - Pipe: 10 - Type 00040000
Index: 3 - BusID: 0x06 - Pipe: 8 - Type 00040000


Then after switching SMBIOS (from iMac19,1 to Macmini8,1) I now get all the Pipe values set on 18 (weird).

How can I proceed? I'm willing to invest more time into this, I just don't know what to do next.
Should I try all possible pipe values? Go through all the BusIDs from 0 to 6 again?

I'll attach my EFI for reference. Thanks in advance people! :)
 

Attachments

  • EFI.zip
    5.2 MB · Views: 88
Hi there, I am having some trouble figuring this out alone.
Usually, I'd avoid asking for help but I really don't know what to do anymore :)

Hardware: i5 9600k (Coffe Lake Refresh) on an ASUS ROG STRIX H370-I.

plaftorm-id: 0x3E9B0007 (But I've tried them all!)
Not spoofing device-id as suggested on WEG's README (But I tried anyway!)
If I set an invalid platform-id then I get HDMI output, but no HW acceleration.

I have tried patching manually by changing the properties in alldata form. I tried every BusID (00 to 06) on every Index (conn0 to conn2). Setting to HDMI (00080000) the one I was testing and DP (00040000) on the other two and rebooting. That's 18 reboots for this test alone, but I think now I'm over 200 reboots just to get this working :D

Then I tried to copy somebody's else configuration (from users with my same mobo), and they all seemed to disable conn1/2 and setting BusID 4 on conn0. First of all, I don't understand how is it possible that copying the framebuffer patches from another user with the same mobo and with same platform-id does not work (Please if somebody can help me to understand this I'd appreciate it!)

The only thing I haven't tried to manually change is pipe values.
I manage to run Hackintool by using TeamViewer and I can see the iGPU is correctly recognized.

At, first I had this configuration:
Index: 1 - BusID: 0x05 - Pipe: 9 - Type 00040000
Index: 2 - BusID: 0x04 - Pipe: 10 - Type 00040000
Index: 3 - BusID: 0x06 - Pipe: 8 - Type 00040000


Then after switching SMBIOS (from iMac19,1 to Macmini8,1) I now get all the Pipe values set on 18 (weird).

How can I proceed? I'm willing to invest more time into this, I just don't know what to do next.
Should I try all possible pipe values? Go through all the BusIDs from 0 to 6 again?

I'll attach my EFI for reference. Thanks in advance people! :)
I have the same issue, I have seen its an issue with a combo of WEG and Catalina 15.5.5, I have supplemented update also, VNC works, the updates were done via vnc
 
EDIT: After first applying the 10.15.5.02 supplemental update, Catalina booted to a single display (additional displays did not work). After a few reboots, displays are back to normal.

--------------------------------------------

I just installed the Catalina 10.15.5.02 supplemental update on my HP EliteDesk 800 G4 Mini and am now limited to a single display. I did not have this problem with 10.15.5.01.
How did you rollback? thanks
 
So today I've done the whole pathing from scratch again.

I went from:
01010900 00080000 C7030000 to 01060900 00080000 C7030000 (Pipe: 9)
01011200 00080000 C7030000 to 01061200 00080000 C7030000 (Pipe: 18)
On every conn.
Setting
00080000 (HDMI) on the one I was testing, and 00040000 (Type) and 00 (BusID) on the other two.

I've done this for every conn, trying both 18 (0x12) and the "original" Pipe values, which are:
90x09 for conn0
10
0x0A for conn1
8
0x08 for conn2

That's 6 (BusID) * 2 (Pipe) * 3 (Index) = 36 possible combinations, rebooting after changes.

And NO LUCK!

These are the starting values:
Schermata 2020-06-03 alle 14.29.11.png

And this is at the end:
Schermata 2020-06-03 alle 14.26.21.png


Latest WEG and Lilu (built from sources yesterday, but tried also with Release ZIPs).

I am also on 10.15.5.
Shall we downgrade? I think this is a no-go.
 
How did you rollback? thanks
I didn't roll anything back. My displays started working properly after a few reboots. My HP EliteDesk 800 G4 Mini is now running fine with 10.15.5.02. I don't understand why the problem happened or why it resolved itself.
 
So today I've done the whole pathing from scratch again.

I went from:
01010900 00080000 C7030000 to 01060900 00080000 C7030000 (Pipe: 9)
01011200 00080000 C7030000 to 01061200 00080000 C7030000 (Pipe: 18)
On every conn.
Setting
00080000 (HDMI) on the one I was testing, and 00040000 (Type) and 00 (BusID) on the other two.

I've done this for every conn, trying both 18 (0x12) and the "original" Pipe values, which are:
90x09 for conn0
10
0x0A for conn1
8
0x08 for conn2

That's 6 (BusID) * 2 (Pipe) * 3 (Index) = 36 possible combinations, rebooting after changes.

And NO LUCK!

These are the starting values:
View attachment 473463
And this is at the end:
View attachment 473464

Latest WEG and Lilu (built from sources yesterday, but tried also with Release ZIPs).

I am also on 10.15.5.
Shall we downgrade? I think this is a no-go.
try updating whatevergreen kext and all the others kexts to the latest releases
they state that
Code:
Fixed framebuffer-conX-alldata patching regression
Maybe it'll help
I'm a newbie so please be cautious following my advises )
 
Back
Top