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
30 stars 1 forks source link

[Kernel/FB] ScreenPad display static on FB initialization #4

Open Qonfused opened 2 years ago

Qonfused commented 2 years ago

Follow up to https://github.com/shiecldk/ASUS-ZenBook-Pro-Duo-15-OLED-UX582-Hackintosh/issues/2 investigating scrambled screenpad plus display-out.

Current tasks:

rogerdcarvalho commented 1 year ago

Please find my dumped DSDT and all ACPI files at https://cloud.rdcmedia.net/index.php/s/Qmqmk4gw55xrqPs, maybe it can provide a hint

Qonfused commented 1 year ago

@rogerdcarvalho What does the BIOS path look like for the screenpad plus in Device Manager? Should be under display devices and titled generic display (the oled display is probably named 'internal' or 'built-in').

rogerdcarvalho commented 1 year ago

@rogerdcarvalho What does the BIOS path look like for the screenpad plus in Device Manager? Should be under display devices and titled generic display (the oled display is probably named 'internal' or 'built-in').

Is "_SB.PCI0.GFX0.DD05" what you mean? or "DISPLAY\BOE085F\4&138DDC8&0&UID224795"?

Qonfused commented 1 year ago

Yes, thank you!

Like the UX481FA and UX481FL, there doesn't appear to be any direct reference to the screenpad plus in your DSDT. May need to take a closer look at what ACPI calls are made from the ASUS ScreenXpert driver.

Here are the two screenpad displays' entries (UX481 and UX581/UX582) from the linuxhw EDID repo: MFG Model Name Res Inch Made ID
BOE BOE087F HF NV126B5M-N41 1920x515 12.6 2019 46E74341751E
BOE BOE085F (missing) 3840x1100 14.0 2019 30E31C6BE9CB

