Qonfused
commented
1 year ago 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 symbols
```cpp kern_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: __ZN25AppleGraphicsDevicePolicy5startEP9IOService ```A 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 CNUnknownFlag_10 (#442) and CNUnknownFlag_100 (#1189) mentioned in other issues to have some side effects of disabling HDMI audio and display rotation.
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 https://github.com/wern-apfel/WhateverGreen/commit/16413cf1d9c34b4381a472ea98d9db5c52206814. Additionally, I also have tried some other workarounds that had been suggested in other issues (e.g. https://github.com/Ardentwheel/OpenCore-Hasee-X57S1/issues/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?
vit9696
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 https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/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:
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.
https://user-images.githubusercontent.com/32466081/227744065-b3f8b14f-7980-4ba7-b082-c79640716785.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.