search

Qonfused / ASUS-ZenBook-Duo-14-UX481-Hackintosh

OpenCore configuration for the ASUS ZenBook Duo 14" (UX481FA/FL)
https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh
BSD 3-Clause "New" or "Revised" License
31 stars 1 forks source link

Fix UHD 620 Framebuffer #1

Closed Qonfused closed 2 years ago

Qonfused commented 2 years ago

This pull request builds upon https://github.com/shiecldk/ASUS-ZenBook-Pro-Duo-15-OLED-UX582-Hackintosh/issues/2#issuecomment-1207144919.

Testing connector patches with platform-id 00009B3E using the following framebuffer profile and base configuration for the framebuffer patch:

Index Connector Type Port Number Pipe Flags
0 LVDS/eDP 0x0 8 98000000
1 Displayport 0x5 9 87010000
2 Displayport 0x4 A 87010000
Add under DeviceProperties > Add > PciRoot(0x0)/Pci(0x2,0x0): Key Type Value
AAPL,ig-platform-id Data 00009B3E
device-id Data 9B3E0000
Qonfused commented 2 years ago

https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/pull/1/commits/cc3eec49a9b9e41d38d67ee11b0e1e17ec552998 produces a black screen (still backlit because of forced 'ready' status from boot arg igfxonln=1).

It seems mapping connector 1 to any port beyond 01 (e.g. 02, 03, 4) will cause a black screen for the screenpad-plus instead of the default static behavior:

image

This seems to confirm the screenpad plus's location at connector 1 port 01, which is verified by the screenpad-plus's location at PCI0@0/AppleACPIPCI/IGPU@2/AppleIntelFramebuffer@1 in IORegistryExplorer: Screen Shot 2022-08-06 at 4 56 59 PM It also shows up as an external display in macOS: Screen Shot 2022-08-06 at 5 04 53 PM

Qonfused commented 2 years ago

Adding to my previous note https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/pull/1#issuecomment-1207287705, I noticed similar behavior for the primary display when using busID 04 for connector 1, but only when disabling connector2 and using the displayport type:

Connector Port BusID Type
con1 01 04 00040000

Going through the remaining busIDs and types (following this guide for busID patching), no behavior appeared to have changed:

Connector Port BusID Type
con1 01 01 00040000
con1 01 02 00040000
con1 01 03 00040000
con1 01 05 00040000
con1 01 06 00040000
con1 01 01 02000000
con1 01 02 02000000
con1 01 03 02000000
con1 01 04 02000000
con1 01 05 02000000
con1 01 06 02000000

I added the above patches w/ con0 and con2 disabled:

image

Maleficent-Magik commented 2 years ago

Adding to my previous note #1 (comment), I noticed similar behavior for the primary display when using busID 04 for connector 1, but only when disabling connector2 and using the displayport type:

Connector Port BusID Type con1 01 04 00040000 Going through the remaining busIDs and types (following this guide for busID patching), no behavior appeared to have changed:

Connector Port BusID Type con1 01 01 00040000 con1 01 02 00040000 con1 01 03 00040000 con1 01 05 00040000 con1 01 06 00040000 con1 01 01 02000000 con1 01 02 02000000 con1 01 03 02000000 con1 01 04 02000000 con1 01 05 02000000 con1 01 06 02000000

What really intrigues me the most is that according to the data sheet of the screenpad (which would be apriori: BOE NV126B5M-N41) the screen would be connected by eDP (2 Lanes) , eDP1.2 , HBR1 (2.7G/lane) , 40 pins Connector

Screenshot : https://prnt.sc/bJnMFlz3F4xW (from datasheet)

so in logic, it would be the connector type : 02000000 (B64 : AgAAAA==)

But, on Windows and MacOS, it is detected as DisplayPort... so quick question, do Windows and MacOS consider eDP and DP = DP?

Then, I was able to open IORegistry, and I could observe that by clicking on AppleDisplay (i.e. the ScreenPad) (Path: IGPU@2/AppleIntelFrambuffer@1/display0/AppleDisplay) I observe that IODisplayConnectFlags has a data of <00 00 00 00> But if we look at the main screen of Asus (Path: IGPU@2/AppleIntelFramebuffer@0/display0/AppleBacklightDisplay) I observe here that IODisplyConnectFlags has a data of <00 08 00 00> (If we look at the datasheet of Dortania, it says that the Connector Type = <00 08 00 00> HDMI...) So, do the connector Type and the flags have something in common?

Photo :

IORegistry main screen: AppleBacklightDisplay: https://drive.google.com/file/d/1P6X__1fuyXqPDdo1f8srZRbDtbuF-5rp/view?usp=sharing

Screenpad IORegistry AppleDisplay : https://drive.google.com/file/d/1aHdPLobJfJBRtOXq9KoQp4uTzshPA36G/view?usp=sharing

Datasheet : https://www.panelook.com/NV126B5M-N41_BOE_12.6_LCM_overview_44187.html

Qonfused commented 2 years ago

I noticed that the screenpad plus is designated as DP (also listed as DDI1) in the device's schematic w/ a different layout than eDP, though it matches what was shown in the datasheet you linked as the physical connector:

image image

On the left is the LCD connector and on the right looks to be for the touchscreen digitizer: image

Qonfused commented 2 years ago

The second display for the UX482 model of this laptop though has a very similar part no. BOE NV126B5M-N42 (BOE0921).

Maleficent-Magik commented 2 years ago

yes true, So that means that from the beginning, not only am I wrong to try to put the EDP patch x) but I'm also talking nonsense... what an idiot... xD 😅

So we have to rely on DP instead? so the type connector would be just to put as a DP but we just have to find the right framebuffer-id so...? 🤔

Qonfused commented 2 years ago
Yep it seems this is the right datasheet: Display Specs w/ pt number
Primary 14.0 inch, 1920 x 1080 px, IPS, matte, non-touch, Chi Mei N140HCE-EN2 panel
Secondary 12.6 inch, 1920 x 515 px, IPS, matte, touch, BOE NV126B5M-N41 panel
Maleficent-Magik commented 2 years ago

Exact, the resolutions is good and the Serials number too

Qonfused commented 2 years ago

yes true, So that means that from the beginning, not only am I wrong to try to put the EDP patch x) but I'm also talking nonsense... what an idiot... xD 😅

So we have to rely on DP instead? so the type connector would be just to put as a DP but we just have to find the right framebuffer-id so...? 🤔

I'm assuming so; it's the same case for the Pro Duo UX582 as well. The display type would be 00040000 for displayport instead of 02000000 for embedded displayport.

Maleficent-Magik commented 2 years ago

That's right according to the dortania guide. So we just have to find the right framebuffer-id...

<02 00 00 00> LVDS and eDP - Laptop displays <00 04 00 00> DisplayPort - USB-C display-out are DP internally

Maleficent-Magik commented 2 years ago

because if we look at your picture :

https://user-images.githubusercontent.com/32466081/183267508-7a728da2-0164-47de-b7b9-220951b594ce.png

We see that the port is already in DisplayPort... So it's not a connector type problem anymore, but the busID I think ? and so potentially also the framebuffer

Qonfused commented 2 years ago

It also seems that in IORegistryExplorer, the AppleBacklightDisplay device name maps to eDP, and just AppleDisplay maps to DP/HDMI. Screen Shot 2022-08-07 at 6 18 31 PM Screen Shot 2022-08-07 at 6 18 37 PM

Maleficent-Magik commented 2 years ago

I see it. So it would just be a Framebuffer-id error? With a possible busID error? This whole Framebuffer-id thing is not very clear to me heh... But personally I have the same thing as you in terms of port.For the moment the screen is still blurred visually so I hope to see if the busId and framebuffer changes something...

Qonfused commented 2 years ago

Yeah pretty much. I'm not sure on what the cause of the static is though, so that might need more research since the device is detected correctly sans the busID patch, etc.

I just pushed a fix to disable the screenpad plus static by just routing it to a different port (so it's instead a black screen to save power), though there isn't a clean way of disabling the backlight even after removing the igfxonln=1 boot arg.

I'll try the same busID search I did with the previous 00009B3E framebuffer id with 0900A53E (keeping the same device id) and then test with other device ids like C89B0000.

Qonfused commented 2 years ago

~Will need to investigate possible EDID patch as suggested here and explained further here and in tylernguyen/x1c6-hackintosh#60.~

Both displays appear to have the proper EDID properties after testing; doesn't affect this issue.

Just dumped the EDID data for the second display to once again confirm this; it also confirms the NV126B5M part no. from the datasheet linked before:

EDID2.txt

...
Manufacturer: BOE Model 87f Serial Number 0
Made week 1 of 2019
EDID version: 1.4
Digital display
8 bits per primary color channel
DisplayPort interface
...
Detailed mode: Clock 70.600 MHz, 309 mm x 83 mm
               1920 1968 2000 2080 hborder 0
                515  520  525  565 vborder 0
               +hsync -vsync 
Detailed mode: Clock 56.500 MHz, 309 mm x 83 mm
               1920 1968 2000 2080 hborder 0
                515  520  525  565 vborder 0
               +hsync -vsync 
ASCII string: BOE
ASCII string: NV126B5M
...

^ This was dumped using edid-decode.

Additionally, the av-signal-type property in IORegistryExplorer shows a value of 10 00 00 00 for the screenpad-plus, which matches the displayport type for the display.

Maleficent-Magik commented 2 years ago

~Will need to investigate possible EDID patch as suggested here and explained further here and in tylernguyen/x1c6-hackintosh#60.~ Both displays appear to have the proper EDID properties after testing; doesn't affect this issue.

Just dumped the EDID data for the second display to once again confirm this; it also confirms the NV126B5M part no. from the datasheet linked before:

EDID2.txt

^ This was dumped using edid-decode.

Additionally, the av-signal-type property in IORegistryExplorer shows a value of 10 00 00 00 for the screenpad-plus, which matches the displayport type for the display.

I see, I was just going to take care of it yesterday to see a bit of the EDID except I didn't have the faith haha x)

Maleficent-Magik commented 2 years ago

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

FramebufferID | AAPL, ig-platform-id | Type | Connector | Stolen Memory | Port Number | NoPatch | Patched -- | -- | -- | -- | -- | -- | -- | -- 0x3EA50009 | 0900A53E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98000000 | No need 0x3EA50009 | 0900A53E | Mobile | 3 | 58MB | 1 | 01050900 00040000 C7010000 | No need ? 0x3EA50009 | 0900A53E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 C7010000 | 02040A00 00080000 C7010000   |   |   |   |   |   |   |   0x3E920009 | 0900923E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98000000 | No need 0x3E920009 | 0900923E | Mobile | 3 | 58MB | -1 (NP[1]) | FF000000 01000000 20000000 | Need to fix busID ? and Port 0x3E920009 | 0900923E | Mobile | 3 | 58MB | -1 (NP[2]) | FF000000 01000000 20000000 | Need to fix busID ? and Port   |   |   |   |   |   |   |   0x3E9B0009 | 09009B3E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98000000 | No need 0x3E9B0009 | 09009B3E | Mobile | 3 | 58MB | 1 | 01050900 00040000 87010000 | No need ? 0x3E9B0009 | 09009B3E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 87010000 | 02040A00 00080000 87010000   |   |   |   |   |   |   |   0x3EA50000 | 0000A53E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98000000 | No need 0x3EA50000 | 0000A53E | Mobile | 3 | 58MB | 1 | 01050900 00040000 87010000 | No need? 0x3EA50000 | 0000A53E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 87010000 | 02040A00 00080000 87010000   |   |   |   |   |   |   |   0x3E920000 | 0000923E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98000000 | No need 0x3E920000 | 0000923E | Mobile | 3 | 58MB | 1 | 01050900 00040000 87010000 | No need? 0x3E920000 | 0000923E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 87010000 | 02040A00 00080000 87010000   |   |   |   |   |   |   |   0x3E000000 | 0000003E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98000000 | No need 0x3E000000 | 0000003E | Mobile | 3 | 58MB | 1 | 01050900 00040000 87010000 | No need? 0x3E000000 | 0000003E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 87010000 | 02040A00 00080000 87010000   |   |   |   |   |   |   |   0x3E9B0000 | 00009B3E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98000000 | No need 0x3E9B0000 | 00009B3E | Mobile | 3 | 58MB | 1 | 01050900 00040000 87010000 | No need 0x3E9B0000 | 00009B3E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 87010000 | 02040A00 00080000 87010000   |   |   |   |   |   |   |   0x3EA50004 | 0400A53E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98040000 | No need 0x3EA50004 | 0400A53E | Mobile | 3 | 58MB | 1 | 01050900 00040000 C7030000 | No need? 0x3EA50004 | 0400A53E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 C7030000 | 02040A00 00080000 C7030000   |   |   |   |   |   |   |   0x3EA50004 | 0400A53E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98040000 | No need 0x3EA50004 | 0400A53E | Mobile | 3 | 58MB | 1 | 01050900 00040000 C7030000 | No need ? 0x3EA50004 | 0400A53E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 C7030000 | 02040A00 00080000 C7030000   |   |   |   |   |   |   |   0x3EA50005 | 0500A53E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98040000 | No need 0x3EA50005 | 0500A53E | Mobile | 3 | 58MB | 1 | 01050900 00040000 C7030000 | No need? 0x3EA50005 | 0500A53E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 C7030000 | 02040A00 00080000 C7030000   |   |   |   |   |   |   |   0x3EA60005 | 0500A63E | Mobile | 3 | 58MB | 0 | 00000800 02000000 98040000 | No need 0x3EA60005 | 0500A63E | Mobile | 3 | 58MB | 1 | 01050900 00040000 C7030000 | No need? 0x3EA60005 | 0500A63E | Mobile | 3 | 58MB | 2 | 02040A00 00040000 C7030000 | 02040A00 00080000 C7030000

[1] No patched

[2] No patched

Maleficent-Magik commented 2 years ago

So, here I made a table with your values considering that the main screen was in LVDS, the ScreenPad in DP, and finally, let's not forget the HDMI port which must be converted... (i'have only convert the connector type, no busid convert here) (Actually I asked a question on the /r/hackintosh discord about the 3rd port)

