Contribute
Register

[Guide] ASUS ZenBook Pro Duo 15 OLED UX582 OpenCore

Joined
May 25, 2021
Messages
5
Motherboard
ZenBook UX582
CPU
i7-10870H
Graphics
UHD 630 + RTX 3070
Can i ask a question?

Great work have been done on touchscreen functionality!
But after touching screen on inactive display it does't get focus, like on Windows OS, but starts to controll pointer on active display.
Is it feature, or such behavior cant be changed for now?
 
Joined
Sep 24, 2012
Messages
178
Motherboard
ASUS ZenBook Pro Duo 15 UX582
CPU
i9-10980HK
Graphics
UHD 630 + RTX 3070
Unfortunately, it does't work on Monterey 12.1:(

I solve it by remapping USB ports from scratch.
I try new (for me) method using USBToolBox utility from GitHub, and it works perfect.
I done it using natively booted Windows 10. Just use manual from repo.
It seems to be working fine with my Logitech G700S dongle and D-Link DWA-181 AC-1300 dongle. Have you tried reseting the NVRAM on OpenCore login screen? (You'll also need to add the OpenCore boot option back in BIOS after the NVRAM reset.) Could you upload your new USB kext?
 
Last edited:
Joined
Sep 24, 2012
Messages
178
Motherboard
ASUS ZenBook Pro Duo 15 UX582
CPU
i9-10980HK
Graphics
UHD 630 + RTX 3070
Can i ask a question?

Great work have been done on touchscreen functionality!
But after touching screen on inactive display it does't get focus, like on Windows OS, but starts to controll pointer on active display.
Is it feature, or such behavior cant be changed for now?
Yes, you're welcome to discuss here. We need more people to fix this laptop.

Unfortunately, that's a know issue with VoodooI2C. If you know how to code with the kext, please help contribute. It's mentioned in VoodooI2C Github issue Duel monitor #96. @gvkt or @sqlsec should have more experiences than I on how to solve this but they use their screenpad as trackpad. You can also try to change your screenpad to trackpad in VoodooI2CHID.kext. I actually duplicated two kexts, VoodooI2CHID-AsTouchscreen.kext and VoodooI2CHID-AsTrackpad.kext, and was going to active them in the future release. Basically, you would have to tweak with the IOKitPersonalities>VoodooI2CHIDDevice Precision Touchpad HID Event Driver and IOKitPersonalities>VoodooI2CHIDDevice Touchscreen HID Event Driver in the info.plist. I haven't finished tweaking the device-id and vendor-id.

Another issue is the trackpad being stop functioning sometimes mostly due to it is still in Polling mode; we need to change it to GPIO mode instead. Maybe also check these Github issues:
Almost silent failure mode of GPIO pinning resulting in polling while IORegistry suggests success #487
Suggestion for edits to the GPIO pinning document to prevent confusion #486

However, it could also be caused by Github issue ELAN1200 stops working after a period of use #321; jjsmith92 on Github claimed to have this issue solved by comparing the Linux driver but he never push his code to VoodooI2C repo.

For now, in any case, if you want to reactive the trackpad without a reboot, you can put your UX582 in sleep and wake it up to reload the VoodooI2C. I simply close the lid for 30 sec and reopen it.
 
Last edited:
Joined
Mar 8, 2015
Messages
69
Motherboard
MSI Z370m Mortar; ASUS Zenbook Pro UX535LI
CPU
i5-9600k; i7-10750H
Graphics
UHD 630
Mac
  1. iMac
  2. MacBook Pro
There has been sporadic reports in the Linux world of trackpads stopping working if a 5 finger or a palm touch happens on the trackpad (that might trigger a multi-finger report). Voodoo code is derived from Linux drivers. Just pointing a possibility. Haven’t had any such problems with my Zenbook Pro but because of the brain-dead position of the trackpad in the center of laptop rather than center of keyboard, I have to type with palm well clear of the trackpad all the time.
 
Joined
Mar 8, 2015
Messages
69
Motherboard
MSI Z370m Mortar; ASUS Zenbook Pro UX535LI
CPU
i5-9600k; i7-10750H
Graphics
UHD 630
Mac
  1. iMac
  2. MacBook Pro
Can i ask a question?

Great work have been done on touchscreen functionality!
But after touching screen on inactive display it does't get focus, like on Windows OS, but starts to controll pointer on active display.
Is it feature, or such behavior cant be changed for now?
This has to do with the way Voodoo code is architected which predates multiple touch display devices.

Touch drivers can work in two different modes -

Touch screen mode: The cursor position is absolute. In other words, the cursor moves to where the finger touches and the movement is one-one with the touch on the screen. Typically, the display and touch sensor is the same device.

Trackpad mode: The cursor position is relative. It stays where it is regardless of where you touch the trackpad and moves corresponding to the relative movements of touch (suitably scaled). Typical use of a touch only trackpad controlling the cursor on a screen.

Voodoo can only boot with one of the above modes attached to any device while booted and not switch. This works fine for the typical use of a touch screen and a trackpad on a laptop.

When you get to multi-display touch devices like the Zenbook, this architecture has a limitation. What is needed is that when the cursor is on one display, touch on the other display can be used as a trackpad controlling the cursor movement on the other screen or it can bring focus to the touched display and act as a touch screen for that display. In Windows, drivers take care of this switch in functionality being aware of this switch between multiple displays for active status.

Voodoo (and I suspect Linux drivers) don’t address this use case.

All you can do with Voodoo is force any such device into a pure trackpad mode or a pure touch screen mode at bootup with no concept of active screen change. You will need to move the cursor and flow into the other screen for it to respond in absolute mode on that screen.

Voodoo can rearchitected to address this but it is significant work and it doesn’t look like there is appetite for that much work in the current maintainers.
 
Joined
Mar 8, 2015
Messages
69
Motherboard
MSI Z370m Mortar; ASUS Zenbook Pro UX535LI
CPU
i5-9600k; i7-10750H
Graphics
UHD 630
Mac
  1. iMac
  2. MacBook Pro
What is the status of Monterey compatibility relative to Big Sur for this machine? Any diffs positive or negative?

I have kept my UX535 in Big Sur because of bluetooth issues with a dongle on Monterey. Don’t know if this is still the case.
 
Joined
Mar 8, 2015
Messages
69
Motherboard
MSI Z370m Mortar; ASUS Zenbook Pro UX535LI
CPU
i5-9600k; i7-10750H
Graphics
UHD 630
Mac
  1. iMac
  2. MacBook Pro
I have also been looking at the insane battery usage that appears to be common with these Zenbook laptops with discrete GPU chips that aren’t used while on MacOS.

I am coming to the conclusion that it has a lot to do with the inefficient use of integrated graphics on the chip thermally but also in CPU demands. It is possible that these machines with discrete graphics chips which they rely on didn’t do much to optimize the integrated graphics usage.

This is particularly noticeable when I use VMWare Fusion to run VMs on the machine. Even when the VMs are idle, it runs very hot with fans blowing all the time and battery life is even poorer. The CPU load goes up a little but not enough to explain it. The temperature shoots up about 20 degrees even with fans blowing. Fusion is doing a lot of graphics refresh for its virtual screens even when the VMs are idle and the temps may be coming from the iGPU part of the chips combined with not letting the CPU get to lower power states when the iGPU is in heavy use. The 4k screen may exacerbate this problem.

It does not look like any power management tweak is going to solve this problem. I have verified that the discrete GPU is indeed switched off. In fact, you can feel the temperature difference between the CPU side and the dGPU side in the laptop base, all the temperature rise being on the CPU side.

Dont have this problem in Windows or Linux which can use the dGPU. I suppose one can test this conjecture turning off the dGPU completely if possible on Windows and checking if the same battery life problem happens.
 
Joined
Sep 24, 2012
Messages
178
Motherboard
ASUS ZenBook Pro Duo 15 UX582
CPU
i9-10980HK
Graphics
UHD 630 + RTX 3070
@gvkt and @Ingener001, speaking of the battery life, there is one key component we forgot to work on - the brightness control of both of the dual monitors. Currently, the brightness is max out in macOS. We use software to "dim" the dual monitors; however, at least for the ScreenPad being a LCD panel, it is always at the maximum backlight no matter how dim we set it with the software workaround. While for OLED, the situation could be different based on the design of the OLED panel, software brightness implementation could reduce its power consumption. In Linux, acpi_call is used (at least for UX582 and UX581) to adjust the brightness of the ScreenPad in hardware level. The details are in https://www.tonymacx86.com/threads/...o-15-oled-ux582-opencore.315661/#post-2274274 and https://www.tonymacx86.com/threads/...o-15-oled-ux582-opencore.315661/#post-2274358. The original source is from Github repo s-light/ASUS-ZenBook-Pro-Duo-UX581GV. You could also find useful info about multitouch on ScreenPad with this repo.

TL;DR, I was hoping to bring the acpi_call function to our laptop but I don't know where to start. It seems there were some similar DSDT implementation done with some tonymac thread before. (I forgot to backup the files and URL I found; maybe search with "acpi call tonymac", or "acpi call brightness dsdt tonymac", or "acpi call brightness ssdt tonymac", etc on Google) For UHD630, I assume it might have something to do with the keyword, AGPM. I remember in the old days, Intel Sandy Bridge time, I had to made an AGPM kext for my AMD/ATI HD6850 GPU for a better power management. As for the battery issue with monitor brightness, one could simply test whether the battery life in Windows/Ubuntu is similar to macOS with the max out ScreenPad brightness in Windows/Ubuntu.
 
Last edited:
Joined
Mar 8, 2015
Messages
69
Motherboard
MSI Z370m Mortar; ASUS Zenbook Pro UX535LI
CPU
i5-9600k; i7-10750H
Graphics
UHD 630
Mac
  1. iMac
  2. MacBook Pro
I have the smartpad turned off as display by disabling the connector, so no power being used there. So, the power usage is unrelated to backlight in that display. OLED screen has no backlight. Power used is simply whatever is the composite value that reaches each element. Not some brightness masked in a different layer. So software or not does not matter.

I have run Linux on this and the oled solution they have there via xrandr brightness command is pretty much the same as what Lunar does in software (BTW, they have fixed the disconnect between Fn control of brightness and software brightness in the recent updates). I don’t see a similar battery problem. Battery seems to last even longer in Linux than Windows.

Apple Graphics Power Management (AGPM) has been relevant when one wanted to use a dGPU rather than just using the iGPU. Most SMBIOS are designed to work with only iGPU. However, our 10th gen CPUs are using the native 9th Gen AGPM as both are labeled UHD 630 and compatible functionally. But it is possible that the 10th Gen UHD 630 has some power management tweaks that needs to be optimized by a driver written natively for it.

We should probably check if Linux Intel drivers have some Comet Lake specialization but this is hard because Linux graphics is distributed into multiple subsystems rather than a single driver.
 
Joined
Mar 8, 2015
Messages
69
Motherboard
MSI Z370m Mortar; ASUS Zenbook Pro UX535LI
CPU
i5-9600k; i7-10750H
Graphics
UHD 630
Mac
  1. iMac
  2. MacBook Pro
Here is some interesting insights from using the Intel Power Gadget for Mac (free download from Intel) that monitors power and frequency usage. This could be useful for configuring CPU friend.

1. Idle state after bootup
Fig 1.png


2. Graphics test with loading iGPU to max
Fig 2.png


3. CPU test with all cores at maximum frequency
Fig 3.png


4. Behavior when VM Fusion is started with a single Linux Guest showing boot and idle after
Fig 4.png


5. Monitoring during Black Magic Disk Read write test
Fig 5.png


I haven't fully digested this yet but at first glance, if I am reading this right, it seems that the current power management is too happy to boost frequencies to near max at the slightest pretext even though the utilization is low. So the power utilization is almost as bad as all cores running at max utilization.

Try it on your machine and see if you can infer anything from these.
 
Top