@rogerdcarvalho Would you be able to check if your screenpad reports the correct screen size (14" and 3840x1100) from System Information > Graphics/Displays, and under About this Mac > Displays or System Settings > General > About > Displays?

If you have the time, include screenshots using both platform-ids w/ framebuffer patches.

rogerdcarvalho commented 1 year ago

Yes, thank you!

Like the UX481FA and UX481FL, there doesn't appear to be any direct reference to the screenpad plus in your DSDT. May need to take a closer look at what ACPI calls are made from the ASUS ScreenXpert driver.

Here are the two screenpad displays' entries (UX481 and UX581/UX582) from the linuxhw EDID repo:

MFG Model Name Res Inch Made ID BOE BOE087F HF NV126B5M-N41 1920x515 12.6 2019 46E74341751E BOE BOE085F (missing) 3840x1100 14.0 2019 30E31C6BE9CB @rogerdcarvalho Would you be able to check if your screenpad reports the correct screen size (14" and 3840x1100) from System Information > Graphics/Displays, and under About this Mac > Displays or System Settings > General > About > Displays?

If you have the time, include screenshots using both platform-ids w/ framebuffer patches.

Yup, under any platform ID (or any patch that starts with 03 for that matter) the screenpad reports the correct size (and even edid)

image

image

Qonfused commented 1 year ago

EDID looks to be read and applied correctly in both cases, which is good. I'm assuming display settings shows resolution options for the screenpad plus?

@rogerdcarvalho What does system information show for the displays when using platform-id 3EA50009 without any framebuffer patches?

Maleficent-Magik commented 1 year ago

Interesting, this one detects 14,1 Inch with a good resolution...

Qonfused commented 1 year ago

Will take a closer look at the 303 BIOS version for the UX582GL using UEFITool. I also found OZMTool which can extract the DSDT from a BIOS file (unclear if generally compatible); will give that a shot as well.

rogerdcarvalho commented 1 year ago

EDID looks to be read and applied correctly in both cases, which is good. I'm assuming display settings shows resolution options for the screenpad plus?

@rogerdcarvalho What does system information show for the displays when using platform-id 3EA50009 without any framebuffer patches?

Only the main screen would be detected. It's like the screenpad is not there.

Qonfused commented 1 year ago

I had no dice in extracting the DSDT w/ OZMTool (which I thought would still work even if the BIOS update only includes part of the BIOS). ASUS appears to have switched to a proprietary format since I've last done something like this.

I realized that shiecldk already shared debug files in https://github.com/hieplpvip/AsusSMC/issues/102#issue-962381803 which includes an ACPI dump (from Aug 5 '21, so about 4 days after fixing the screenpad plus).

Only the main screen would be detected. It's like the screenpad is not there.

@rogerdcarvalho Could you include a screenshot of the graphics/displays section of system information using one of the other framebuffer-ids?

rogerdcarvalho commented 1 year ago

I had no dice in extracting the DSDT w/ OZMTool (which I thought would still work even if the BIOS update only includes part of the BIOS). ASUS appears to have switched to a proprietary format since I've last done something like this.

I realized that shiecldk already shared debug files in hieplpvip/AsusSMC#102 (comment) which includes an ACPI dump (from Aug 5 '21, so about 4 days after fixing the screenpad plus).

Only the main screen would be detected. It's like the screenpad is not there.

@rogerdcarvalho Could you include a screenshot of the graphics/displays section of system information using one of the other framebuffer-ids?

Screenshot just shows the main screen without any details: image

Thanks so much for that link, I've been able to compare both my DSDT and shiecldk's, and there aren't any meaningful differences in anything that mentions _SB_.PCI0.GFX0. The only main difference I could find was that on shiecldk's machine, there is a function that behaves slightly differently:

Device (LID)
        {
            Name (_HID, EisaId ("PNP0C0D") /* Lid Device */)  // _HID: Hardware ID
            Method (_LID, 0, NotSerialized)  // _LID: Lid Status
            {
                Local0 = One
                Local0 = RPIN (0x11)
                If ((Local0 == Ones))
                {
                    Local0 = One
                }

                /* This section is missing in my DSDT
                Local0 = RPIN (One)
                If ((Local0 == Ones))
                {
                    Local0 = One
                }
                */
                If (IGDS)
                {
                    ^^^^GFX0.GLID (Local0)
                }
                Return (Local0)
            }
        }

I however doubt that this is the culprit. Interestingly, the hardware ID of the second screen DD05 doesn't appear anywhere in the DSDT, whereas the main screen DD1F appears twice (doing exactly the same thing on both devices). The 'ScreenXpert interface' ASXC also has no differences.

This problem is so weird, I spent hours and hours playing around with frame buffer patches, but nothing seems to make a difference. The fact that others have got it to work with such minimal hardware differences is really odd to me. Do you have any recommendations of other things I should be looking for when comparing DSDTs, or is there another ACPI file I should be looking at to identify issues with either DisplayPort or Monitor?

Qonfused commented 1 year ago

I however doubt that this is the culprit. Interestingly, the hardware ID of the second screen DD05 doesn't appear anywhere in the DSDT, whereas the main screen DD1F appears twice (doing exactly the same thing on both devices). The 'ScreenXpert interface' ASXC also has no differences.

This problem is so weird, I spent hours and hours playing around with frame buffer patches, but nothing seems to make a difference. The fact that others have got it to work with such minimal hardware differences is really odd to me. Do you have any recommendations of other things I should be looking for when comparing DSDTs, or is there another ACPI file I should be looking at to identify issues with either DisplayPort or Monitor?

I figured that there might have been an ACPI table not included in the DSDT that either the ScreenXpert driver or ASUSSystemControllInterface driver manipulates. On a non-OEM install of windows, the screenpad does not work OOB without these drivers, which is odd given it works on Linux w/o any specialized drivers. Brightness control for the screenpad used WMI methods that wrote to the embedded controller directly (for ScreenXpert), so if it used WMI similarly it presumably would show up in the WMI section of the DSDT.

To me it seems like shiecldk had threw everything at the wall with his framebuffer patches:

Debug config.plist Latest config.plist
Screenshot 2023-01-12 at 10 17 44 AM Screenshot 2023-01-12 at 10 17 48 AM

^^ The lilucpu=10 boot arg forces CPU detection as 10th gen (which is unnecessary and odd). I'm unsure of what disabling agdc actually did there either. The agdpmod boot arg in latest also doesn't do anything (it's meant for AMD GPUs).

I had thought that maybe the SSDT-IMEI could be related, which addresses exotic configurations that have a newer/older chipset that doesn't match with the CPU. Not only is that not the case, but it is also nowhere present in the Aug 5 EFI. SSDT-GPRW is the only non-stock ssdt in that config, but it addresses instant-wake (sleep issue) and is not related.

Qonfused commented 1 year ago

@ rogerdcarvalho Could you include a screenshot of the graphics/displays section of system information using one of the other framebuffer-ids?

Screenshot just shows the main screen without any details:

@rogerdcarvalho You'll want to type System Information in spotlight (launches a separate app) and go to Graphics/Displays. Ventura has unfortunately made this process very confusing if you're used to navigating to it through About this Mac.

Just want to verify that detection there is valid even if it doesn't show up in display settings.

rogerdcarvalho commented 1 year ago

@ rogerdcarvalho Could you include a screenshot of the graphics/displays section of system information using one of the other framebuffer-ids?

Screenshot just shows the main screen without any details:

@rogerdcarvalho You'll want to type System Information in spotlight (launches a separate app) and go to Graphics/Displays. Ventura has unfortunately made this process very confusing if you're used to navigating to it through About this Mac.

Just want to verify that detection there is valid even if it doesn't show up in display settings.

Yup, not detected at all.. Also added a screenshot with the frame buffer patch, which interestingly shows the 30 bit color instead of 24

image

image

Qonfused commented 1 year ago

This at least confirms that it's the same behavior causing this issue.

rogerdcarvalho commented 1 year ago

I however doubt that this is the culprit. Interestingly, the hardware ID of the second screen DD05 doesn't appear anywhere in the DSDT, whereas the main screen DD1F appears twice (doing exactly the same thing on both devices). The 'ScreenXpert interface' ASXC also has no differences.

This problem is so weird, I spent hours and hours playing around with frame buffer patches, but nothing seems to make a difference. The fact that others have got it to work with such minimal hardware differences is really odd to me. Do you have any recommendations of other things I should be looking for when comparing DSDTs, or is there another ACPI file I should be looking at to identify issues with either DisplayPort or Monitor?

I figured that there might have been an ACPI table not included in the DSDT that either the ScreenXpert driver or ASUSSystemControllInterface driver manipulates. On a non-OEM install of windows, the screenpad does not work OOB without these drivers, which is odd given it works on Linux w/o any specialized drivers. Brightness control for the screenpad used WMI methods that wrote to the embedded controller directly (for ScreenXpert), so if it used WMI similarly it presumably would show up in the WMI section of the DSDT.

To me it seems like shiecldk had threw everything at the wall with his framebuffer patches:

Debug config.plist Latest config.plist Screenshot 2023-01-12 at 10 17 44 AM Screenshot 2023-01-12 at 10 17 48 AM ^^ The lilucpu=10 boot arg forces CPU detection as 10th gen (which is unnecessary and odd). I'm unsure of what disabling agdc actually did there either. The agdpmod boot arg in latest also doesn't do anything (it's meant for AMD GPUs).

I had thought that maybe the SSDT-IMEI could be related, which addresses exotic configurations that have a newer/older chipset that doesn't match with the CPU. Not only is that not the case, but it is also nowhere present in the Aug 5 EFI. SSDT-GPRW is the only non-stock ssdt in that config, but it addresses instant-wake (sleep issue) and is not related.

Interesting.... Could it perhaps be that the Windows driver may update the firmware similarly to how some WiFi cards get firmware pushed? Perhaps trying an older version of ScreenXpert on a fresh Windows install could get my machine in the same state of the other users, but I'd struggle to know which version to install......

Qonfused commented 1 year ago

Interesting.... Could it perhaps be that the Windows driver may update the firmware similarly to how some WiFi cards get firmware pushed? Perhaps trying an older version of ScreenXpert on a fresh Windows install could get my machine in the same state of the other users, but I'd struggle to know which version to install......

I figure that there might be some device enable method like a _STA method that switches from a legacy video mode or similar. I'll have to look the device schematic more closely to see what devices the screenpad is linked to.

I'm a bit puzzled since wern-apfel didn't appear to fix anything exotic with his EFI; there is a confounding issue here for both devices that is hard to address with how black-box macOS is. Another user opened an issue for it on his config's repo here; it appears that he is just busy atm, but supposedly no fix from changing his EFI? I'm more worried about what is causing the issue than what solved it since this could easily resurface again without an explicit patch.

Maleficent-Magik commented 1 year ago

I'm a bit puzzled since wern-apfel didn't appear to fix anything exotic with his EFI; there is a confounding issue here for both devices that is hard to address with how black-box macOS is. Another user opened an issue for it on his config's repo here; it appears that he is just busy atm, but supposedly no fix from changing his EFI? I'm more worried about what is causing the issue than what solved it since this could easily resurface again without an explicit patch.

What if to solve the problem, it would be enough to patch the BusIDs and the whole mess (while selecting the right framebuffer too) first, and to install MacOS afterwards?

As if MacOS doesn't take into account some changes...

(Again, this is just a simple reasoning I'm trying to find... It is possible that my reasoning is totally WRONG)

rogerdcarvalho commented 1 year ago

I'm a bit puzzled since wern-apfel didn't appear to fix anything exotic with his EFI; there is a confounding issue here for both devices that is hard to address with how black-box macOS is. Another user opened an issue for it on his config's repo here; it appears that he is just busy atm, but supposedly no fix from changing his EFI? I'm more worried about what is causing the issue than what solved it since this could easily resurface again without an explicit patch.

What if to solve the problem, it would be enough to patch the BusIDs and the whole mess (while selecting the right framebuffer too) first, and to install MacOS afterwards?

As if MacOS doesn't take into account some changes...

(Again, this is just a simple reasoning I'm trying to find... It is possible that my reasoning is totally WRONG)

I don't think it would work because even if you boot from a USB that has macOS installer, the screen is already garbled when setup starts

rogerdcarvalho commented 1 year ago

One thing I did discover however.... if I don't turn on my screenpad, the main screen actually doesn't go to 24 bit but goes to 30 bit:

image

But then as soon as I turn on the screenpad, it reverts to 24 Bit color, but sends 30 bit to the screenpad. Could it be that somehow it turns on the screenpad first and tries to send the 30 bits to the wrong monitor? I've been playing around with edid overrides that seem to work well, if I force 24 bit on the internal monitor it will respect the override and go to 24 bit instead of 30. However, if I do the same for the screenpad, it just ignores the setting and still forces 30 bit... Where could it be getting that information from?

Qonfused commented 1 year ago

I don't think it would work because even if you boot from a USB that has macOS installer, the screen is already garbled when setup starts

Yeah, I had asked @wern-apfel whether or not the problem was still persistent in recovery, as it would indicate that the issue is unrelated to iGPU acceleration.

But then as soon as I turn on the screenpad, it reverts to 24 Bit color, but sends 30 bit to the screenpad. Could it be that somehow it turns on the screenpad first and tries to send the 30 bits to the wrong monitor? I've been playing around with edid overrides that seem to work well, if I force 24 bit on the internal monitor it will respect the override and go to 24 bit instead of 30. However, if I do the same for the screenpad, it just ignores the setting and still forces 30 bit... Where could it be getting that information from?

I believe macOS assumes this behavior independently from EDID color data, though I don't know the cause.

rogerdcarvalho commented 1 year ago

One other thing I discovered is that in Windows, the shared memory for the intel 630 is not 4GB but 8GB. Is it possible to set Framebuffer-unifiedmem to this value to test? Not sure what the hex would be for that...

Qonfused commented 1 year ago

One other thing I discovered is that in Windows, the shared memory for the intel 630 is not 4GB but 8GB. Is it possible to set framebuffer-unifiedmem to this value to test? Not sure what the hex would be for that...

I don't believe this is actually necessary. Setting DVMT in BIOS to 64 MB or more should work fine; the framebuffer profile doesn't actually require any more memory than 53-ish MB, so adding more memory beyond something like 4 GB wouldn't resolve any issues.

Qonfused commented 1 year ago

Looking at the UX481FL schematic, I noticed that some signals for the screenpad's displayport and HDMI are tied to legacy DDI interfaces (page 89 of 10th gen platform datasheet; there's a helpful diagram on page 90 showing how these are connected). Presumably the screenpad on the UX581GV does the same. The DDPB and DDPC are standard aliases for DDI1 and DDI2, which are the DDI interfaces (Page 3, U0301A):

DDI 1 + DDI 2 DDPB + DDPC
image
image		 image
Screenshot 2023-01-12 at 2 53 14 PM

The primary display (eDP), screenpad plus (DP), and HDMI all have a hot-plug line connected to the PCH (DP_HPD_PCH, eDP_HPD_PCH, HDMI_HP), which I have tested as working for the primary display (eDP->PCH) and HDMI (DDI->PCH). The SCI and SMI interrupts occupying the latter DPPx interfaces there handle power management and other misc device controls (cf. SMM: https://en.wikipedia.org/wiki/System_Management_Mode), though it's unclear to me how these interact with macOS. Note that the SMI interrupt is not Windows SMI.

I did notice some SCL and SDA lines connected from the screenpad (DDPB) to the PCH, which I included in the bottom right screenshot. These are the serial clock and data lines respectively, which I imagine are used for sending initialization data to the display controller over I2C.

Qonfused commented 1 year ago

The display should communicate between any/all of these signals in windows and macOS. Will need to investigate any PCH-related fixes or assumptions between the MacbookPro16,4 and MacbookPro16,3 SMBIOSes to figure out why this isn't working OOB, assuming there aren't any issues with current framebuffer patching. I'll also need to find a schematic for the UX581LV or UX582LV to verify that these are connected the same, though my assumption is that they are.

I don't have a logic analyzer or really any way to test if these are working correctly for the screenpad (or that there are issues caused by this), though if everything works for HDMI w/ an embedded DVI->DP adapter, it's confusing why it doesn't for the screenpad without any funky internal display adapter.

Qonfused commented 1 year ago

The only other thing I can think of is that maybe we're missing PCI bridges for the iGPU or for the screenpad, but there isn't any dependency on any pci bridges for either device path.

rogerdcarvalho commented 1 year ago

I've been playing around more with frame buffer patching and discovered something that may lead us somewhere, but seems super arbitrary and complex.

Looking at https://github.com/acidanthera/WhateverGreen/blob/master/Manual/IntelFramebuffer.bt, the different connector flags used as part of the framebuffer-alldata values are explained there. I was particularly interested in:

/* AppleIntelFramebuffer::maxSupportedDepths checks this and returns 2 IODisplayModeInformation::maxDepthIndex ?? */
        uint8_t CNUnknownFlag_10             :1;  /* 0x10 */
        uint8_t CNUnknownFlag_20             :1;  /* 0x20 */

Playing around in Hackintool, you can generate a variety of combinations of the different connector flags. On the same port and bus number, changing the flags can sometimes lead to the screenpad not turning on at all, none of the displays working, or the screenpad turning on garbled. This makes me think that one of these flags may be where the 30 bit color framebuffer depth is injected. My theory is that because the system thinks 30 bit depth is supported, it sends these signals to the screenpad, which results in the garbled screen (as the edid clearly states the screen only supports 24 bit color).

I reckon that for some arbitrary reason something in the hardware or the EFI configuration of the people for which the screenpad does work, the system correctly sets the signal to 24 bit, which fixes the issue. It could be that the SMBios or some other configuration value forces the system to only consider 24 bit depth, but this could happen for a bunch of different reasons.

The problem is it isn't clear to me what all the flags mean, I've tried randomly changing between them, every time the system behaves differently, but I could obviously spend forever trying all different combinations.

Is there a way to override this function so it always returns a maxSupportedDepths of 24 bits? This could potentially be a solution? Alternatively, is there a way to better understand how the different flags interoperate?

Qonfused commented 1 year ago

Is there a way to override this function so it always returns a maxSupportedDepths of 24 bits? This could potentially be a solution? Alternatively, is there a way to better understand how the different flags interoperate?

I'm not sure, I haven't looked much into how these connector flags are set/read by macOS.

Qonfused commented 1 year ago

It seems CNUnknownFlag_10 sets the port for a connector to 0, and these appear to be used on LVDS displays as part of marking them as internal. There is an issue on https://github.com/acidanthera/bugtracker/issues/442 that describes this flag more in-depth, but this flag does not change framebuffer depth.

Maleficent-Magik commented 1 year ago

speaking of Wern Apfel, I was able to check his GitHub, and he forked WhatEverGreen by adding some code himself, it's quite interesting to try to understand what he could have added... but it seems that what he did and nothing is the same....

https://github.com/wern-apfel/WhateverGreen/commit/16413cf1d9c34b4381a472ea98d9db5c52206814

He talks a lot about "FramebufferCoffeeLakePatches." CoffeLake and CometLake is the same thing?

rogerdcarvalho commented 1 year ago

Coffee lake is gen9, Comet Lake is gen 10. The UX581 is Coffee lake. But what is weird is this was 6 days ago, after he had already supposedly fixed it no? The screenshots were from 2 weeks ago...

Qonfused commented 1 year ago

CometLake on macOS depends on the CoffeeLake drivers+framebuffer. WhateverGreen enumerates supported features by CPU generation, though you can see that the entry here is mostly copy+pasted: https://github.com/acidanthera/WhateverGreen/blob/2b8c16cab6c614540c7de7ae00d7eb289449f468/WhateverGreen/kern_igfx.cpp#L125-L138

case CPUInfo::CpuGeneration::CoffeeLake:
    supportsGuCFirmware = true;
    currentGraphics = &kextIntelKBL;
    currentFramebuffer = &kextIntelCFLFb;
    // Allow faking ask KBL
    currentFramebufferOpt = &kextIntelKBLFb;
    // Note, several CFL GPUs are completely broken. They freeze in IGMemoryManager::initCache due to incompatible
    // configuration, supposedly due to Apple not supporting new MOCS table and forcing Skylake-based format.
    // See: https://github.com/torvalds/linux/blob/135c5504a600ff9b06e321694fbcac78a9530cd4/drivers/gpu/drm/i915/intel_mocs.c#L181
    modForceCompleteModeset.supported = modForceCompleteModeset.enabled = true;
    modRPSControlPatch.available = true;
    modForceWakeWorkaround.enabled = true;
    modTypeCCheckDisabler.enabled = true;
    modBlackScreenFix.available = true;
    break;
case CPUInfo::CpuGeneration::CometLake:
    supportsGuCFirmware = true;
    currentGraphics = &kextIntelKBL;
    currentFramebuffer = &kextIntelCFLFb;
    // Allow faking ask KBL
    currentFramebufferOpt = &kextIntelKBLFb;
    // Note, several CFL GPUs are completely broken. They freeze in IGMemoryManager::initCache due to incompatible
    // configuration, supposedly due to Apple not supporting new MOCS table and forcing Skylake-based format.
    // See: https://github.com/torvalds/linux/blob/135c5504a600ff9b06e321694fbcac78a9530cd4/drivers/gpu/drm/i915/intel_mocs.c#L181
    modForceCompleteModeset.supported = modForceCompleteModeset.enabled = true;
    modRPSControlPatch.available = true;
    modTypeCCheckDisabler.enabled = true;
    modBlackScreenFix.available = true;
    break;

Not sure if he is trying to target Comet Lake since his code only explicitly references CoffeeLake to apply patches (CPUInfo::CpuGeneration::CoffeeLake). If he's trying to patch a comet lake CPU he'd need to use CPUInfo::CpuGeneration::CometLake instead to apply CoffeeLake framebuffer patches.

rogerdcarvalho commented 1 year ago

Maybe he's trying to fix the black oled screen on wake issue, doesn't have to be related to the screenpad

Qonfused commented 1 year ago

Maybe he's trying to fix the black oled screen on wake issue, doesn't have to be related to the screenpad

I believe he only has the UX481FA, though any modding of how WhateverGreen patches the framebuffer for that comet lake CPU can also apply for coffee lake. Not sure if this is targeting a different machine that has a coffee lake CPU either.

From what I can tell, the getOSDataValue() method from WIOKit loads user configuration data (e.g. our custom framebuffer patches). Not sure if these are actual features/device properties supported by coffee lake or comet lake igpus.

rogerdcarvalho commented 1 year ago

The display should communicate between any/all of these signals in windows and macOS. Will need to investigate any PCH-related fixes or assumptions between the MacbookPro16,4 and MacbookPro16,3 SMBIOSes to figure out why this isn't working OOB, assuming there aren't any issues with current framebuffer patching. I'll also need to find a schematic for the UX581LV or UX582LV to verify that these are connected the same, though my assumption is that they are.

I don't have a logic analyzer or really any way to test if these are working correctly for the screenpad (or that there are issues caused by this), though if everything works for HDMI w/ an embedded DVI->DP adapter, it's confusing why it doesn't for the screenpad without any funky internal display adapter.

FYI, my screenpad turns on garbled with SMBIOS MacBookPro15,2. If I pick MacBookPro15,1 (a closer match to my actual hardware), the screenpad doesn't turn on at all with the same framebuffer overrides. Whatevergreen never detects the screenpad with that SMBIOS. I'm still to play with SMBIOS 16,4 and 16,3, but again I have Coffeelake, so would prefer to optimize for 15,1.

Maleficent-Magik commented 1 year ago

though you can see that the entry here is mostly copy+pasted:

ah, lol... It's true that I haven't checked the veracity of the thing... I missed the essential thing bruh...

Qonfused commented 1 year ago

@ rogerdcarvalho FYI, my screenpad turns on garbled with SMBIOS MacBookPro15,2. If I pick MacBookPro15,1 (a closer match to my actual hardware), the screenpad doesn't turn on at all with the same framebuffer overrides. Whatevergreen never detects the screenpad with that SMBIOS. I'm still to play with SMBIOS 16,4 and 16,3, but again I have Coffeelake, so would prefer to optimize for 15,1.

I meant doing an ablative analysis between the MacbookPro16,4 and MacbookPro16,3 SMBIOSes.

rogerdcarvalho commented 1 year ago

FYI, my screenpad turns on garbled with SMBIOS MacBookPro15,2. If I pick MacBookPro15,1 (a closer match to my actual hardware), the screenpad doesn't turn on at all with the same framebuffer overrides. Whatevergreen never detects the screenpad with that SMBIOS. I'm still to play with SMBIOS 16,4 and 16,3, but again I have Coffeelake, so would prefer to optimize for 15,1.

I meant doing an ablative analysis between the MacbookPro16,4 and MacbookPro16,3 SMBIOSes.

Nah get that, just wanted to let you know garbled happens with 15,2 too, in case that could be of interest. I'll switch to 16,4 now to see if the screenpad turns on at all with that one.

Qonfused commented 1 year ago

Continuing https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1381029523, I found an Intel 7th gen (kaby lake) HD graphics reference manual that addresses these mappings w/ more detail (22nd page):

Screen Shot 2023-01-13 at 3 24 02 PM

There's a full-length one here as well.

Edit: Found 10th gen ice lake docs for comparison, but nothing for CFL/CML (page 119): https://www.x.org/docs/intel/ICL/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf.

Qonfused commented 1 year ago

I also noticed that the connector flags between the screenpad and HDMI are the same.

Maleficent-Magik commented 1 year ago

ConnectorFlag? What do you mean by this?

And also, can @rogerdcarvalho / @danperks (may potentially help too...) check if this is the case for them too?(with the screenpad active of course..)

Qonfused commented 1 year ago

They're the connector flags from hackintool (https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1381162357).

rogerdcarvalho commented 1 year ago

Sorry guys I can't properly support anymore, my zenbook sadly died.

Good luck though, will be keeping an eye on this thread and hope you guys figure it out!

danperks commented 1 year ago

ConnectorFlag? What do you mean by this?

And also, can @rogerdcarvalho / @danperks (may potentially help too...) check if this is the case for them too?(with the screenpad active of course..)

I'm probably just being dumb but what is it you want me to check? I'm happy to do whatever you guys need

Qonfused commented 1 year ago

@rogerdcarvalho Sorry guys I can't properly support anymore, my zenbook sadly died.

Good luck though, will be keeping an eye on this thread and hope you guys figure it out!

Regarding your laptop, there are still a couple of things you can try that may help:

I'd also recommend checking if you still have a warranty for this machine. In the US, the Magnuson-Moss warranty act should protect your warranty status from being voided by simply replacing your Wi-Fi card. You shouldn't have much trouble with ASUS if you're in the EU also.

If it doesn't require board-level repair, you can also find a lot of spare parts (i.e. display cables, batteries, etc: https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1215001389) from https://en.accessoires-asus.com/.

@danperks I'm probably just being dumb but what is it you want me to check? I'm happy to do whatever you guys need

He's referring to the connector flags for the screenpad (connector 1 or 2). I believe it's located under Patching > Connectors in Hackintool.

Also, is it still the case that your static screen issue leaves the right side of the screen black? I think I recall seeing a picture of this, though I'm not sure if it was from you.

rogerdcarvalho commented 1 year ago

I bought it at a used shop but did have warranty. They refunded me. Looked around for another UX581, but can't find anyone for a price I'm willing to pay. Don't want the UX582 because wifi is soldered on and the performance of Intel wifi is terrible. Who knows at some point I'll find another UX581, but until then I'll be cheering on you guys from the sideline!

Maleficent-Magik commented 1 year ago

ConnectorFlag? What do you mean by this? And also, can @ rogerdcarvalho / @ danperks (may potentially help too...) check if this is the case for them too?(with the screenpad active of course..)

I'm probably just being dumb but what is it you want me to check? I'm happy to do whatever you guys need

Hi @danperks, I would also like you to see if you have the same thing as @Qonfused in Hackintool, about the connectors flags between the Screenpad and the HDMI, or if it's just an isolated problem...

This is Hackintool :

image Do not go to the site of the image... it is a very bad site... but the image corresponds to what I want you to check

Well, the image does not match since Index 1 should be eDP / LSVD (in short, the port for the portable screen) Index 2 should be DP index 3 should be HDMI

_But the image wants to represent what I'm looking for._

I also noticed that the connector flags between the screenpad and HDMI are the same. as indicated by Qonfused

About @rogerdcarvalho , I'm sorry to hear that, it's too bad...

Qonfused commented 1 year ago

TODO

There was a PR (https://github.com/acidanthera/WhateverGreen/pull/92) that fixes similar behavior for built-in displays on ICL, however it calls a data buffer optimization at the time of completing a modeset for the built-in display. This does not however resolve this issue on the screenpad.

It's a fairly common practice, but there may also be an issue if there is a shared IRQ for the iGPU or screenpad ddi w/ another device.

Qonfused commented 1 year ago

Needed to add boot-args -wegdbg msgbuf=1048576 and use sudo dmesg | grep WhateverGreen to get debug logging.

Qonfused commented 1 year ago

Some brief notes on some clarifying behavior observed w/ the screenpad:

Additional notes: