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

[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:

Qonfused commented 1 year ago

Again, sorry for the confusion, as often happens in a hurry I don't read all the comments. I have no issues with Monterey, what I meant were issues with the implementation of the Screenpad patches in Monterey because of the sealed drive, Monterey is version 12.6.2. By help, I meant that it would help me if someone would test my EFI and give me feedback.

What version of macOS Catalina were you using before you had issues? This sounds like some kind of device override (display profile or similar), which should still work. Finder won't let you manipulate the folder so you'll need to move files manually in terminal. I did have issues with mounting the system (root) partition and similar (noted in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1328127976).

Are you having filesystem permission issues, issues resealing the drive, or does your display patch not work with SIP + resealed drive?

I don't think there is any point in tweaking your EFI because I looked at shielcdk's EFI a few weeks ago and it is a mess, or shall we say all you can get. 3 brightness patches, but instead uses gamma software, 2 battery patches and so on. You guys have changed a few things, but there is still useless stuff in there. I don't care if someone uses my EFI, so I didn't update it.

I had realized the same thing there for a while without even looking into ACPI at the time, so I understand that completely. Since #15. I've removed all the nonsense clover/rehabman kexts/patches that are now defunct and just started from scratch there; that's why I still need to revisit the UX581/UX582 to port these changes. I've already mentioned that a couple of times, though the result of #15 and #19 should yield no useless stuff in there so to speak. You'll want to look at this repo instead of shiecldk's when comparing your config to this one until I can bring the pro duo repo up to speed, which I'll then rebase this repo's tracking to that one.

My latest local commit (will commit later) includes all misc. device enables and fixes I could find (should re-enable SIP if disabled; requires reinstall of macOS to reseal). I'm just working on regression testing and adding more userspace tweaks w/ ATKD, but that should be the only difference between our configs (comparing last commit).

Maleficent-Magik commented 1 year ago

I meant were issues with the implementation of the Screenpad patches in Monterey because of the sealed drive

So, I'm a bit of a BIG novice in MacOS and stuff... and in complicated English in this case, but what did you mean by : "of the sealed drive"

Could you explain a little bit what it is? ^^'

Qonfused commented 1 year ago

It's part of APFS and essentially means signed for security purposes; the seal can break when disabling SIP and modifying system files. It's purpose since Catalina is mainly to isolate system and user space. I don't know much of what his specific issue.

Maleficent-Magik commented 1 year ago

oh okay thanks @Qonfused !

Qonfused commented 1 year ago

Btw, I do explain this in a bit more depth in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/6.

Also explore the DDC track (French: Wikipedia DDC French Version sorry...)

There might be something... but I doubt... I really think it must have more to do with an SSDT than handling it by hand like that...

This was a solution I was looking into for controlling OLED brightness for the UX581/UX582 (via MonitorControl). It should work for most external displays and can be patched for the screenpad plus if it doesn't work OOB.

At least, if @ wern-apfel could tell us, a little idea since he has the same PC, the same configuration...

His configuration writes directly to the embedded controller to manipulate screen brightness; the implementation is borrowed from the ACPI methods that normally control it in windows, which are the WMI methods that were mentioned in this thread earlier when discussing backlight (https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1328165864).

For reference, this is the ACPI code responsible for controlling screenpad backlight in wern-apfel's config:

https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/blob/aa500752db161e030f6465920db07b3eaf2daa17/Resources/ACPI/SSDT-ATKD.dsl#L173-L226

Qonfused commented 1 year ago

Again, sorry for the confusion, as often happens in a hurry I don't read all the comments. I have no issues with Monterey, what I meant were issues with the implementation of the Screenpad patches in Monterey because of the sealed drive, Monterey is version 12.6.2. By help, I meant that it would help me if someone would test my EFI and give me feedback.

@wern-apfel Just to clarify, I can help you resolve this and any other issues you have with your EFI.

From what I can gauge, it sounds like you're unable to modify your root partition or otherwise are having issues applying overrides/loading kexts/whatever it is you're doing due to permission issues with APFS. I'll need to know what it is you're trying to do or what part of the filesystem you're trying to modify, otherwise I can't really tell what SIP protections may be blocking you. Is there any behavior you notice to cause instability w/o those patches (regarding the application of those patches, not SIP), or if you're able to modify your root partition what indicates that they aren't working?

I've outlined some general steps that you can check to figure out the cause of your issue more fully (and are worth verifying anyways):

This workaround for M1 macs may also be of interest to you: https://gist.github.com/ejdyksen/8302862?permalink_comment_id=4207925#gistcomment-4207925

Maleficent-Magik commented 1 year ago

His configuration writes directly to the embedded controller to manipulate screen brightness; the implementation is borrowed from the ACPI methods that normally control it in windows, which are the WMI methods that were mentioned in this thread earlier when discussing backlight (https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1328165864).

For reference, this is the ACPI code responsible for controlling screenpad backlight in wern-apfel's config:

Oh okay i see that. Thanks for remember, as well i have see all FN+FX (all the keys of the keyboard F1,F2, F3, etc...) I understand better with the comments who does what

Until I have more information on the next step of the project, if you want me to test something, let me know @Qonfused and I will answer you.

Same to you @wern-apfel ! If you want me to test your EFI, let me know, ask me about what you want to know if it works or not and I will answer you, I have 3 USB keys:

One with Qonfused's EFI, one with my own EFI when I fiddle with desuss, and if you want another with your EFI @wern-apfel . I can work on all 3 at once without problems.

In the meantime, happy new year, and let's keep working, it's great! As long as we can find the problem together, it's good...

Maleficent-Magik commented 1 year ago

Okay, I've been using DarwinDumper software, and I've found some funny things if I may say in the EDID

EDID Decode Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 09 e5 7f 08 00 00 00 00 01 1d version: 01 04 basic params: a5 1f 08 78 02 chroma info: d2 2d 93 51 57 8d 28 18 4e 52 established: 00 00 00 standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 94 1b 80 a0 70 03 32 20 30 20 55 00 35 53 10 00 00 1a descriptor 2: 12 16 80 a0 70 03 32 20 30 20 55 00 35 53 10 00 00 1a descriptor 3: 00 00 00 fe 00 42 4f 45 20 48 46 0a 20 20 20 20 20 20 descriptor 4: 00 00 00 fe 00 4e 56 31 32 36 42 35 4d 2d 4e 34 31 0a extensions: 00 checksum: ed 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 Maximum image size: 31 cm x 8 cm Gamma: 2.20 Supported color formats: RGB 4:4:4 First detailed timing is preferred timing Chroma Info: Red X: 0.577148 Y: 0.317383 Green X: 0.339844 Y: 0.552734 Blue X: 0.156250 Y: 0.095703 White X: 0.307617 Y: 0.321289 Established timings supported: Standard timings supported: 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 Checksum: 0xed (valid) EDID block does NOT conform to EDID 1.3! Missing name descriptor Missing monitor ranges Detailed block string not properly terminated

Already the sizes are too big, and the refresh rate is above 60 or 59 mhz...

Maleficent-Magik commented 1 year ago
File Download Description
EDID2.txt Matches EDID extraction in a .txt file
EDID2.bin (in.zip for GitHub...) Corresponds to the EDID extraction in a .bin file but to be accepted on GitHub I put it in a ZIP file
EDID2.hex (in .zip for GitHub) Corresponds to the EDID extraction in a .hex file but to be accepted on GitHub I put it in a ZIP file
DarwinDumper_3.1.1_2023.01.02_18.34.53_MacBookPro16,3_Opencore_4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102opencore-versionDBG-087-2022-12-06_Unknown_21G72_magik.zip Extraction of TOTAL information on my pc (Always via MacOS) There is a LOT of stuff... ACPI, DSDT, Kexts loaded, reports etc. !! Use 7Zip for Extract, Windows don't like my name... !!
Qonfused commented 1 year ago

My EDID is also the same (including @VillenaDeveloper).

Okay, I've been using DarwinDumper software, and I've found some funny things if I may say in the EDID

Does this report as 24-bit color in system info? The '8 bits per primary color channel' should correspond to 24-bit color (ARGB8888) in macOS if the EDID is properly ingested.

Already the sizes are too big, and the refresh rate is above 60 or 59 mhz...

I believe those additional sizes are for overscan or something related; they may not be problematic unless it's supposed to be reported differently for Apple displays.

The 70.6 MHz and 56.5 MHz values refer to the pixel clock range, which tells us the allowed range for the display's refresh rate. 60 MHz falls within this range and should be supported, though there exists no explicit resolution for 1920x515@60.

Qonfused commented 1 year ago

Some additional steps building on Big Sur SIP changes from the post-install guide are also listed in detail for Monterey in https://stackoverflow.com/a/73422893.

You can write to and persist changes to your root drive by creating a new snapshot, but re-enabling SIP or the signed system volume will revert any changes. This happens on OS updates as well, so this can also break from delta-updates.

If possible, place it in the /Library directory (if the appropriate subdirectory exists) instead of the system protected /System/Library directory.

You can create the display overrides directory manually:

sudo mkdir -p /Library/Displays/Contents/Resources/Overrides

And proceed from there.

Qonfused commented 1 year ago

This is a display override file for fixing resolutions (download to ~/Desktop as DisplayProductID-87f with no file extension):

<!-- ~/Desktop/DisplayProductID-87f -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>DisplayProductName</key>
    <string>ScreenPad Plus Display</string>
    <!-- PID 0x87f -> 2175 -->
    <key>DisplayProductID</key>
    <integer>2175</integer>
        <!-- VID 0x9e5 -> 2533 -->
    <key>DisplayVendorID</key>
    <integer>2533</integer>
        <!-- Same EDID as before -->
    <key>IODisplayEDID</key>
<data>AP///////wAGEBSgAAAAAAoWAQSlHRJ4Am+xp1VMniUMUFQAAAABAQEBAQEBAQEBAQEBAQEBlBuAoHADMiAwIFUANVMQAAAaEhaAoHADMiAwIFUANVMQAAAaAAAA/ABDb2xvciBMQ0QKICAgAAAA/QA4TB5TEQAKICAgICAgAGo=</data>
    <key>scale-resolutions</key>
    <array>
        <!-- 1920x515 -> 00000780 00000203 -->
        <!-- 00000780 00000203 00000001 00200000 -->
        <data>AAAHgAAAAgMAAAABACAAAA==</data>
    </array>
</dict>
</plist>

And these are the appropriate commands for applying it:

sudo mkdir -p /Library/Displays/Contents/Resources/Overrides
sudo mkdir /Library/Displays/Contents/Resources/Overrides/DisplayVendorID-9e5
cd ~/Desktop
sudo cp DisplayProductID-87f /Library/Displays/Contents/Resources/Overrides/DisplayVendorID-9e5/DisplayProductID-87f
Qonfused commented 1 year ago

This reflects instructions for applying EDID patches to displays in https://gist.github.com/ejdyksen/8302862#instructions.

It does not work my case; CoreDisplay still applies a default 1280x720 resolution on the screenpad, and it is never properly initialized with this display override. It's possible that you may need to delete /Library/Preferences/com.apple.windowserver.displays.plist to override this behavior (as it's using some previous setting instead).

Qonfused commented 1 year ago

The EDID for the display reported from registry also matches the EDID in macOS:

// macOS EDID

00FFFFFF FFFFFF00 09E57F08 00000000 011D0104 A51F0878 02D22D93 51578D28
184E5200 00000101 01010101 01010101 01010101 0101941B 80A07003 32203020
55003553 1000001A 121680A0 70033220 30205500 35531000 001A0000 00FE0042
4F452048 460A2020 20202020 000000FE 004E5631 32364235 4D2D4E34 310A00ED

// Windows Registry:
// HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\BOE087F\4&71f0984&0&UID200195\Device Parameters\EDID

00FFFFFF FFFFFF00 09E57F08 00000000 011D0104 A51F0878 02D22D93 51578D28
184E5200 00000101 01010101 01010101 01010101 0101941B 80A07003 32203020
55003553 1000001A 12168010 70033220 30205500 35531000 001A0000 00FE0042
4F452048 460A2020 20202020 000000FE 004E5631 32364235 4D2D4E34 310A00ED
Qonfused commented 1 year ago

@wern-apfel What kind of display patch are you trying to do on Monterey?

Also, do you still have the scrambled screen issue in macOS Recovery or is it black?

Maleficent-Magik commented 1 year ago

i'm stupid this night, can you convert 2C58 in base10?

Qonfused commented 1 year ago

It would be 11352. You can also search 0x2C58 to decimal in spotlight and press space to preview a web result if you want a quick way of doing it.

Maleficent-Magik commented 1 year ago

big thanks ❤️ (Headache, it's boring :'))

Qonfused commented 1 year ago

The main thing I'm noticing OOB on Catalina is that the screenpad has the correct resolution data in system information, but reports the wrong framebuffer depth (30-bit color ARGB2101010). It's possible that the screenpad may be detected as a TV (reports 'NaN-inch' with 0x0 screen size and TV icon).

Maleficent-Magik commented 1 year ago

@Qonfused I don't think so because shiecldk has the same framebuffer depth for the 2 screens (both in 30 bit) Insanelymac.com Comment unless I didn't understand...

Qonfused commented 1 year ago

Both displays on windows report 8-bit (per color channel), which is the same as 24 bit in macOS. The screenpad plus on the UX581/UX582 are 8-bit as well.

The screenpad in shiecldk's case reports the correct physical size and screen size. I did attempt to correct this using BetterDisplay in order to verify the application, though the framebuffer depth still remains invalid and producing the same issue.

Some behavior contributing to this issue is from invalid EDID:

...
Checksum: 0xed (valid)
EDID block does NOT conform to EDID 1.4!
    Missing name descriptor
    Missing monitor range

