[Kernel/FB] ScreenPad display static on FB initialization

[Qonfused]

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:

• [ ] Display output
• Pre-OS (OpenCore verbose)
  • [x] GOP (UEFI feature)
• iGPU Framebuffer
  • [x] Proper RGB screenspace
  • [x] QE/CI acceleration
• [ ] Display metadata (EDID)
  • [x] Device Name (Cosmetic)
  • [x] Device and Vendor IDs
  • [ ] Valid resolution data
    • [x] Native resolution
    • [x] Default resolution
    • [ ] Scaled resolutions
  • [ ] Valid clock/timings data
  • [ ] Physical size info (Cosmetic)
    • [ ] Panel dimensions
    • [ ] Correct default ppmm
• [x] PCH Sideband signals
  • [x] Display Hotplug
  • [x] Panel power and backlight
  • [x] GMBUS I2C GPIO

[Qonfused]

I refer to the DSDT, WMI device: WMB method. The Screenpad is controlled there, as well as the FN keys. FN key lock works, turn Screenpad on and off (for now brightness at 0 means off) brightness in 5 levels. On the UX434, the Screenpad can be turned off completely, meaning the port is disabled, which is what I'm looking for.

I'm a bit out of my depth here, but I couldn't find a WMB method in my device's DSDT dump unless you're referring to WMNB? It seems like an ACPI method that screenxpert would interact with on Windows; I can take a closer look there.

The EDID is wrong for both displays, the name is a data string instead of product name, that's what I changed and also the reason why it says unknown monitor.

Ah ok. Is it not EDID spec compliant or just incompatible with what macOS expects?

This still works, make the folder /Library/Displays/Contents/Resources/Overrides/DisplayVendorID-...

I figured so. I couldn't modify the overrides folder even with SIP disabled; seemed like user error but I couldn't tell why. It can also be done with a kext (which I think hackintool does for display patching iirc).

[danperks]

Has there been any look into how ScreenXpert functions on Windows? I can try and decompile and reverse engineer it a bit and see if I can find anything useful if it's not already been done?

[danperks]

Also @wern-apfel, in regards to disabling the bottom screen instead of the flickering, I'd preferably avoid editing the whole EFI and replacing it for yours, is it a hard task to disable it manually by editing my existing EFI and if not, any guidance on doing so would be greatly appreciated :)

[Qonfused]

Has there been any look into how ScreenXpert functions on Windows? I can try and decompile and reverse engineer it a bit and see if I can find anything useful if it's not already been done?

Possibly related is asus-wmi-screenpad repo.

For reference, this is the interface for the (wmi) hotkey driver it uses:

// https://github.com/Plippo/asus-wmi-screenpad/blob/master/asus-wmi.h#L50-L74
50    | struct asus_wmi_driver {
51    |     int         brightness;
52    |     int         panel_power;
53    |     int         wlan_ctrl_by_user;
54    | 
55    |     const char      *name;
56    |     struct module       *owner;
57    | 
58    |     const char      *event_guid;
59    | 
60    |     const struct key_entry  *keymap;
61    |     const char      *input_name;
62    |     const char      *input_phys;
63    |     struct quirk_entry  *quirks;
64    |     /* Returns new code, value, and autorelease values in arguments.
65    |      * Return ASUS_WMI_KEY_IGNORE in code if event should be ignored. */
66    |     void (*key_filter) (struct asus_wmi_driver *driver, int *code,
67    |                 unsigned int *value, bool *autorelease);
68    | 
69    |     int (*probe) (struct platform_device *device);
70    |     void (*detect_quirks) (struct asus_wmi_driver *driver);
71    | 
72    |     struct platform_driver  platform_driver;
73    |     struct platform_device *platform_device;
74    | };

In another thread, I also found mention of a WMNB method that controls backlight (refers to \_SB.ATKD.WMNB, which seems to be what wern-apfel was mentioning?): https://github.com/s-light/ASUS-ZenBook-Pro-Duo-UX581GV/issues/1#issuecomment-632839056

• Control backlight: echo '\_SB.ATKD.WMNB 0x0 0x53564544 b32000500xx000000' | sudo tee /proc/acpi/call (xx is a hex value from 00 to FF).
• Disable backlight: echo '\_SB.ATKD.WMNB 0x0 0x53564544 b3100050000000000' | sudo tee /proc/acpi/call

^^^ They're using the acpi_call linux kernel module to call this method, though assumedly an SSDT could also call the same method with these values to change backlight (and in your case disable backlight).

[wern-apfel]

I'm a bit out of my depth here, but I couldn't find a WMB method in my device's DSDT dump unless you're referring to WMNB? It seems like an ACPI method that screenxpert would interact with on Windows; I can take a closer look there.

