[Guide] ASUS ZenBook Pro Duo 15 OLED UX582 OpenCore

[gvkt]

@shiecldk, as I posted in this thread

VoodooI2C Help and Support

Hello everyone. I ask for help starting Trackpad. I tried to do different SSDT-GPIOs, but nothing works. My device is Scope (_SB.PCI0.I2C0) Device (TPD0) APIC PIN 0x28 (IOREG ) What to do next ? Should I use: - SSDT-GPIO? - SSDT-XOSI? I do not understand how to make the desired SSDT. Thank...

www.tonymacx86.com

the problem in trying to modify VoodooI2CHID is that the same changes apply to the main screen (touch screen). So getting the screenpad to work as mouse emulation is possible but that destroys the multi-touch gestures on the main screen which works OOB for me. There doesn't appear to be a way to designate the changes to a particular device only. Both the main screen and the screenpad appear as two similar touch screen devices to Voodoo and the same driver hierarchy loads.

So, it is a choice between perfect touch screen with multi-finger gestures that is working well and a dead screenpad or the screenpad and touchscreen both working as mouse emulations (so no multi-finger gestures on main screen which is kind of useless).

I assume this applies in your dual screens as well. But your trackpad is not a screenpad device, so perhaps changes can be made that apply only to the trackpad.

I have got several things working now including Monterey except for the trackpad and sleep wake issue (black screen on wake). Bluetooth works fine on Catalina but pretty bad on Big Sur and Monterey. Battery usage is high even after CPUFriend tweaking. USB dongles that worked OOB don't seem to work on Big Sur and Monterey. This came with a WD SN730 so didn't have to change the SSD either.

 

[shiecldk]

@gvkt

In my case, I don't need to change any settings in the plist file in VoodooI2CHID.kext. However, the screenpad works only as a cursor (without multitouch; even without two finger scrolling); main screen multitouch works well; trackpad multitouch works well although the trackpad would stop responding sometime due to VoodooI2C bugs (no one has fixed it yet, but sleep and wake get it work again). Someone really need to look into the VoodooI2C code; it hasn't been well-maintained for a while. (I couldn't do it anymore since no one is funding/donating me... and I have to spare my time for my work and grad school prep.)

For macOS Monterey, I assume you might be able to adopt my OC files to your laptop. I think I have to update Lilu.kext or some other kexts to get my previous OC EFI files work on macOS Monoterey. For WiFi USB dongle, you would have to use the version for Big Sur/Monterey. (chris1111/Wireless-USB-Big-Sur-Adapter on GitHub.) It works well with my DWA-181 in both Big Sur and Monterey.

As for battery, I also found the battery life is not ideal on my laptop. Currently to be around 2.5 hours with light use. I think it might still be necessary to patch the battery with SSDT/DSDT method. Rehabman has a guide in here although he is no longer active (won't be anymore):

[Guide] How to patch DSDT for working battery status

Background Because the battery hardware in PCs is not compatible with Apple SMbus hardware, we use ACPI to access battery state when running OS X on laptops. Generally I recommend you use ACPIBatteryManager.kext, available here: https://github.com/RehabMan/OS-X-ACPI-Battery-Driver Later...

www.tonymacx86.com

Although kext and SSDT/DSDT is not necessary to get the battery status of my UX582 work, I'm still temporarily using ECEnabler.kext. It might be helpful to fix that. Also, NVMeFix.kext is necessary to get NVMe power manage work on hackintosh. I heard it's usually around 30 mins of difference in battery life w/wo NVMeFix.kext.

 

[shiecldk]

Thanks for that info. I have managed to boot into the install screen so far but no mouse (from trackpad or touch screen) . Need to create patched DSDTs or use a USB mouse for now with a hub to the single available USB-A port. The installer puts up a helpful diagram about turning on a mouse power switch before the language selection screen!

Have a question about setting the hidden BIOS settings with mod_grub. How did you find the names and offsets? Seems like some of them are the same on my laptop as what you have listed but not all. Disabling boot lock for example has unintended consequences (like disabling USB ports!). So my offsets might be different.

I tried following the instructions elsewhere using UEFITool and ifr extractor to get the offsets for the BIOS for my laptop. But after downloading the latest bios image from ASUS with which I was able to update the laptop successfully, the above tools aren't working as they are supposed to on that image. Don't want to hijack this thread for debugging this, will post in separate thread.

But interested in knowing if that is how you got the names and offsets for your PC BIOS. A line or two in your guide on how you got that information might be useful for others if they run into problems using the offsets you have given even for the same laptop in a future or variant firmware. Just a suggestion.

I also found out changing the BIOS settings with modGRUBShell.efi would disable my USB1.0/USB2.0 external/internal ports sometimes. (USB-A port, webcam, and bluetooth would stop functioning.) I am suspecting it might be ASUS's fault or there is something needed to be fixed in the newest modGRUBShell.efi because I am very sure I got the variables and commands right.

I basically extracted Setup.bin from my BIOS with UEFITools, and then I dumped the Setup.txt from Setup.bin using ifr extractor, and then I search for the BIOS setting I want to change. One thing to be noted (at least currently) is that if there are some settings that you can change in BIOS menu, I would just change it there instead of using modGRUBShell.efi (such as SecureBoot, Fast Boot, and SATA Mode Selection); otherwise, it could most likely mess up your BIOS setting. After I make changes to these settings, I then tweak the rest of the BIOS settings with modGRUBShell.efi. It might take some tries of what saving sequence you should use to save the BIOS settings with modGRUBShell.efi without messing up the USB port. And if you mess up the USB port, you can just reload the default settings in BIOS menu, save it, reboot, and tweak again. (I couldn't find a better way with what ASUS's BIOS offer for now.) I would have to update the guide for this. If you find a better way dealing with this, please let me know.

However, I updated the OC config.plist, so you don't really need to change anything in BIOS except for SecureBoot, Fast Boot, and SATA Mode Selection from the BIOS menu for it to boot. (At least the DVMT Pre-Allocated is 64M on UX582; not sure about what it is on your model tho.)

 

[gvkt]

Looks like ASUS has changed to a proprietary format for their firmware like HP. ifrextractor no longer useful on my laptop's BIOS image. It is able to parse the tree but the sections have all changed and so exporting it and extracting text version is no longer possible. Have to see if there are some updated forks. Will post if I find something that works.

Some of these BIOS restrictions may be related to Windows 11 lock-down requirements.

I have got my laptop to reasonably work with both Monterey and Big Sur but no trackpad yet (there might be a VoodooI2c bug in my case) and can go to sleep but cannot wake up without a black screen.

BTW, in your use of the three variants of the airport wireless driver for three different macos versions, I would recommend using the min and max kernel parameters in the opencore config.plist to have only the right one load rather than have all the three be tried with two failing at boot. Just my small incremental contribution to your effort.

My laptop allows 64MB DVMT in BIOS. With framebuffer patching, I had to designate the iGPU with 2GB vram to allow 4k and HiDPI selection to FHD.

 

[shiecldk]

@gvkt
I use FPTw64.exe to extract the BIOS instead of using the BIOS downloaded from ASUS. Usually, the BIOS you download from OEM website is not the entire BIOS; it is usually part of the BIOS for the update, which might be the problem of why you couldn't extract the Setup module.

If you can't extract the BIOS with FPTw, it might have something to do with the BIOS lock. You can try to disable BIOS lock with "setup_var_cv PchSetup 0x17 0x17 0x0". (if that bios option is the same as my UX582.)

The min and max kernel parameters are already implemented in my OC config.plist. Only the right version of AirportItlwm.kext would be loaded at boot.

For the black screen wake problem, I'm guessing it might be something to do with your boot-arg and other parameters in device-properties section in OpenCore. Try to see if you could solve it with the same/similar settings from my latest OC files. If you still cannot get the wake work, it could be just bad luck... I wasn't able to get OLED black screen at wake solved for my UX582 either (and was never hoping to solve it after read other people's experience with OLED in hackintosh) but it was solved suddenly after I changed some settings with the iGPU. I was surprised wake works without a problem for this laptop because I heard OLED usually have black screen wake problem unsolved in macOS at least with Dell, Gigabyte, HP, and most Razer laptops. (Razer 17" OLED works ok tho) If you can, try to check what's the vendor of the main screen. If it's the same vender and model as mine, I assume it would most likely be solvable. Otherwise, it's probably gonna black screen every time it wakes unless Apple use OLED (which doesn't seem ever gonna happened) or someone writes a kext for OLED or find a way to wake the screen through ACPI call in macOS. (like how Linux people get it works, maybe check s-light/ASUS-ZenBook-Pro-Duo-UX581GV in GitHub if you know how to port the ACPI call to macOS; the author of hieplpvip/AsusSMC in GitHub seems to know how to do that to get ASUS FN keys work.)

 

[gvkt]

@shiecldk

Some progress...

1. As usually happens with Hackintosh experiments the sleep/wake is working perfectly now and I have no idea which of the many changes fixed it.

2. I am able to get the Screenpad working as trackpad with GPIO interrupt (01b worked in my case) rather than polling. But has the same issue as you have faced in not having multi-touch.

I may have found the reason and it may be fixable. A couple of things:

The current architecture of VoodooI2C where the specific driver for a device is selected based on some priority score is not ideal for multi-I2C-hid input devices like our laptops. In my case, the screen should get the Multi-touch screen device driver (which happens OOB) and the screenpad the Precision Trackpad driver (which doesn't happen OOB because the Multi-touch screen device driver attaches to it like for the main screen). So the screenpad does not respond at all. Giving high priority to the PTP driver fixes this but the main screen no longer gets the Multi-touch screen driver then and so loses much of its functionality. There is a need to more precisely control which driver in the VoodooI2CHID kext is attached to what device. I was able to do this with some help on the Voodoo GIT site

IOPropertyMatch does not work correctly in VoodooI2CHID · Issue #485 · VoodooI2C/VoodooI2C

The IOKitPersonalities section in the kext has multiple Event Driver personalities. Each of them, in theory, support a IOPropertyMatch property to specify a property and a value that should match a...

github.com

Now the issue narrows to the PTP driver not being able to see the screenpad as a precision trackpad to allow multi-touch.

The problem in my case is that the screenpad (a Goodix GDX1515) can work in two modes - a legacy mouse mode and a PTP mode. On power up the default is the legacy mouse mode. This is what we are seeing. To get the multi-touch the HID initialization needs to send a I2C command that will switch the mode. This is likely true for you as well even if it is not a Goodix device. In addition, for the Goodix devices the latter command must be sent with sufficient delay from the initial I2C probe power on for it to respond to the command. Linux drivers fixed this.

I described what I found and what needs to happen here

Dual-screen devices with integrated trackpad and screen do not support multi-finger gestures（GDX1515） · Issue #474 · VoodooI2C/VoodooI2C

Describe the bug Dual-screen devices with integrated trackpad and screen do not support multi-finger gestures, like asus zenbook series's screenpad technology.In fact, it is a combination of a touc...

github.com

I am operating here with barely enough knowledge of these things so the above might be a bit off.

I am not sure if the Voodoo PTP code sends that command to make the screenpad switch to PTP mode or if it does whether it sends it without the required delay and so is dropped without a switch to PTP mode.

Not sure if the Voodoo developers are responsive to these issues, we will see. I will take a look at the Voodoo source code to see if I can first understand it and second if I can do some experiments with the above in mind. Might take a while.

I discovered another problem. While my USB-C port works fine with individual USB-C devices (have done the USB mapping), a hub or even a USB-C to USB-A adapter will not work on that port. Have no idea how to fix this. They work fine running Windows on the laptop. May have something to do with power provided through that port.

 

[gvkt]

Have got the keyboard light and levels controlled by Fn key working following your code.

The screen brightness is still software based with Lunar (the gamma adjustment based brightness as it does works reasonably well at different levels without affecting colors). But use of the Fn keys is not working as it should (this may be a bug in the latest version of Lunar I updated to). The keys change the brightness level and I can see the Lunar slider move as well but the Lunar brightness control does not follow the slider moved via the Fn keys. It remains where it is until I touch the slider and then it jumps to that setting. Not sure if this is a bug or a configuration issue with Lunar.

 

[shiecldk]

@gvkt Great finding for the VoodooI2C. I'm checking your posts now.

I have similar issue with my USB-A port (only USB3.0 device can be connected) but USB-C ports work fine with any device. I'm still fixing this issue.

For the Lunar.app issue, you have to change the brightness adjustment method in Lunar to software-base instead of hardware-base.
1. Check with Lunar.app dev, or
2. Read the document on their website.

I'll have to update the guide for this also. Let me know if you still cannot figure it out after checking the two things mentioned above.

 

[gvkt]

It is set to "software gamma".

If I use the brightness up and down Fn keys the brightness level OSD changes in number of bars and the lunar slidebar above moves accordingly. But lunar's gamma control doesn't kick in to affect the screen for the new settings unless I then click/touch the slider on the lunar interface when the screen "brightness" then jumps to the new value set with the Fn keys. I don't think this was happening in the previous version of Lunar. Might be a regression error in the new update that came out recently.

Unless I am missing something.

 

[shiecldk]

I agree it might most likely be Lunar's issue. I haven't updated Lunar for a while. Maybe open an GitHub issue there?