We could potentially assume that without the 3rd port, the 2nd one is scrambled? but that wouldn't make sense?

Qonfused commented 2 years ago

I'm still not sure on what the cause of the static/garbled second display is though; I'd just expect a black screen if there was some kind of port/busID/etc mismatch. The only similar behavior I've seen is from stuff like this, though there is a suggested solution from the WhateverGreen manual that seems like a reasonable solution:

Fix the issue that the builtin display remains garbled after the system boots on ICL platforms:
Add the `enable-dbuf-early-optimizer` property to `IGPU` or use the `-igfxdbeo` boot argument instead to fix the Display Data Buffer (DBUF) allocation issue on ICL platforms, otherwise your builtin display remains garbled for 7 to 15 seconds after the system boots. You need this fix if you observe a bunch of errors mentioning "DBUF" and "pipe underrun" in the kernel log. This fix works by calling the function that optimizes the display data buffer allocations early. You may specify the delay in seconds (value of type `Data`) via the `dbuf-optimizer-delay` property. If the property is not specified, the default value will be used (see below). The community reports that a delay of 1 to 3 seconds is adequate for avoiding the underrun issue on the builtin display without having negative impacts on external displays, and that the default delay of 0 second used in *WEG* v1.5.4 may lead to both internal and external displays flickering on some laptops. Starting from v1.5.5, the default delay is changed to 1 second, so in most cases users do not have to specify the delay manually.
Sample kernel log that contains DBUF-related errors ``` [IGFB][ERROR][DISPLAY ] Display Pipe Underrun occurred on pipe(s) A [IGFB][ERROR][DISPLAY ] Internal cached DBuf values are not set. Failed to distribute DBufs ```

If this the cause of that behavior for the screenpad then this seems like a fairly likely fix to try as well.

Maleficent-Magik commented 2 years ago