It was a typo, I meant WMNB

Ah ok. Is it not EDID spec compliant or just incompatible with what macOS expects?

I think macOS is more restrictive, but that doesn't affect the functionality.

I figured so. I couldn't modify the overrides folder even with SIP disabled; seemed like user error but I couldn't tell why. It can also be done with a kext (which I think hackintool does for display patching iirc).

You can edit the DisplayProductID-xxxx while it is on the desktop and then copy it to that folder.

[wern-apfel]

Has there been any look into how ScreenXpert functions on Windows? I can try and decompile and reverse engineer it a bit and see if I can find anything useful if it's not already been done?

Not yet, I haven't really used Windows for a few years now.

Also @wern-apfel, in regards to disabling the bottom screen instead of the flickering, I'd preferably avoid editing the whole EFI and replacing it for yours, is it a hard task to disable it manually by editing my existing EFI and if not, any guidance on doing so would be greatly appreciated :)

Just copy my EFI to USB-Stick and try it out. Where the port is disabled (battery drain) and the FN key lock also works. If you just want to disable the Screenpad, I'll try to make a SSDT for it, but it actually only turns off the backlight. Do you use the EFI provided by Qonfused?

[wern-apfel]

Has there been any look into how ScreenXpert functions on Windows? I can try and decompile and reverse engineer it a bit and see if I can find anything useful if it's not already been done?

Possibly related is asus-wmi-screenpad repo.

For reference, this is the interface for the (wmi) hotkey driver it uses: In another thread, I also found mention of a WMNB method that controls backlight (refers to \_SB.ATKD.WMNB, which seems to be what wern-apfel was mentioning?): s-light/ASUS-ZenBook-Pro-Duo-UX581GV#1 (comment)

• Control backlight: echo '\_SB.ATKD.WMNB 0x0 0x53564544 b32000500xx000000' | sudo tee /proc/acpi/call (xx is a hex value from 00 to FF).
• Disable backlight: echo '\_SB.ATKD.WMNB 0x0 0x53564544 b3100050000000000' | sudo tee /proc/acpi/call

^^^ They're using the acpi_call linux kernel module to call this method, though assumedly an SSDT could also call the same method with these values to change backlight (and in your case disable backlight).

Linux has already a WMI driver where some FN key already work. My method (see SSDT-ATKD) writes to the EC register.

[wern-apfel]

Ok, so yesterday watching World Cup soccer and looking at the code at the same time didn't work, but today it did. But wait, not the Screenpad (still garbled), we can now only turn the port and brightness on and off. Not what we want, but a little progress. Looking at EDID now.

If anyone wants to try my EFI, copy the entire EFI to a FAT (not sure if NTFS or APFS will also works) formatted USB-stick, after the ASUS boot screen press ESC, if the USB-stick is not visible go to Setup, go to Save & Exit (left arrow) and select the stick then press Enter.

[Maleficent-Magik]

Quick question, but... in faculty, during a class, a girl came to ask me if she could charge her iPhone (I specify iPhone, very important...) on my Asus...

It was under Windows 10 and when she plugged it on the USB-C (important again this indication), my screen was duplicated on her phone (or the reverse, I do not know more ...).

I wonder something, the USB-C would also make screen transfer / screen duplicator?

If this is the case, under MacOS it happens too? or is it the same syndrome as the ScreenPad+?

[danperks]

Just copy my EFI to USB-Stick and try it out. Where the port is disabled (battery drain) and the FN key lock also works. If you just want to disable the Screenpad, I'll try to make a SSDT for it, but it actually only turns off the backlight. Do you use the EFI provided by Qonfused?

I'm actually on the OG EFI from ShieldCK which for me has most things working out the box, with the only thing being the bottom screen and brightness controls. Stuff like the HDMI has always worked for me no problem, so not wanting to update it until something changes. I (maybe wrongly) use MacOS as my main OS so I am somewhat reluctant to change the EFI in case I break something and, most likely, don't know how to fix it.

I am yet to much reading or learning on the in-depth stuff with Hackintosh's but this thread alone is teaching me loads!

Quick question, but... in faculty, during a class, a girl came to ask me if she could charge her iPhone (I specify iPhone, very important...) on my Asus... It was under Windows 10 and when she plugged it on the USB-C (important again this indication), my screen was duplicated on her phone (or the reverse, I do not know more ...).

This could possibly be a feature from the ScreenXpert app that has a load of phone linking built in, such as taking calls on your laptop and so on. Maybe not though, can't be sure, just a guess.

[wern-apfel]