If this is the cause of the scrambling behavior (since the remaining and expected issue is a black screen), then @wern-apfel's resolution was through an EDID patch or display profile addressing native resolution and size.

Maleficent-Magik commented 1 year ago 
Checksum: 0xed (valid)
EDID block does NOT conform to EDID 1.4!
  Missing name descriptor
  Missing monitor range
  • Qonfused

In any case it is the same for the main screen ... but we are on an EDID 1.3 ... So I'm not sure I understand...

main screen : 

ASCII string: N140HCE
ASCII string: CMN
ASCII string: N140HCE
Checksum: 0x10 (valid)
EDID block does NOT conform to EDID 1.3!
    Missing name descriptor
    Missing monitor ranges
    Detailed block string not properly terminated
Qonfused commented 1 year ago

I've fixed some issues using EDID 1.4 here: EDID-9e5-87f.bin.zip. I've fixed the PnPID (BOE) and vendor id (087f), as well as the color depth (6 bit -> 8 bit) and physical size (31 cm x 8 cm).

You can convert the binary format to hex and then to base64:

$ xxd -ps EDID-9e5-87f.bin > EDID-9e5-87f.txt
$ cat EDID-9e5-87f.txt | xxd -r -p | base64

Or convert the binary format directly to base64:

xxd -ps EDID-9e5-87f.bin | xxd -r -p | base64

The base64 output for this EDID edit results in this:

AP///////wAJ5X8IAAAAAAEdAQSlHwh4At0Zk1FWjSgYTlIAAAABAQEBAQEBAQEBAQEBAQEBkxuAoHADMiAwIFUANVMQAAAaEhaAoHADMiAwIFUANVMQAAAaAAAA/ABCT0UwODdGCiAgICAgAAAA/QA4TB5TEQAAAAAAAAAAAMkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

You'll need to override the display profile with the new EDID value using the method from https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1370245698. I'll try with and without the scale resolutions in case there is still an issue with CoreDisplay only matching the nearest 16:9 resolution.

Qonfused commented 1 year ago

May also try enabling the sRGB flag with AW EDID Editor.

Maleficent-Magik commented 1 year ago

So normally this is supposed to fix things?

Qonfused commented 1 year ago

If it doesn't it will at least help make patching through the display plist easier. I'm expecting that if it does anything it will probably result in a black screen instead which is a more normal issue (if it doesn't just outright fix it).

Qonfused commented 1 year ago

Doing an EDID override through opencore is preferred if the issue can be addressed with an EDID patch.

Maleficent-Magik commented 1 year ago

I was seeing this quickly but I don't think it's much help Youtube

Qonfused commented 1 year ago

Did not correct reported framebuffer depth or physical display size on Catalina (still reported as NaN-inch (0x0)).

I was able to verify the framebuffer depth on Ventura using betterdisplay (is reported as 24-bit here), but this didn't resolve the issue either. It did resolve the physical display size (12.6 in) but is reporting 2688 x 720 for the native resolution.

Qonfused commented 1 year ago

Noticed some additional props for overriding default resolution: https://www.tonymacx86.com/threads/wrong-native-resolution-after-catalina-update.292742/

Qonfused commented 1 year ago

Was already being used as part of BetterDisplay's generated overrides:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>DisplayIsTV</key>
    <false/>
    <key>DisplayPixelDimensions</key>
    <data>
    AAAHgAAAAgM=
    </data>
    <key>DisplayProductID</key>
    <integer>2175</integer>
    <key>DisplayProductName</key>
    <string>Screenpad Plus</string>
    <key>DisplayVendorID</key>
    <integer>2533</integer>
    <key>default-resolution</key>
    <data>
    AAAHgAAAAgMAAAA8
    </data>
    <key>scale-resolutions</key>
    <array>
        <data>
        AAAKgAAAAtE=
        </data>
        <data>
        AAAVAAAABaI=
        </data>
        <data>
        AAAVAAAABaIAAAABACAAAA==
        </data>
    </array>
    <key>target-default-ppmm</key>
    <real>10.069930100000001</real>
</dict>
</plist>
Qonfused commented 1 year ago

Additional resolutions are probably other scale resolutions in the same aspect ratio at higher resolutions (eg. 2x resolution), which is for enabling HiDPI. Can try disabling that to support only the native resolution with HiDPI off.

Interestingly it seems the 30-bit framebuffer depth is not necessarily tied to EDID; macOS appears to fall back onto this color depth for external monitors, but uses 24-bit for any internal retina displays. If it was detected as a TV, then overriding this has no effect. @UsedDiscord The video you linked allows you to force RGB mode to bypass this issue, but it only applicable if there is Television: Yes in system information or otherwise isn't using sRGB.

Another property is the IOGFlags property - will need to look into that also. Possible override values seem to be 0, 4, 1552, 14499, 19501, 40974, 40975, 40979, 40980, 40981, 65536, 196608, 262144, 262148.

Qonfused commented 1 year ago

I'll try to resolve everything I can this way, but if it doesn't resolve the issue then I can try changing the SMBIOS model + redoing busID patching.

Maleficent-Magik commented 1 year ago

Another property is the IOGFlags property - will need to look into that also. Possible override values seem to be 0, 4, 1552, 14499, 19501, 40974, 40975, 40979, 40980, 40981, 65536, 196608, 262144, 262148.

https://github.com/mafredri/macos-display-overrides/issues/2 - https://github.com/mafredri/macos-display-overrides

The same speech as you, (I didn't read it all, I put it temporarily here).

Maleficent-Magik commented 1 year ago

I'll try to resolve everything I can this way, but if it doesn't resolve the issue then I can try changing the SMBIOS model + redoing busID patching.

If we need to changing the SMBIOS Model, there are servals choose :

MacBookProX,X Processor Card Graphics ? Initial Support
MacBookPro15,1 Coffee Lake(H) UHD 630/Radeon Pro 555X (15") Mac-937A206F2EE63C01 10.13.6 (17G2112)
MacBookPro15,2 Coffee Lake(U) Iris Plus 655 (13") Mac-827FB448E656EC26 10.13.6 (17G2112)
MacBookPro15,3 Coffee Lake(H) UHD 630/Radeon Pro Vega 16 (15") Mac-1E7E29AD0135F9BC 10.14.1 (18B3094)
MacBookPro15,4 Coffee Lake(U) Iris Plus 645 (13") Mac-53FDB3D8DB8CA971 10.14.5 (18F2058)
MacBookPro16,1 Coffee Lake(H) UHD 630/Radeon Pro 5300 (16") Mac-E1008331FDC96864 10.15.1 (19B2093)
MacBookPro16,3 Coffee Lake(U) Iris Plus 645 (13") Mac-E7203C0F68AA0004 10.15.4 (19E2269)
MacBookPro16,4 Coffee Lake(H) UHD 630/Radeon Pro 5600M (16") Mac-A61BADE1FDAD7B05 10.15.1 (19B2093)
Model Proc Type
U, M Mobile (Mid tier)
H, QM, HQ Mobile (High End)

So we'll see...

Maleficent-Magik commented 1 year ago

I was able to verify the framebuffer depth on Ventura using betterdisplay (is reported as 24-bit here), but this didn't resolve the issue either. It did resolve the physical display size (12.6 in) but is reporting 2688 x 720 for the native resolution.

Same with BetterDisplay on Monterey, it's now 24bits ARGB8888 but no change, still NaN Inch (and still 1280*720 in résolution...but still garbled screen)

Qonfused commented 1 year ago

Btw should point out that changing the SMBIOS wouldn't be a fix but it would verify the framebuffer patch (displayport connector for screenpad is at 1 when it should be 2-6). Usually the busids for connectors change between SMBIOS models.

Maleficent-Magik commented 1 year ago

Here the same problem again, under an Acer Aspire V3 but like us, without CSM option... Tonymacx86.com Thread Aspire V3-371 Broadwell Iog Flag 0x3

Qonfused commented 1 year ago

That's a different problem, unfortunately.

Qonfused commented 1 year ago

Added display overrides folder w/ patch script in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/commit/91a8048680c636716c5dd9575866d6ae1c3e388c for future use.

rogerdcarvalho commented 1 year ago

I'd like to pitch in and see if I can help resolve this, got the same problem as you guys with a UX581GV, I7-9750H with 2 4K screens. I'll just summarise the thinking process I've been through to date, and see if this may trigger a hint that we can aim our investigation towards.

  1. It has been reported that other users could use the UX581 with the second screen and shiecldk's EFI (see here. Assuming this person was telling the truth, it means there must be a difference between my UX581 and theirs. The differences I could identify were: a. This person had a i9-10980hk whereas I have the I7-9750H. At first I thought all UX581s were gen 9, but apparently 10th gen UX581s were sold (see here). This could imply that something about the way the 10th gen UHD 630 connects to a 4k screenpad is different from my device, which is where I initially thought the solution could lie. b. I don't know which BIOS version that person had, but both myself and @danperks have this problem with the UX581, and both of us use a bios version newer than 303, which is what shiecldk quoted as having tested (@danperks had version 305, while I have version 309). Apparently it is possible to downgrade BIOSes on ASUS devices, but I can't find a download of BIOS version 303 anywhere. If anyone has this, it could be worthwhile to try and downgrade and eliminate that the BIOS version is related.

  2. Interestingly both the user on tonymacx86 and @danperks could run shiecldk's EFI without any big changes. I however could not run this EFI, I had to create a new EFI and copied their device properties to get my device working (with the garbled screen). Thus it makes me wonder what the difference is between @danperks device and mine, probably not related to the garbled screen issue but at least proves that BIOS updates can severely impact the functionality of the EFI

  3. Looking at the feedback @Qonfused gave to shiecldk when the garbled issue was first reported, it was stated that in Hackintool both connections were visible with platformid 3EA50009. The screenpad was detected on port 1. On my device, the screenpad is actually found on port 3, but I can never get both the normal screen and the screenpad to be detected by the same platform ID in Hackintool. This makes me wonder whether this is normal for the UX581, or whether there is something in my EFI that makes Hackintool discover connected devices differently. I find the normal screen under platformid 3EA50009, but the only platformid I can find the screenpad under is platformid 3E9B0007. Given the two screens are never detected together, this already makes me worry about how I'd ever patch the framebuffer to get both screens working at the same time with my current configuration: image image

  4. I tried all busIds 1-6 for HDMI (00080000), DP (00040000) and even eDP (02000000) in Device Properties frame buffer patching, but it didn't make any difference whatsoever. As long as my framebuffer-con3-alldata starts with 03, the screenpad will turn on with garbled white noise, it feels like whatever digits I enter past that are irrelevant. If it doesn't start with 03, it will stay off. However, when it is on, I do get the correct reported resolution of my screenpad (3840x1100) in MacOS Settings.

  5. So now I'm basically stuck. All I could think of is: a. The 10th gen intel UHD is connected to a 4k screenpad differently than on my 9th gen, either using a different port or something. But its odd that the UX481 also has 10th gen intel but still the same problem, so I'd guess this probably isn't related. b. Something in shiecldk's ACPI SSDTs is affecting how the screen responds to the frame buffer patch. But I can't figure out what SSDT that would be, none of them seem particularly related to the GPU. c. Something in ASUS BIOS updates broke compatibility. Interestingly they did mention patching something on the screenpad during version 305 ("Upgrade BIOS to improve the user experience of ScreenPad 2.0/Plus while system resume", see here). I wonder if there is any way to find someone with an older BIOS that has the same issue? Or perhaps find a detailed changelog of version 305?

@Qonfused What are your thoughts? Was this summary at all helpful? Which version of the BIOS do you have? Any way I can help move the investigation forward?

rogerdcarvalho commented 1 year ago

Actually scrap the BIOS idea, I assumed there was a universal BIOS version number for all ZenBook Pros, but the BIOS versions of the UX582 follows a completely different versioning approach and 303 is still the latest BIOS. On top of that, there are two UX581s, the UX581LV and UX581GV. Both have completely different BIOSes. And so it could very well be that the person on tonymacx86 has the UX581LV. So whatever the difference is between our machines, it probably isn't the BIOS version alone that is making the difference.

@danperks, which UX581 do you have?

Maleficent-Magik commented 1 year ago

Quickly, I did not read everything, for the UX481FAY, the latest BIOS is 302

Maleficent-Magik commented 1 year ago

By the way, thanks for your help in this buggy ScreenPad adventure xD, welcome to the underworld! @rogerdcarvalho

Qonfused commented 1 year ago

Unfortunately there is no version 303 for your machine; you can download existing BIOS versions directly using a download URL like https://dlcdnets.asus.com/pub/ASUS/nb/UX581GV/UX581GVAS303.zip?model=ux581gv; this is the URL the support page download links use.

Matching BIOS version numbers between UX481/UX581/UX582 models may share the same incremental changes. For context, the initial BIOS version for the UX581GV is 204 (latest is 309), and the initial BIOS version for the UX582LR is 203 (latest is 305).

For the UX481, there are UX481FA/UX481FL and UX481FAY/UX481FLY variants; the FAx and FLx models differ primarily by the inclusion of the dGPU. The UX481Fx variants' initial BIOS version was 206 (latest is 308), while UX481FxY variants' initial BIOS version was 203 (latest is 302).

The current BIOS version I'm using for my machine is version 302 for the UX481FLY BIOS (GOP reports version 9.0.192 and EC reports version F0021508.309), which are the latest firmware versions.

Comparing DSDTs between the UX481, UX581 and UX582 should reveal any functional differences here, though this also changes between BIOS version. You can also compare BIOS versions this way.

Qonfused commented 1 year ago

@rogerdcarvalho regarding no. 3, shiecldk encountered the same issue on his machine (see this post). He saw the primary display using 3E9B0000, and the screenpad plus using 3E9B0007. Note that platform-id 3EA50007 is for the Intel NUC, which doesn't have a connector for an internal display.

What does hackintool show when using 3EA50009 without any framebuffer patches?

Qonfused commented 1 year ago

Actually scrap the BIOS idea, I assumed there was a universal BIOS version number for all ZenBook Pros, but the BIOS versions of the UX582 follows a completely different versioning approach and 303 is still the latest BIOS. On top of that, there are two UX581s, the UX581LV and UX581GV. Both have completely different BIOSes. And so it could very well be that the person on tonymacx86 has the UX581LV. So whatever the difference is between our machines, it probably isn't the BIOS version alone that is making the difference.

There appears to only be one variant of the UX582 (UX582LV), so if the UX581LV is reported as working, then there may have been some resolution in the device's DSDT or EC controller firmware that we can use for the UX581GV.

@wern-apfel was able to get the screenpad plus working on a UX481FA model (unclear if FA or FAY variant), presumably using an EDID patch/display override/ACPI hotpatch. They have shared a fork of this repo's EFI here, but it only goes up to Nov 27 (a month before reporting any success). They've included two screenshots here and here on Catalina and Monterey, using the same 0x3E9B0000 device-id (and probably the same framebuffer patches). Unfortunately they've been unresponsive and haven't shared any progress since.

rogerdcarvalho commented 1 year ago

@rogerdcarvalho regarding no. 3, shiecldk encountered the same issue on his machine (see this post). He saw the primary display using 3E9B0000, and the screenpad plus using 3E9B0007. Note that platform-id 3EA50007 is for the Intel NUC, which doesn't have a connector for an internal display.

What does hackintool show when using 3EA50009 without any framebuffer patches?

Hey there! Without any Framebuffer patches it still shows the main screen attached, just not the screenpad:

image

Aaah I missed the status update of @wern-apfel, that is positive news though.... So the key is now to keep experimenting with EDID overrides? Is there anything that I can share to help out, need to see my DSDT?

Qonfused commented 1 year ago

So the key is now to keep experimenting with EDID overrides? Is there anything that I can share to help out, need to see my DSDT?

I'm not sure what the fix was but it would have maybe been some combination of EDID patching/display overrides/etc. I know he was looking into correcting EDID though this wasn't the only change made. I'm trying to stay away from patching Lilu+WhateverGreen if the solution can be done trivially.

You can share your DSDT here; it's more useful for comparing if I can get a DSDT dump from a UX581LV/UX582LV. Can also make more sense of the original repository as it shares more similar firmware for devices like thunderbolt.

I've also documented some of the ACPI patches from shiecldk's EFI in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/7. The original repository doesn't have any before/after commits to compare (before fixing the screenpad), but I can look into these again to be sure.

Qonfused commented 1 year ago

Regarding #7, the only related SSDTs I could find would be SSDT-IMEI or potentially SSDT-XSPI. That issue is closed as I was planning on transferring it to a new fork for the UX581/UX582.