`magik@MBP-de-Magik ~ % /System/Library/Extensions/AppleGraphicsControl.kext/Contents/MacOS/AGDCDiagnose -a AGDCDiagnose Version: 6.5.7 (AGDC node count: 2)

Start: GPUWrangler

Stats: GPUCAdded:0 GpuAdded:1 Eject:0/f0/fd0/c0 Remove:0/t0 Un:0

gpu 0x4873 flags 0xb2000010 (IG,published,quiet,pubSched,pubArmed) vid.did=8086.3e9b b:d:f=0:2:0 gpu 0x4873 pci 0x100000227 IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IGPU@2 gpu 0x4873 agdc 0x10000050b /AppleIntelFramebufferController/IntelFBClientControl gpu 0x4873 gpuc 0x000000000 gpu 0x4873 agdpclient 0x000000000 gpu 0x4873 accel 0x1000004f9 /IntelAccelerator gpu 0x4873 fb0:0 0x1000004fc /AppleIntelFramebuffer@0 gpu 0x4873 fb1:1 0x1000004fd /AppleIntelFramebuffer@1 gpu 0x4873 fb2:2 0x1000004fe /AppleIntelFramebuffer@2

End: GPUWrangler (took 0.004 sec)

Start: EFIDisplayInfo

Not present Dumping EFI data for GPU Path IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IGPU@2

End: EFIDisplayInfo (took 0.003 sec)

Start: Mux

End: Mux (took 0.000 sec)

Start: Ports

Start: AGDC[1] 0x10000051c

IOService:/IOResources/AppleGPUWrangler Vendor: Apple [0000106b]: AppleGPUWrangler [8 10000] (0)

End: AGDC[1] 0x10000051c (took 0.000 sec)

Start: AGDC[2] 0x10000050b

IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IGPU@2/AppleIntelFramebufferController/IntelFBClientControl Vendor: AppleIntelFramebufferController [0000106b]: IntegratedGPU [1 10000] (0) FBs: 3, Ports: 0xe mst:0xc ddc:0xc aux:0xe, Streams: dp:0 dvi:0 mst:2 max:3 Framebuffers:

End: Ports (took 0.137 sec)

Start: Metrics

Display Metric Tool Version: 1.2 Display Metric Plugin Version: 1.2 AGDC Version: 6.5.7 Dumping Metric Logs: currentlog(10) logsize(32768) numberlogs(819) Total lines: 11 2022-08-09 17:02:26.112176+0200: kAGDCPluginMetricsPowerOff(411e) GPU:0x4873 Port: 0 Will 2022-08-09 17:02:32.802870+0200: kAGDCPluginMetricsLTBegin(4106) GPU:0x4873 Port: 2 2022-08-09 17:02:32.828557+0200: kAGDCPluginMetricsLTEnd(4107) GPU:0x4873 Port: 2 link_rate:0xa lane_count:0x82 LT Status:0x1 (OK) 2022-08-09 17:02:32.913166+0200: kAGDCPluginMetricsLTBegin(4106) GPU:0x4873 Port: 2 2022-08-09 17:02:32.939891+0200: kAGDCPluginMetricsLTEnd(4107) GPU:0x4873 Port: 2 link_rate:0xa lane_count:0x82 LT Status:0x1 (OK) 2022-08-09 17:02:33.156898+0200: kAGDCPluginMetricsLTBegin(4106) GPU:0x4873 Port: 2 2022-08-09 17:02:33.182802+0200: kAGDCPluginMetricsLTEnd(4107) GPU:0x4873 Port: 2 link_rate:0xa lane_count:0x82 LT Status:0x1 (OK) 2022-08-09 17:02:36.745700+0200: kAGDCPluginMetricsLTBegin(4106) GPU:0x4873 Port: 2 2022-08-09 17:02:36.772267+0200: kAGDCPluginMetricsLTEnd(4107) GPU:0x4873 Port: 2 link_rate:0xa lane_count:0x82 LT Status:0x1 (OK) 2022-08-09 17:02:46.806150+0200: kAGDCPluginMetricsHDCPStart(410b) GPU:0x4873 Port: 2 HDCP version:0x1.0 Authenticated Version:0x1 Bcaps:0

End: Metrics (took 0.001 sec)

Start: displaypolicyd

running 2603 sec (started Tue Aug 9 17:02:20 2022, now Tue Aug 9 17:45:43 2022) boardID: Mac-E1008331FDC96864 featureMask: 0x20002000 platformFlags: 0 extraSupportFlags: 0 wranglerFlags: 0 Version: 6.5.7, Max: 512, counter: 2, calendar sync: 0x5e5d0d229c82b/0x9b21cff9 GTRACEDATASTREAM traceData = { { 0x67547261, 0x63654461, 0x74614475, 0x6d700000, 0x102, 512, 2, 6, 5, 7, 0, 56, 1660059925465131, 2602684409 }, { { 18737538604, 0x0, 392, 38, 0, 0, 0x0, 0x0, 0x0 }, { 19119633992, 0x0, 143, 22, 0, 0, 0x100, 0x0, 0x0 }, } };

End: displaypolicyd (took 0.001 sec)

Start: Devices

Start: AGDC[1] 0x10000051c

IOService:/IOResources/AppleGPUWrangler Vendor: Apple [0000106b]: AppleGPUWrangler [8 10000] (0)

End: AGDC[1] 0x10000051c (took 0.000 sec)

Start: AGDC[2] 0x10000050b

IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IGPU@2/AppleIntelFramebufferController/IntelFBClientControl Vendor: AppleIntelFramebufferController [0000106b]: IntegratedGPU [1 10000] (0)

End: AGDC[2] 0x10000050b (took 0.004 sec)

End: Devices (took 0.004 sec)

Start: mpxdiagnose

End: mpxdiagnose (took 0.007 sec)

AGDCDiagnose completed in 0.138999 seconds

magik@MBP-de-Magik ~ % `