I'm actually on the OG EFI from ShieldCK which for me has most things working out the box, with the only thing being the bottom screen and brightness controls. Stuff like the HDMI has always worked for me no problem, so not wanting to update it until something changes. I (maybe wrongly) use MacOS as my main OS so I am somewhat reluctant to change the EFI in case I break something and, most likely, don't know how to fix it.

I can give you a SSDT to disable the Screenpad, but you have to replace it in your EFI, which is more risky than just booting from a USB stick. Booting from a USB stick does not change your config, if you remove the stick everything works as before.

[Maleficent-Magik]

This could possibly be a feature from the ScreenXpert app that has a load of phone linking built in, such as taking calls on your laptop and so on. Maybe not though, can't be sure, just a guess.

Ah yep possible... indeed GlideX takes this feature. so yep, it doesn't affect macOS... I put my comment in Outdate ^^'

[Qonfused]

Linux has already a WMI driver where some FN key already work. My method (see SSDT-ATKD) writes to the EC register.

Which methods manipulate the display connector and backlight? I'm not entirely sure which _Qxx method maps to which fn-row key after F12. I have noticed that the F5+F6 keys don't update display backlight; the methods for them should be the same but may be different values. I'd need to reference your DSDT to be compare. The Esc, F1 & F2+F3, F7 keys work; F8 maps to the media functionality of F11? This is tested using your EFI config but may need more corroboration from others.

Ok, so yesterday watching World Cup soccer and looking at the code at the same time didn't work, but today it did. But wait, not the Screenpad (still garbled), we can now only turn the port and brightness on and off. Not what we want, but a little progress. Looking at EDID now.

As expected, this appears to work fine on the UX481FL as well; backlight is disabled by default (and the connector; no display attached to the framebuffer), and the backlight (00 -> FF) is toggleable.

In https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/pull/2#issuecomment-1212688936 I found an EDID log for both displays that shows that shows they're both missing their name and monitor ranges, but have valid size info, timings, and clock data (https://linux-hardware.org/?probe=d680085d25&log=edid). What's reported in macOS (w/ IORegistryExplorer) as the display's EDID data also matches. My main reference for both displays though has come from the linuxhw repo's EDID table, which has matching entries for the two displays: MFG	Model	Name	Res	Inch	Made	ID
Chimei Innolux	CMN14D5	N140HCE-EN2	1920x1080	13.9	2016	[3181E3522B42](<Digital/Chimei Innolux/CMN14D5/3181E3522B42>)
BOE	BOE087F	HF NV126B5M-N41	1920x515	12.6	2019	46E74341751E

It's also possible that the EDID for both displays may still need to be corrected with the edid-gen.sh script from the WEG guide.

If anyone wants to try my EFI, copy the entire EFI to a FAT (not sure if NTFS or APFS will also works) formatted USB-stick, after the ASUS boot screen press ESC, if the USB-stick is not visible go to Setup, go to Save & Exit (left arrow) and select the stick then press Enter.

I made a quick note in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/10#issuecomment-1325892257 about MATs support on the UX481FL model when upgrading to OC 0.8.6; this is the only necessary change to boot on the UX481FL model (assuming the latest BIOS/firmware version, if you encounter a kernel panic on invalid frame pointer). You may need to add -v to NVRAM > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > boot-args in your config.plist to see the kernel panic (or if the progress bar is stuck at zero).

@wern-apfel It's possible that the UX481FA model may be based on a newer firmware revision than the UX481FL. Would you be able to provide your DSDT for reference?

[wern-apfel]

Which methods manipulate the display connector and backlight? I'm not entirely sure which _Qxx method maps to which fn-row key after F12. I have noticed that the F5+F6 keys don't update display backlight; the methods for them should be the same but may be different values. I'd need to reference your DSDT to be compare. The Esc, F1 & F2+F3, F7 keys work; F8 maps to the media functionality of F11? This is tested using your EFI config but may need more corroboration from others.

This is from the UX434, but apart from the two keys above the Trackpad, the same. UX434_FN_Keys.zip

It's also possible that the EDID for both displays may still need to be corrected with the edid-gen.sh script from the WEG guide.

I have not tested that script, and do not think the name is important.

It's possible that the UX481FA model may be based on a newer firmware revision than the UX481FL. Would you be able to provide your DSDT for reference?

My firmware supports MAT.

UX481FA_dsdt.aml.zip

[Qonfused]

I'll double check with ACPIDebug just to be sure.

[wern-apfel]

I tried the script, it changes the color from 8 to 6 bit but still garbled screen. Have you tried the entire EFI? it is not enough to use only the SSDT-ATKD, or does it panic because MAT is not supported?

[Qonfused]

