Display static on FB initialization w/ DisplayPort ASUS ScreenPad devices #2243
Comments
|
As I investigate this I'd appreciate some feedback here as I don't have enough familiarity with what devices/behavior are affected by existing WhateverGreen patches. I'm not averse to fixing/re-implementing any existing WEG fixes, though I'd appreciate any help that can shrink the search space in the CFL framebuffer/controller kexts as my time is quite limited. For reference, this is the run-down on what methods/symbols are already hooked/used by WhateverGreen, applicable to CFL->CML iGPUs, etc: WEG symbolskern_igfx_clock.cpp
// IGFX::DPCDMaxLinkRateFix::processFramebufferKextForCFL
150,4: __ZN31AppleIntelFramebufferController7ReadAUXEP21AppleIntelFramebufferjtPvP21AppleIntelDisplayPath
// IGFX::CoreDisplayClockFix::processFramebufferKext
494,4: __ZN31AppleIntelFramebufferController21probeCDClockFrequencyEv
500,5: __ZN31AppleIntelFramebufferController14disableCDClockEv
501,5: __ZN31AppleIntelFramebufferController19setCDClockFrequencyEy
// IGFX::HDMIDividersCalcFix::processFramebufferKext
689,39: __ZN31AppleIntelFramebufferController17ComputeHdmiP0P1P2EjP21AppleIntelDisplayPathPNS_10CRTCParamsE
// IGFX::MaxPixelClockOverride::processFramebufferKext
912,4: __ZN21AppleIntelFramebuffer15connectionProbeEjj
kern_igfx_debug.cpp
// IGFX::FramebufferDebugSupport::processFramebufferKext
337,5: __ZN21AppleIntelFramebuffer16enableControllerEv
338,5: __ZN21AppleIntelFramebuffer25setAttributeForConnectionEijm
339,5: __ZN21AppleIntelFramebuffer25getAttributeForConnectionEijPm
340,5: __ZN21AppleIntelFramebuffer14setDisplayModeEii
341,5: __ZN21AppleIntelFramebuffer15connectionProbeEjj
342,5: __ZN21AppleIntelFramebuffer16getDisplayStatusEP21AppleIntelDisplayPath
343,5: __ZN21AppleIntelFramebuffer13GetOnlineInfoEP21AppleIntelDisplayPathPhS2_PNS0_15DisplayPortTypeEPbb
344,5: __ZN21AppleIntelFramebuffer15doSetPowerStateEj
345,5: __ZN21AppleIntelFramebuffer18IsMultiLinkDisplayEv
346,5: __ZN21AppleIntelFramebuffer19validateDisplayModeEiPPKNS_15ModeDescriptionEPPK29IODetailedTimingInformationV2
347,5: __ZN31AppleIntelFramebufferController18hasExternalDisplayEv
348,5: __ZN31AppleIntelFramebufferController15SetDPPowerStateEP21AppleIntelFramebufferhP21AppleIntelDisplayPath
349,5: __ZN31AppleIntelFramebufferController14setDisplayPipeEP21AppleIntelDisplayPath
350,5: __ZN31AppleIntelFramebufferController11setFBMemoryEP21AppleIntelFramebuffer
351,5: __ZN20IntelFBClientControl11doAttributeEjPmmS0_S0_P25IOExternalMethodArguments
kern_igfx_i2c_aux.cpp
// IGFX::AdvancedI2COverAUXSupport::processFramebufferKext
32,5: __ZN31AppleIntelFramebufferController14ReadI2COverAUXEP21AppleIntelFramebufferP21AppleIntelDisplayPathjtPhbh
37,5: __ZN31AppleIntelFramebufferController15WriteI2COverAUXEP21AppleIntelFramebufferP21AppleIntelDisplayPathjtPhb
kern_igfx_lspcon.cpp
// IGFX::LSPCONDriverSupport::processFramebufferKext
190,4: __ZN31AppleIntelFramebufferController11GetDPCDInfoEP21AppleIntelFramebufferP21AppleIntelDisplayPath
196,4: __ZN31AppleIntelFramebufferController7ReadAUXEP21AppleIntelFramebufferjtPvP21AppleIntelDisplayPath
kern_igfx_memory.cpp
// IGFX::DVMTCalcFix::processFramebufferKext
78,50: __ZN31AppleIntelFramebufferController13FBMemMgr_InitEv
90,21: __ZN11IOPCIDevice20extendedConfigRead16Ey
// IGFX::DisplayDataBufferEarlyOptimizer::processFramebufferKext
310,39: __ZN31AppleIntelFramebufferController17getFeatureControlEv
kern_igfx_pm.cpp
// IGFX::RPSControlPatch::processFramebufferKext
151,4: __ZL15pmNotifyWrapperjjPyPj
// IGFX::RPSControlPatch::processGraphicsKext
165,52: __ZN26IGHardwareCommandStreamer514submitExecListEj
165,107: __ZN26IGHardwareCommandStreamer514submitExecListEj
// IGFX::ForceWakeWorkaround::processGraphicsKext
322,4: __ZN16IntelAccelerator26SafeForceWakeMultithreadedEbjj
kern_igfx.cpp
// IGFX::processKernel
277,40: __ZN9IOService20copyExistingServicesEP12OSDictionaryjj
// IGFX::processKext
287,52: __ZN18IGTelemetryManager16prepareTelemetryEj
304,41: __ZN16IntelAccelerator5startEP9IOService
360,32: __ZN31AppleIntelFramebufferController16getOSInformationEv
// IGFX::MMIORegistersReadSupport::processFramebufferKext
461,13: __ZN31AppleIntelFramebufferController14ReadRegister32Em
// IGFX::MMIORegistersWriteSupport::processFramebufferKext
551,13: __ZN31AppleIntelFramebufferController15WriteRegister32Emj
// IGFX::ForceCompleteModeset::processFramebufferKext
634,4: __ZN31AppleIntelFramebufferController16hwRegsNeedUpdateEP21AppleIntelFramebufferP21AppleIntelDisplayPathPNS_10CRTCParamsEPK29IODetailedTimingInformationV2
// IGFX::ForceOnlineDisplay::processFramebufferKext
709,4: __ZN21AppleIntelFramebuffer16getDisplayStatusEP21AppleIntelDisplayPath
// IGFX::AGDCDisabler::processFramebufferKext
747,4: __ZN20IntelFBClientControl11doAttributeEjPmmS0_S0_P25IOExternalMethodArguments
// IGFX::TypeCCheckDisabler::processFramebufferKext
779,5: __ZN31AppleIntelFramebufferController17IsTypeCOnlySystemEv
// IGFX::BlackScreenFix::processFramebufferKext
816,5: __ZN31AppleIntelFramebufferController16ComputeLaneCountEPK29IODetailedTimingInformationV2jPj
// IGFX::PAVPDisabler::processGraphicsKext
898,14: __ZN16IntelAccelerator19PAVPCommandCallbackE22PAVPSessionCommandID_tjPjb
// IGFX::wrapLoadFirmware
1230,9: __ZN12IGScheduler415systemWillSleepEv
1230,51: __ZN12IGScheduler413systemDidWakeEv
// IGFX::loadIGSchedular4Patches
1356,60: __ZL17__KmGen9GuCBinary
1360,46: __ZN13IGHardwareGuC13loadGuCBinaryEv
1390,9: __ZN12IGScheduler412loadFirmwareEv
1391,9: __ZN13IGHardwareGuC16initSchedControlEv
1392,9: __ZN20IGSharedMappedBuffer11withOptionsEP11IGAccelTaskmjj
kern_weg.cpp
// WEG::processKext
347,64: __ZL16gIOFBVerboseBoot
349,41: __ZN13IOFramebuffer6initFBEv
360,6: __ZN25AppleMCCSControlGibraltar5probeEP9IOServicePi
361,6: __ZN21AppleMCCSControlCello5probeEP9IOServicePi
373,40: __ZN15AppleIntelPanel10setDisplayEP9IODisplay
// WEG::processGraphicsPolicyMods
626,40: __ZN25AppleGraphicsDevicePolicy5startEP9IOServiceA thought I had was to trace references to potential internal display flags in the CFL fb driver logic. The assumption is that there may be some blocking/conflicting behavior when an internal display is connected w/ the screenpad, similar to how some internal display flags appear to affect specific functionality for external displays. I've seen flags Notably with the UX581GV (CFL-H) and UX582LV (CML-H) models, there were some observations of different behavior with the screenpad when the primary display isn't connected; e.g. some framebuffers that disable the primary display connector allowed the screenpad to work for those ZenBook Pro Duo models. For the case of the UX581GV, the screenpad still showed static however. You can find a breakdown of some of these reports here (most notably rogerdcarvalho's): CC @shiecldk and @rogerdcarvalho if you have any more input here. Unfortunately, I haven't reproduced the same behavior on the UX481FL model, which doesn't have any similar change in behavior regardless of framebuffer/busID/etc connector patches; even when the primary display is physically disconnected. I did also experiment with some FeatureControl flags in the CFL framebuffer driver. Changing the CachedEDIDDisable and/or IgnorePanelTmings FeatureControl options on the CFL framebuffer driver doesn't change any behavior here (and probably shouldn't unless there is some EDID caching issue). Thought I should mention that as (I believe) it was suggested as a potential fix in wern-apfel/WhateverGreen@16413cf. Additionally, I also have tried some other workarounds that had been suggested in other issues (e.g. Ardentwheel/OpenCore-Hasee-X57S1#3) but I haven't noticed any clear change in behavior or logs. Are there any other mitigations currently possible with WhateverGreen that can help isolate this behavior if this may be caused by some resource conflict or read failure w/ either the CFL framebuffer driver or the framebuffer controller? |
|
Not sure there is anything WEG can handle. if I remember correctly, there is no proper concept of power-off in Apple drivers, and it may well be that this second display is connected via some proprietary MUX thus no dice. |
|
Yeah, there don't appear to be any current WEG patches that directly address this issue. However, this issue may require patching CFL framebuffer driver logic with hex patching or by hooking w/ WEG. Additionally, there is no MUX involved with the screenpad; display signals are split between a DDI interface with the CPU with additional sideband signals to the PCH. Regarding hardware compatibility with macOS, the screenpad has been tested as working between @shiecldk (UX582) and @wern-apfel (UX481), albeit the latter has not yet been reproduced. |
|
@vit9696 I'd prefer leaving this issue open until it's been resolved (for visibility), though depending on how you triage your issues it'd be fair to re-open and mark it low-priority until there is more progress. A current blocker is a lack of observability for the UX582LV's case (unaffected by this issue); there is a unique opportunity to compare with the UX581LV (affected by this issue), which has very small hardware + firmware differences. |
|
This is a compiled list of current reports for reference: ASUS Zenbook Pro Duo 15":
ASUS Zenbook Duo 14"
|
Background
I've been investigating an issue with the secondary screenpad display on the ASUS Zenbook Duo notebooks that causes RGB static when the display device is initialized. This behavior only occurs during the second stage of boot into macOS or recoveryOS or upon hot-plug of the screenpad device. This appears to affect UX481FA/UX481FL (CML-U) Zenbook Duo models and UX581GV (CFL-H) + UX581LV / UX582LV (CML-H) Zenbook Pro Duo models, albeit the latter CML-H models are largely unaffected by this issue.
This does not appear to be a bug with WhateverGreen or an issue caused by/addressable with EDID patching or CSM, but a conflict w/ the framebuffer controller or CFL driver. I've verified that this is not a configuration issue suitable for support forums through my tracking in Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh#4.
For clarity (as the description of 'static' is quite vague), here is a video of the display static w/ misc DDC functions like backlight, panel power, and hot-plug demonstrated as working:
IMG_0838-H264_Proxy_half_size.mov
Observed Behavior
The screenpad works correctly during the first stage of boot (w/ GOP before GPU driver initialization), but after the second stage of boot, the screenpad displays static. It also shows a black screen very briefly upon hot-plug (before macOS initializes the display) or when no display connector is defined for con1/index1 (disabled); this behavior is expected. Otherwise, the static issue is present regardless of the framebuffer profile or busID + connector type, coinciding w/ when the display is initialized by macOS.
I've noted some other observations that help clarify this behavior:
Testing configuration
I've tested this with a UX481FL ZenBook Duo with an i7-10510u (CML-U) CPU and UHD 620 iGPU. Connected to the iGPU (in DDI order) are an eDP primary display, a DP secondary (screenpad) display, and an HDMI 1.4 port; both the primary display and HDMI connector work fine. The DisplayPort connector/signals from the screenpad aren't at all exotic, though I've started to detail some of ASUS's implementation here. This was tested with DVMT set to 64mb in BIOS (w/ no CSM option), and across all mobile CFL/CML framebuffer ids + connector patches (busids, etc).
As hardware availibility for these laptops is limited, I'd also appreciate input + reports for this issue by anyone affected. I've created a very rudimentary debug script here for dumping kernel logs and some misc. diagnostics + ioreg output.
For reference, below is a debug build of my UX481FA/FL EFI with a copy of my current config.plist:
This is how the screenpad display shows up in System Information (also using a display override):
Additional Documentation and Logs
Logs
Below are logs dumped using
liludump=60 -liludbg -wegdbgboot args:I've attached the output of the debug script (ref) containing some common kernel and system logs from my UX481FL:
For reference, below is a pruned log of CFL driver kernel logs containing only relevant lines for the screenpad (FB1) emitted after hot-plugging the display:
This log was synced to the device's physical behavior based on a screen + device recording.
Hot-plug.log.synced.mov
Hardware Docs
For brevity, only the most relevant resources are included below.
Display Panels
• UX582LV
You can find a list of all related hardware docs here.
The text was updated successfully, but these errors were encountered: