Fix HDMI connector and investigate hot-plug issue

[Qonfused]

Investigate potential hot-plug issue affecting HDMI and internal DP (screenpad plus). Potentially combines with:

• [x] LSPCON requires ACPI patch
• [x] con3 mapped to HDMI (e.g. usb-c port is thunderbolt capable)
• [x] enable-dbuf-early-optimizer WEG fix

[Qonfused]

Some tests for potential hot-plug issue w/ DP:

• [x] Boot with internal display disconnected, then re-connect
• [x] Boot with external display (DP) disconnected, then re-connect
• [x] Boot with external display (DP disconnected, then connect HDMI

[Qonfused]

^ Relevant LSPCON section for https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/pull/3#issue-1336783766.

[Qonfused]

I notice that the the first and second framebuffer are indexed 00 00 00 00 and 01 00 00 00 for their AAPL,DisplayPipe property, but the 3rd framebuffer is instead ff ff 00 00. This is also with an AGDP override already being present in boot args (agpdmod=vit9696).

I was thinking of another post here (the context is entirely different though) that brought my attention on a certain point:

Override AGDP is the basic step for multi monitors setup, still need select correct ig-platform-id for framebuffer patching.

For example, your current ig-platform-id is 0x3E9B0007 (CFL framebuffer mis-match with your IGPU but it work), it use bus-id 0x05 (port 5), 0x04 (port 6), 0x06 (port7), 0x00 (port 0 not activated), all connector type are DP and usually WEG will auto apply DP to HDMI patches, means that your HDMI probably linked to 0x00 (port 0).

Try other ig-platform-id with 0x00 (port 0 for LVDS) is activated, like 0x3E920000, and use hackintools change connector type from LVDS to HDMI, may work.

I wonder if the port isn't being properly activated or is somehow attached to con1 instead of con2 w/ similar behavior described there.

[Qonfused]

Displaypipe is still the same (still the same behavior of black internal screen for a couple of seconds before external monitor going into low power mode again).

I was thinking that maybe since the HDMI connector is a 1.4 HDMI connector, setting LSPCON preference to use HDMI 1.4 instead of 2.0 would be better. Regardless of whether there is native HDMI 2.0 iGPU support, I don't think it's necessary to enable it going forward without a HDMI 2.x connector present.

[Qonfused]

Tried applying the enable-cdclk-frequency-fix patch from the WEG guide. I didn't see anything in the display's EDID data to suggest it'd have the wrong clock frequency, but it didn't end up helping anyways.

Hot-plug still doesn't appear to work, also showing the following in console:

[Qonfused]

Need to test more HDMI fixes before testing https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/pull/3#issuecomment-1212881661.

[Qonfused]

May also try 0x3E9B0000 platform-id in case #1 needs to be revisited (suggested here as a possible fix for black-screen after 10.15.5).

[Qonfused]

For clarity, the HPD is low signal in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/pull/3#issuecomment-1213103167 suggests no connection was found. It's possible that the port isn't routed/activated correctly.

[Maleficent-Magik]

yes, but is he talking about the hdmi? or screenpad? logically the screenpad... remains to be seen if it is linked to FB or not...Also I have a question, I noticed in IO Registry that the main screen with the HDMI code as DisplayFlag (00 08 00 00 of memory) but concerning the screenpad, its DisplayFlag is for him coded in null, that is to say 00 00 00 00. Which represents no port I think...Do you think there is the same thing at home and that the fact that the DisplayFlag is at 00 00 00 00 is a problem?

Le 12 août 2022 15:56, Cory Bennett @.***> a écrit : For clarity, the HPD is low signal in #3 (comment) suggests no connection was found. It's possible that the port isn't routed/activated correctly.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Qonfused]

It’s a problem for the HDMI connector (ff ff 00 00 for me), but I think it was 10 00 00 00 for displayport for the screenpad which as far as I know is normal. I’ll have to double check that for the second display.

[Qonfused]

It’s all zeros for the primary display (should be normal for an internal display), so if it’s that for the second display then it must not have attached or has the same behavior described in that thread.

[Qonfused]

Just testing using Apple GuC firmware + RPS patch in this last commit; does work but as expected it didn't fix the HDMI or screenpad issue.

I updated the connector flags from 87010000 -> C7010000 and that didn't yield any new behavior either.

[Qonfused]

What's left to try is the enable-debug-early-optimizer WEG patch in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/pull/3#issue-1336783766 as far as potential fixes go, and then https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/pull/3#issuecomment-1212881661 as far as debugging hot-plug behavior goes.

[Qonfused]

Just posted on Reddit here for anyone following that.

[Qonfused]

Considering moving down to MacBookPro16,2 as potentially a better-fit SMBIOS, but I don't think that'll fix any behavior described here.

Edit: Revisited in #5 w/ a more adequate SMBIOS of MacBookPro16,3

[Qonfused]

A very obvious problem that I overlooked is if the HDMI port is routed to the (disabled) MX250 Nvidia GPU.

[Maleficent-Magik]

mmm...that would be possible. but on some versions (including mine) the HDMI port is on the iGPU. but it is possible that the HDMI port on external cards is connected to it yep

[Qonfused]

Well, there isn't a mux switch (it's software based here using Nvidia optimus). All hardware display outputs are routed to the iGPU on this sort of muxless system.