Yeah, this is with your EFI; it does panic since my firmware doesn't support MATs (may be another issue) but it's resolved by changing the values of these booter quirks: https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/10#issuecomment-1325892257.

[Qonfused]

My firmware supports MAT.

UX481FA_dsdt.aml.zip

OEM revision in the DSDT is the same (0x01072009); I'll have to explore that kernel panic a bit deeper, though it's not an issue atm.

As expected, the _Q0E and _Q0F methods are the same between the UX481FL/FA and UX582; same EC events triggered.

[wern-apfel]

I'm still watching World Cup, and I probably didn't answer all the questions, if so, ask again. I don't know if I mentioned that the brightness of the Screenpad is controlled with FN+a.

[Qonfused]

For clarity, what maps to the _Q76 method? Is this triggered by sleep/hybernate or by a physical key?

Also, does the value 0x00010082 or 0x00010001 disable the screenpad connector? I'm assuming 0x0001FF52 corresponds to the max for backlight.

[wern-apfel]

For clarity, what maps to the _Q76 method? Is this triggered by sleep/hybernate or by a physical key?

_Q76 mapped to FN+a: Screenpad backlight. _Q71 mapped to FN+spacebar: Battery Threshold. The battery stops charging at 80% if you press FN+space it will charge to 100%. Watch the LED (turns orange) or the Battery in the menubar.

Also, does the value 0x00010082 or 0x00010001 disable the screenpad connector? I'm assuming 0x0001FF52 corresponds to the max for backlight.

This was a quick fix, normally the code needs to read the current value first and then change it in relation to the result (I will change that if time allows) 0x0001FF52 is about 30% (I think is the default value) 0XFF is 100%

[Maleficent-Magik]

If the HDMI works, we can't change the ScreenPad from eDP / DP to HDMI?

On the WhatEverGreen wiki: "Implements the driver support for onboard LSPCON chips to enable DisplayPort to HDMI 2.0 output on some platforms with Intel IGPU." Git WEG

well, I'm just saying that... I'm not at all sure that it works and that it's functional...

[Maleficent-Magik]

Temporarily written here :

BiosVideo*	CSM video driver implementing graphics output protocol based on VESA and legacy BIOS interfaces. Used for UEFI firmware with fragile GOP support (e.g. low resolution). Requires ReconnectGraphicsOnConnect. Included in OpenDuet out of the box.

ReconnectGraphicsOnConnect Type: plist boolean Failsafe: false Description: Reconnect all graphics drivers during driver connection.

_On certain firmware, it may be desireable to use an alternative graphics driver, for example BiosVideo.efi, providing better _screen resolution options on legacy machines, or a driver supporting ForceResolution. This option attempts to disconnect allcurrently connected graphics drivers before connecting newly loaded drivers.

Note: This option requires ConnectDrivers to be enabled.

---

Until the new year, happy holidays to you all.

Be careful on the road. and be careful with the abuse :)

• @UsedDiscord

[Qonfused]

Tried disconnecting the primary display but didn't yield anything new.

Does make for an interesting visual:

https://user-images.githubusercontent.com/32466081/209572074-bf0f797c-574e-4105-8947-24a5509ea139.mp4

[Maleficent-Magik]

We can see that here it's not really an OpenCore problem... but rather a MacOS problem, so, is it WhatEverGreen? is it directly the MacOS graphics?

And about the Log? if you connect by VNC, can you connect it?

However, I think I can also withdraw my idea of BiosVideo.EFI which would be useless, would it not? (Check down)

Conversation btw Krazy-Killa and Obi Cobobi about BiosVideo.efi on Discord /r/Hackintosh