Maleficent-Magik commented 2 years ago

By searching a bit on the right and left, I could find a graphical diagnostic utility, but I didn't find anything interesting...at least, I don't think so

Maleficent-Magik commented 2 years ago

So, while wandering a bit from forum to forum, I found this:

"if your IGPU is driving dual 1080P displays". the interesting word is dual 1080P displays because both displays are 1080P if I'm not mistaken... and we own 2 displays... so if we keep reading :

if you already have the property framebuffer-patch-enable in the device properties section of your config.plist then you just need to add : framebuffer-unifiedmem AAAAgA== (in the GPU property of the config.plist ofc)

I can see that here -> : https://www.tonymacx86.com/threads/an-idiots-guide-to-lilu-and-its-plug-ins.260063/#4K What do you think? @Qonfused

The reading a little higher up that concerns us too! ⬇️ ⬇️ If you have a High DPI display (>1080P) or video panel connected to the IGPU like i do on my laptop then you will need to add -cdfon as a MacOS boot argument, this enables WhatEverGreen's pixel-clock patches (that used to be handled by the now depreciated CoreDisplayFixUp plug-in) and allows for higher display resolutions and refresh rates on High-DPI display panels such as 4K @ 60Hz.

Qonfused commented 2 years ago

So, while wandering a bit from forum to forum, I found this:

"if your IGPU is driving dual 1080P displays". the interesting word is dual 1080P displays because both displays are 1080P if I'm not mistaken... and we own 2 displays... so if we keep reading :

if you already have the property framebuffer-patch-enable in the device properties section of your config.plist then you just need to add : framebuffer-unifiedmem AAAAgA== (in the GPU property of the config.plist ofc)

I can see that here -> : https://www.tonymacx86.com/threads/an-idiots-guide-to-lilu-and-its-plug-ins.260063/#4K What do you think? @Qonfused

That adds an additional 512 MB of iGPU memory from the existing 1536 MB (AAAAgA== -> 00000080 = 2048MB). It doesn't appear to help our case much but I've added a unified-mem value of 3072 MB (000000C0) in case it helps to minimize the issue at all (probably not).

The reading a little higher up that concerns us too! ⬇️ ⬇️ If you have a High DPI display (>1080P) or video panel connected to the IGPU like i do on my laptop then you will need to add -cdfon as a MacOS boot argument, this enables WhatEverGreen's pixel-clock patches (that used to be handled by the now depreciated CoreDisplayFixUp plug-in) and allows for higher display resolutions and refresh rates on High-DPI display panels such as 4K @ 60Hz.

I believe this would only benefit individual panels' clock rates (neither panel is above 1080p and would need that patch), but this would probably be applicable for patching the HDMI connector for 4k@30. It seems unnecessary to apply atm.

Qonfused commented 2 years ago

The unified-mem patch reserving more VRAM doesn't seem to help after re-testing the busID patches, but I hope that is looking in the right direction.

I'd double check that you've set at least 64 MB for pre-alloc DVMT (under graphics settings in BIOS) since 58 MB is required for the 0x3E9B0000 or 0x3EA50009 framebuffer profile.

Also no one seems to be responding to my post in the Hackintosh Paradise Discord as of a couple hours later. I'm pretty sure 0x3E9B0000 is the correct framebuffer profile for this iGPU, and after testing busID patching again there must be something else interfering since it isn't just a black screen issue.

Qonfused commented 2 years ago

That last commit reverted the unifiedmem patch. Edit: Accidentally removed the framebuffer-patch-enable key when committing past some point.

Qonfused commented 2 years ago

Some suggested changes/things to test:

Qonfused commented 2 years ago

After verifying again, it appears a setting for enabling/disabling CSM is either read-only or missing. It's possible it may have been available in an older BIOS (see the kernel-issues section for possible setting names).

The current situation is that the framebuffer patches and/or EDID patch should work but unfortunately do not (at least they do not fix this issue). I'm thinking of investigating other missing devices/behavior (e.g. trackpad, touchscreen, etc) to figure out the functionality of some of the disabled ACPI patches from upstream.

I may also either continue investigating HDMI here or in a separate pull request, though current patches should work but don't detect a display.

I do fully intend to continue investigating this issue, though it appears to likely be outside the scope of a simple framebuffer patch fix.

Qonfused commented 1 year ago

Pruned for clarity; there were a number of messages that appear to had been resolved and made it confusing to navigate through.