This is the software control for optimus; for reference, the second display is labeled as 'TV' while the 1080p external monitor is the 'E2360' display:

^ You can also use HDMI while the MX250 is blacklisted in Linux, and it also works on Windows without activating the dGPU at all.

[Qonfused]

mmm...that would be possible. but on some versions (including mine) the HDMI port is on the iGPU. but it is possible that the HDMI port on external cards is connected to it yep

I was worried that it may have just been reported as such from Nvidia Optimus. The thought is that having 2 displays connected is probably already very heavy on the iGPU, so maybe they went for connecting HDMI to the dGPU like they did on the higher-specced pro-duo, albeit this is usually only done w/ higher end dGPUs anyways.

It's shown to be connected to the iGPU on the schematic as well, but I thought I might have overlooked something if HDMI still wasn't being detected.

[Qonfused]

Additionally, there does not exist alt-mode for the usb-c port either, so there isn't an additional connector to be accounted for. If there was, then the following config would work:

It's not clear why HDMI isn't working then. Maybe I'm still using the wrong framebuffer?

[Qonfused]

~~If this is still related to CSM, then there is a potential fix from changing the horizontal sync width from 60 to 100: https://github.com/Sniki/Lenovo-Thinkpad-T440S#patching-display-edid-wip~~

Edit: I've been unable to find any mod to the screen's clock data that addressed this problem.

[Maleficent-Magik]

well, what do you mean by Apple GuC Firmware? what does it correspond to ^^' I've never heard of it? same as for the rps patch? Just testing using Apple GuC firmware + RPS patch in this last commit; does work but as expected it didn't fix the HDMI or screenpad issue. I updated the connector flags from 87010000 -> C7010000 and that didn't yield any new behavior either.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[Maleficent-Magik]

yeah, I looked at its specs, it has the Touchbar (i.e. the integrated screen...) the same family of processors, i5 and i7 Le 15 août 2022 02:55, Cory Bennett @.***> a écrit : Considering moving down to MacBookPro16,2 as potentially a better-fit SMBIOS, but I don't think that'll fix any behavior described here.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[Qonfused]

The GuC firmware is intel firmware for handling power management/performance tweaks for the iGPU; it’s meant for better supporting intel macs’ iGPUs. The RPS patch is for enabling some kind of ‘RPS control patch’?; supposedly it also helps iGPU performance but I honestly can’t recall what it actually does from reading this: https://github.com/acidanthera/WhateverGreen/blob/master/WhateverGreen/kern_igfx_pm.cpp#L128-L239.

The thought was that if the issue was related to bad firmware matching/something performance related (it wasn’t, which to be fair was expected), these were the only patches that would address it.

[Qonfused]

Going to have to better organize this information going forward, but the GuC patch has been removed w/ some dummy stubs.

[Qonfused]

HDMI also works (with hotplug) after updating opencore + kexts in #10 and using an updated framebuffer patch.