[Link Conv](https://discord.com/channels/186648463541272576/302485086060937219/1056708800515674212) >*Krazy-Killa — Today at 12:03 AM* BiosVideo AFAIK won't fix the scrambled screen after video pass over to macOS framebuffer. It's mainly used to help with faulty GOP implementations (eg. Older IVB or HSW based laptops with 1366x768 screens) >*Obi Cobobi — Today at 12:05 AM* IIRC that's what it was supposed to be for originally? This is a HSW setup CSM video driver implementing graphics output protocol based on VESA and legacy BIOS interfaces. Used for UEFI firmware with fragile GOP support (e.g. low resolution). Fragile GOP support - and it's based on the CSM implementation - so it's supposed to function in a similar way IIRC, but I had issues with it on my HP (which is 1366x768 and requires CSM to display properly) >*Krazy-Killa — Today at 12:07 AM* Yeah. I use BiosVideo.efi on my IVB laptop with a 1366x768 screen. Completely fixed the garbled screen during bootup (never had garbled screen after the framebuffer takes over), and was able to use native resolution unlike with CSM setting which locks to 1024x768 >*Obi Cobobi — Today at 12:09 AM* Not sure why my experience with it didn't yield success - but I recall having read that it was for garbled issues. I may have misinterpreted though >*Krazy-Killa — Today at 12:13 AM* Well with BiosVideo.efi it has to be paired with ReconnectGraphicsOnConnect or else it won't work as expected. But I've had two users try it with their HSW that has the garbled screen when the framebuffer takes control, and it didn't fix it. It seems to only fix garbled verbose, apple logo during the first stage of bootup before the iGPU driver is initialized in macOS. >*Obi Cobobi — Today at 12:14 AM* Good to know thanks for that! >*Krazy-Killa — Today at 12:14 AM* [Link Conv](https://discord.com/channels/186648463541272576/400050916411047937/922718414244552704)  My experimentation on the driver Only thing it breaks is the background with FileVault. It does not stick when the iGPU takes over completely. Basically reverts to black background with white apple logo >*Obi Cobobi — Today at 12:18 AM* So with the Haswell garble, really the only fix is still to enable CSM? >*Krazy-Killa — Today at 12:19 AM* I'm curious though.. When you boot, is verbose garbled as well or is it legible? >*Obi Cobobi — Today at 12:19 AM* It's perfectly legible It only garbles when the OS framebuffer takes over IIRC >*Krazy-Killa — Today at 12:20 AM* So it's when GOP releases control and allows the iGPU driver to take over. >*Obi Cobobi — Today at 12:20 AM* Not on that machine currently - but I can test later to be sure if you'd like >*Krazy-Killa — Today at 12:21 AM* I'm curious if its still garbled if you set Output->Resolution to 1024x768x32 but leave CSM disabled. My IVB, the alternative was to set mine to 1024x768 and it provided legible verbose.

also, how did you disable your screen in your video here?

Since I see that the BIOS is displayed directly on the ScreenPad, that said... we can well confirm that it works haha... it works well and is not dependent on Windows.

So for the moment, I am also a little dry in terms of solution immediately...

well, being French, I don't have the same vision of the thing in English... so if I am wrong, don't hesitate to correct me.

[Maleficent-Magik]

(next conv Krazy-Killa : )

[Qonfused]

We can see that here it's not really an OpenCore problem... but rather a MacOS problem, so, is it WhatEverGreen? is it directly the MacOS graphics?

The issue is present after the OS framebuffer (or iGPU driver) takes over. WhateverGreen handles patching the framebuffer (spoofing the UHD 620 to a 630), which also requires framebuffer patches to correct the port layout for the internal display, screenpad plus, and HDMI. I don't really know of a way of attaching the framebuffer (w/ acceleration) without using WhateverGreen, so it's hard to isolate blame there; EDID is a known problem though.

Interestingly, the UX482 (11th gen counterpart) has a functional screenpad plus w/o acceleration, though it's not clear whether it or the UX582 have similar EDID issues as the UX481 model. From what I recall the screenpad shows a black screen w/o acceleration (no framebuffer attached).

And about the Log? if you connect by VNC, can you connect it?

I neglected to check much further, but the display isn't recognized any differently in macOS.

However, I think I can also withdraw my idea of BiosVideo.EFI which would be useless, would it not? (Check down)

Yes, the display has proper UEFI GOP support (and will probably also work in Recovery). The screenshot in your second post shows the opposite problem where GOP is broken but is fine in macOS. This doesn't necessarily clear CSM being a potential issue if related to the Haswell 'garbled screen' issue after boot, but I do doubt CSM is a problem unless mirroring similar circumstances.

Unfortunately, the sync-width EDID patch suggested by the other user will also not work for the screenpad.

also, how did you disable your screen in your video here?

I physically disconnected the display cable. It's near the top-right of the motherboard labeled R4501 ('eDP LCD Connector' on page 31 in the schematic). In general, it's best to connect/disconnect the cable by the sides of the connector using a spudger since the cable itself can be fragile, but I wouldn't recommend people try this outside of a repair.

[wern-apfel]

Since no one was interested in my patches, I'm not sure if you guys are interested in my patches for a working screenpad. But I just want to say that the screenpad works on macOS.

[Maleficent-Magik]

Since no one was interested in my patches, I'm not sure if you guys are interested in my patches for a working screenpad. But I just want to say that the screenpad works on macOS.

Well, the last time I tested your Project on GitHub concerning the UX481, the ScreenPad+ was totally off... I couldn't find any way to turn it on... did you change anything in the meantime?

also we can see that it is not MacOS Monterey or Ventura? it's Catalina isn't it? It's maybe the possible problem without doubt? Please let me know if I made a mistake somewhere? because I'm a bit lost...

You say Patches, it's about WhatEverGreen? Or more specific?

I would take your patches with a little explanation of how you put them on? (by how you put them on, I mean how to inject them properly...)

[Qonfused]

Since no one was interested in my patches, I'm not sure if you guys are interested in my patches for a working screenpad. But I just want to say that the screenpad works on macOS.

My preference is to separate ACPI patches by functionality (e.g. w/ DISABLE-SCREENPAD.aml, etc). That way it is easier to disable any specific behavior in the case of regression or incompatibility, as well as diff with upstream for maintaining compatibility for UX581/UX582 models. Another good example is SSDT-PLUG not being needed past Monterey 12.3; separating ACPI patches w/ commonly used names makes it easier for end users to maintain.

OOB your config works fine; the backlight issue I mentioned before was caused by dGPU info still being present (still needed to be hidden from the OS with -wegnoegpu or the disable-gpu property), which was just a minor configuration issue for the dGPU variant. I've linked parts of your UX481FA SSDT to a few other issues (#6 #8 #18); your ASUSFN SSDT could be used as-is though I've ported some behavior from the linux driver into ASUSSMC (not merged into main quite yet).

Was the solution for fixing the screenpad framebuffer (w/ resolution/color data) just an EDID patch or did it involve any fixes w/ WhateverGreen (framebuffer), MSOS, etc?

[wern-apfel]

@UsedDiscord Sorry for the confusion, I didn't mean that the Screenpad works with the EFI I uploaded a few days ago. As you have already noticed, it was off. I thought no one had tested it because of the lack of feedback.

Right now I'm not sure what fixed the Screenpad, I've made a lot of changes so I'll have to remove one at a time to see what fixed it. I chose Catalina so I wouldn't have to deal with these snapshots.

For example, on my EFI, the microphones, trackpad GPIO pinning (I haven't tested the Screenpad touch), FN key lock, and maybe more all work, so you probably haven't really tested it. It is not the goal to test my EFI, but together we can improve the functionality of this machine.

[Qonfused]

@ UsedDiscord Sorry for the confusion, I didn't mean that the Screenpad works with the EFI I uploaded a few days ago. As you have already noticed, it was off. I thought no one had tested it because of the lack of feedback.

I thought I had mentioned that I tested it but realized I needed to look further into debugging the OS framebuffer. The main thing I noted was needing the atomic filestructure for ACPI patches, but I considered it's status working (for FN keys and screenpad connector toggling).

Right now I'm not sure what fixed the Screenpad, I've made a lot of changes so I'll have to remove one at a time to see what fixed it. I chose Catalina so I wouldn't have to deal with these snapshots.

I can build up from this repo's config as well to isolate the issue. My main interest is addressing the cause of the issue for solving this for the UX581 as well (for @danperks). Even if the screenpad works, if the cause is still invisible it's fixed but not exactly solved (in the case of any future regressions).

I'm not aware of any functional OS changes concerning the screenpad past 10.15.5 (where comet lake is stable), but it shouldn't be an issue. If something would break its unlikely it would be framebuffer related, though testing on Ventura would confirm it still works after graphics stack changes. I'd recommend rebooting a couple of times on Ventura before testing (this issue is present on real macs).

For example, on my EFI, the microphones, trackpad GPIO pinning (I haven't tested the Screenpad touch), FN key lock, and maybe more all work, so you probably haven't really tested it. It is not the goal to test my EFI, but together we can improve the functionality of this machine.

If you were only mapping peripherals (as to what coincided with fixing the screenpad) it could be related to the LPC bus (LPCB). The eSPI protocol is the newer counterpart, which is more common for display port controllers. You could try reverting or disabling the GPIO pinning for the trackpad or w/e other peripheral fixes address these busses.

(confirmed resolved with trackpad GPIO) Something to note is that if either display's touchscreen has intermittency issues after GPIO pinning the trackpad, it may be blocked by an upstream issue w/ VoodooI2C and VoodooI2CHID. It should work after login + wake, but if it otherwise has issues I'd note its status in #12 (I think I linked the voodoo issue there as well).

The main change I've made is adding support for the micro-sd reader in e14c7f9. The only change needed is adding a kext (it ports the linux driver for realtek sd readers). You'll also want to look in #12 as I've detailed a fix for multi-touch gestures for both displays (your screenpad may only have basic pointer support w/o multi-touch).

[Qonfused]

I'll remove Legacy / CSM from the roadmap as it's now unnecessary w/ working UEFI GOP (https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1365298998).

[Maleficent-Magik]

@UsedDiscord Sorry for the confusion, I didn't mean that the Screenpad works with the EFI I downloaded a few days ago. As you already noticed, it was turned off. I thought no one had tested it due to the lack of feedback.

haha, no, I did test it under Monterey as well ^^', I didn't give any feedback because I didn't find any "improvement" with the Qonfused EFI. So unless I was a moron...?

Could you still share your EFI with the repaired Screenpad as your picture shows? I don't intend to steal the project from you of course haha, but to be able to work in colobaration with @wern-apfel and @Qonfused

Make Qonfused EFI & wern-apfel EFI work...

Trying in quotes to merge them to make everything work...

For example, if your screen works @wern-apfel , we take the section there and we add it to the one of Qonfused to which the microphone works (from memory I had tested a train, and we heard the train, I must test), the SD card and all the other things._

You know what I mean? unless @Qonfused sees it as something else?

[Qonfused]

@wern-apfel You can create a new issue for tracking. If you know of a commit where the screenpad plus wasn't working, make sure to mention it there. I'll create a PR for bringing feature parity + isolating the screenpad framebuffer issue.

Edit: Created a PR with tracking. See https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/pull/19 PR.

[Maleficent-Magik]

I physically disconnected the display cable. It's near the top-right of the motherboard labeled R4501 ('eDP LCD Connector' on page 31 in the schematic). In general, it's best to connect/disconnect the cable by the sides of the connector using a spudger since the cable itself can be fragile, but I wouldn't recommend people try this outside of a repair.

oh okay, thanks for this information 😄 i just know how, but i don't touch my pc, it's my pc for my school... so... I can switch Windows and macOS, but not in hardware ... it's too risky

[Qonfused]

@wern-apfel You'll need to commit your local changes for me to continue #19 PR. There isn't any history after Nov 27.

[Qonfused]

@wern-apfel Was the color data (framebuffer depth) fixed through an EDID patch or was it still broken w/ something like 30-bit color before the screenpad was fixed?

[wern-apfel]

For example, if your screen works @wern-apfel , we take the section there and we add it to the one of Qonfused to which the microphone works (from memory I had tested a train, and we heard the train, I must test), the SD card and all the other things._

On my EFI, the microphone and SD card reader have been working for months on my UX434, it has always worked on the UX481. This REPO says that the microphone does not work. So you think we should change the engine, transmission, brakes, wheel on an old car just because you think it's nicer?

@wern-apfel Was the color data (framebuffer depth) fixed through an EDID patch or was it still broken w/ something like 30-bit color before the screenpad was fixed?

I did not change anything in the color depth, it was always 8-bit per channel, 24-bit as indicated by the System-Profiler. As on the picture.

Monterey also works as expected, but there are still some issues.

[Qonfused]

On my EFI, the microphone and SD card reader have been working for months on my UX434, it has always worked on the UX481. This REPO says that the microphone does not work. So you think we should change the engine, transmission, brakes, wheel on an old car just because you think it's nicer?

@UsedDiscord I've neglected a lot of simple ACPI housekeeping to focus on the framebuffer issue (though I've addressed some of this already in #19 PR). The only change you'd need to make to wern-apfel's config is adding SSDT-GPU-DISABLE.aml w/ the disable-gpu in igpu device props or the -wegnoegpu boot arg.

I did not change anything in the color depth, it was always 8-bit per channel, 24-bit as indicated by the System-Profiler. As on the picture.

Interesting. Color data may be a separate issue.

Monterey also works as expected, but there are still some issues.

What sort of issues are you experiencing there? Also, is this Monterey <12.3?

[Maleficent-Magik]

On my EFI, the microphone and SD card reader have been working for months on my UX434, it has always worked on the UX481. This REPO says that the microphone does not work. So you think we should change the engine, transmission, brakes, wheel on an old car just because you think it's nicer? @wern-apfel

Hey, I confirm that in the repo of @Qonfused, the micro works for me (well, from memory, I'll test it in a few hours if I think about it, for me it works.)

Regarding the Micro-SD reader, I could not test it because I blocked it... Yeah genius... I have a Micro-SD card that got destroyed in there like a ball and chain.

Concerning your sentence that caught my attention, not in the fact that it's beautiful, but more because it's recent, more solid to change the engine, the transmission, the wheels and companies while keeping the base which is stable...

In what I mean here, it's that by taking your base patch for the Framebuffer, it would already fix a problem for many people... except if your patch is in the .aml?

If you have problems as you say with Monterey, don't hesitate to let us know, we can potentially help in return

Wishing you a pleasant reading, and a good understanding :)

If ever it's not clear, don't hesitate to tell me, I'm French, so the English translation is a bit complicated sometimes haha

[Qonfused]

Concerning your sentence that caught my attention, not in the fact that it's beautiful, but more because it's recent, more solid to change the engine, the transmission, the wheels and companies while keeping the base which is stable...

Ironically, the analogy with the car describes most code reviews lol. This is exactly what I'm doing in #19 PR for the purposes of documentation, with the expectation of bringing this repo to parity. There really isn't much change from that to warrant the comparison though.

In what I mean here, it's that by taking your base patch for the Framebuffer, it would already fix a problem for many people... except if your patch is in the .aml?

Sort of; presumably it was fixed by another underlying issue. The ACPI section for this repo has had as minimal as possible changes from upstream (with the exception of thunderbolt and some outdated in #7). As I've mentioned before, any fixes to LPCB/SBUS/etc that may have also fixed the screenpad would need to be compared to figure out the root cause of this behavior.

I'll need to create a PR for upstream incorporating some miscellaneous changes (remove unneeded/outdated ACPI patches, updating kexts + opencore). This will help clarify needed changes for differences in hardware between models, and not in dependencies, etc.

[Qonfused]

@ wern-apfel You'll need to commit your local changes for me to continue #19 PR. There isn't any history after Nov 27.

@wern-apfel Could you update me on this when you get the chance? It's not time critical though there's a lot of work I need to do that's waiting on this.

@danperks I'll update you when I bring the UX582 repo up to speed. Were there any changes needed to get your UX581 model working with that repo? You can compare your config.plist with FileMerge (search for in spotlight, it comes bundled with XCode).

[Maleficent-Magik]

it's very ironic yes haha...

Good luck to all of you for this project, and let's hope we can finish it by 2023 (Within the year, not from the beginning lol)! haha Thanks again to all of you for participating in this project and for not letting it fall through :')

[wern-apfel]

On my EFI, the microphone and SD card reader have been working for months on my UX434, it has always worked on the UX481. This REPO says that the microphone does not work. So you think we should change the engine, transmission, brakes, wheel on an old car just because you think it's nicer? @wern-apfel

Hey, I confirm that in the repo of @Qonfused, the micro works for me (well, from memory, I'll test it in a few hours if I think about it, for me it works.)

Regarding the Micro-SD reader, I could not test it because I blocked it... Yeah genius... I have a Micro-SD card that got destroyed in there like a ball and chain.

Concerning your sentence that caught my attention, not in the fact that it's beautiful, but more because it's recent, more solid to change the engine, the transmission, the wheels and companies while keeping the base which is stable...

In what I mean here, it's that by taking your base patch for the Framebuffer, it would already fix a problem for many people... except if your patch is in the .aml?

If you have problems as you say with Monterey, don't hesitate to let us know, we can potentially help in return

Wishing you a pleasant reading, and a good understanding :)

If ever it's not clear, don't hesitate to tell me, I'm French, so the English translation is a bit complicated sometimes haha

That's another confirmation that I'm not going to get any help from here. So, good luck with your stable base. And sorry for bothering you.

[Maleficent-Magik]

You don't answered to @Qonfused ...

Monterey also works as expected, but there are still some issues.

What sort of issues are you experiencing there? Also, is this Monterey <12.3?

As well i'have reply :

If you have problems as you say with Monterey, don't hesitate to let us know, we can potentially help in return

I have say don't hesitate to let us know, where I have fault ? You didn't say your issues...

So say your issues with Monterey @wern-apfel and we see for helping you.

[Qonfused]

That's another confirmation that I'm not going to get any help from here. So, good luck with your stable base. And sorry for bothering you.

@wern-apfel What's the issue here? From what I can understand this sounds like standard git-flow. This repository is a fork of a different project, so configuration changes need to be considered for upstream as well, which is the project base. I've addressed this before in https://github.com/Qonfused/ASUS-ZenBook-Duo-14-UX481-Hackintosh/issues/4#issuecomment-1365869534.

Nobody has done anything here besides offer help and offer support, but there isn't anything more we can do if you're unable to describe your issue. I have offered to look into the exact cause of the screenpad framebuffer issue as well as addressing a list of changes in #19's tasks that would be greatly beneficial for maintaining compatibility for your config for future OpenCore versions.

I can continue with #19 PR if you want to incorporate any further changes from here in the future, though it'll be limited to tracking changes as of your Nov 27 commit. You can check out the project roadmap for planned fixes like fan control and input for the stylus.

[Qonfused]

@wern-apfel Do you recall any changes you've made since your last public commit? What issue are you facing now?

Let me know if you still wish to collaborate, otherwise I'll work on merging #19 with current standing changes. There will be work needed for you to include any further changes to this repository if you don't wish to collaborate, though if that's the case then moving forward I won't be able to provide support.

[Maleficent-Magik]

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...

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

[wern-apfel]

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.

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.