qonfused / asus-zenbook-duo-14-ux481-hackintosh Goto Github PK

--- @vit9696: acidanthera/NVMeFix#7 (comment) ---
Updating NVMeFix to macOS 14 will require substantial code changes. I would say current NVMeFix is already pretty much discontinued and needs fixes even for macOS 13. We will probably not release an update for it with macOS 14 support.

(Latest update): https://dortania.github.io/hackintosh/updates/2022/11/07/acidanthera-november.html

UX581GV: linuxwacom/wacom-hid-descriptors#75

I'm considering creating an injector kext for ScreenPad Plus display overrides, similarly to the VoodooInjector project. Below is an example of how it's setup for just the BOE087F panel:

This replaces the need for an installation-specific display override file:

It may be better to merge this with the VoodooInjector repo and rename it to be ScreenPadInjector or similar as it specializes in injecting various ScreenPad related IOPersonalities.

Follow up to shiecldk/ASUS-ZenBook-Pro-Duo-15-OLED-UX582-Hackintosh#2 investigating scrambled screenpad plus display-out.

Current tasks:

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

Hello,

I put a small list of Kexts that need to be updated.
As I don't have the permission for Pull Requests, I put it in an Issue.

What ChangeLog :

Main changes :

• Removed unwanted flicker when launching non-text entry.

• Changed macrecovery to download files into com.apple.recovery.boot by default.

• Improved Apple builtin picker (BootKicker.efi) on some systems and after reboot.

• Misc -> Boot -> ShowPicker changed from Boolean to String, valid values are:

• • Always - Always show picker (equivalent to ShowPicker=True).
• • Never - Never show picker (equivalent to ShowPicker=False).
• • SkipOnHibernateWake - Don't show picker if waking from macOS hibernation.

• Misc -> Boot -> added HibernateSkipsPicker (Boolean): not to show picker if waking from macOS hibernation. Failsafe value: false.

config.plist :

• Misc -> Boot -> ShowPicker changed from Boolean to String, valid values are Always, Never and SkipOnHibernateWake.
• Misc -> Boot -> added HibernateSkipsPicker (Boolean), failsafe value is false.

Download table :

Sincerely, UsedDiscord / Magik

⁉️ My Source : Everything comes from the formal creators.

⚠️ ❗ I have not tested anything on the ASUS! I'm posting this just like that but I haven't tested the OpenCore update... nor the Kexts ⚠️ ❗

SOURCE CHANGEMENTS

AnyiSightCam UVC driver requires info.plist changes for all instances of idProduct and idVendor with decimal form of the product and vendor ids. You can find these values for the webcam in system information under USB. May require documentation for potential fixes.

In my case I had 0x56cb and 0x13d3 for my product and vendor ids.

It's possible that HDMI audio does not work due to an unset power well state. This was discovered from a check that looks for the presence of a connector flag (from the internal display, oddly enough).

This check was found in AppleIntelFramebufferController::getPowerWellState:
https://github.com/acidanthera/WhateverGreen/blob/c5a5f507f54a6ff1d17e048fb9456302ef2a3702/WhateverGreen/kern_fb.hpp#L138-L142:

0x100 // Activates Power Well 2 usage (SKL_PW_CTL_IDX_PW_2)
0x80  // Activates MISC IO power well (SKL_DISP_PW_MISC_IO)

I've previously encountered this in #4 (comment), which brings some related points to this issue (as both audio and DDI_B lanes are within the power domain of PW2).

For HDMI (digital audio), the suggested fix is to change the connector flags for the internal display (con0) from 98000000 to 98010000:

framebuffer-con0-alldata | Data | <00000800 02000000 98010000>
framebuffer-con0-enable  | Data | <01000000>

Hi @Qonfused, please see the updated sections 3.4 and 3.5 on UX582 guide to reduce the boot time. I successfully implemented these tweaks on UX582; however, there are some issues with compiling IntelBTPatcher.kext (IntelBTPatcher.kext/IntelBTPatcher/MacOS is empty and fw_name is missing after the implementation).

I have these files loaded with OpenCore 0.8.8:
BlueToolFixup.kext (only for after macOS Monterey)
IntelBluetoothInjector.kext (only for before macOS Monterey)
IntelBluetoothFirmware.kext
IntelBTPatcher.kext

On startup, touchscreen on both displays works in legacy mouse mode (no multitouch/PTP mode); it also appears to no longer respond about a minute after login. These issues were also described in @shiecldk's tonymacx86 UX582 thread prior to resolution, and describes an issue with VoodooI2CHID where changing driver/device priority can break multitouch.

@gkvt's fork of VoodooI2C at https://github.com/gvkt/VoodooI2CHID resolves an architecture incompatibility w/ multi-I2C HID devices; the workaround allows for greater control of which driver is attached to which device. The pull request for this fork was tracked in VoodooI2C/VoodooI2CHID#58 (closed) and VoodooI2C/VoodooI2CHID#59 (merged).

Refer to VoodooI2C/VoodooI2C#485 (comment) for Info.plist changes (changes are to match drivers to device-specific product ids rather than device names).

For reference, discussion on multi-touch support for touchscreen w/ VoodooI2C details the debugging used to modify the kext's Info.plist to prevent interference from touchscreen/precision trackpad event drivers.

The correct SecureBootModel key (under Misc > Security) is j223 for the MacBookPro16,3 SMBIOS.

Some more information here that describes potential issues:
https://dortania.github.io/OpenCore-Post-Install/universal/security/applesecureboot.html#securebootmodel

With the addition of SD card device path support in OpenCore 0.8.8, it may become desirable to explore SD card support at boot. The UX481FA/FL models feature a RTS522A PCI express card reader (cf.) which requires a driver to be loaded for boot entries to be properly detected and loaded by OpenCore. These drivers can be pulled from the BIOS image, with other models provided by OcBinaryData per this commit: acidanthera/OcBinaryData@4d362e8.

This is based on information found in acidanthera/bugtracker#1894, concerning the same PCI SD card reader. This will need to be tested on other models (UX581/UX582) as they may feature the same device.

Release article: https://dortania.github.io/hackintosh/updates/2023/01/04/acidanthera-january.html

Notable changes to OpenCore and surrounding kexts:

• SD card path support for boot device selection
• VoodooInput updated to version 1.1.3 (now appears to be maintained)
• VoodooPS2 2.3.3 adds fixes for scrolling and button issues

Backlight is set by ACPI calls exposed through a WMI driver. For reference, there is a linux module that probes ACPI for methods controlling backlight of the screenpad. Below details basic methods for the display's backlight control implemented similarly to keyboard backlight control in AsusSMC:

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    | };

819   |	if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_SCREENPAD)
820   |		&& !screenpad_led_read(asus, &led_val)) {
821   |		asus->screenpad_led_wk = led_val;
822   |		INIT_WORK(&asus->screenpad_led_work, screenpad_led_update);
823   |
824   |		asus->screenpad_led.name = "asus::screenpad";
825   |		asus->screenpad_led.brightness_set = screenpad_led_set;
826   |		asus->screenpad_led.brightness_get = screenpad_led_get;
827   |		asus->screenpad_led.max_brightness = 0xff;
828   |
829   |		rv = led_classdev_register(&asus->platform_device->dev,
830   |					   &asus->screenpad_led);
831   |	}

If it can't be controlled in the same submenu as the primary display, then mapping Screenpad backlight brightness in a control center slider like keyboard brightness may be a good alternative UX implementation:

New SMBIOS better matches the clocks + TDP of the CPU, though has iris plus graphics instead (already handled by framebuffer patches in #1).

See https://dortania.github.io/OpenCore-Install-Guide/extras/smbios-support.html#macbook-pro as far as instructions go (you may have to replace all existing entries of ROM, SMBIOS, Serial, etc manually).

(WIP)

Screenpad Plus

• Display output
• Pre-OS (OpenCore verbose)
  • UEFI GOP
• iGPU Framebuffer
  • Valid clock data
  • Proper RGB screenspace
  • QE/CI acceleration
• Display metadata (EDID)
  • Device Name (Cosmetic)
  • Device and Vendor IDs
  • Valid resolution data
  • Physical size info (Cosmetic)
• Touchscreen
  • Basic pointer functionality
  • Multitouch Gestures
  • GPIO Pinning (addresses intermittency issue)
• Backlight control
  • Leveled slider control
  • Power toggle

Trackpad

• Trackpad functionality
  • Basic pointer functionality
  • Multitouch Gestures
  • Disable force-touch pressure collision (for Recovery)
  • GPIO Pinning (addresses intermittency issue)
• Physical buttons
  • Recognize PS2 interface
  • Proper button mapping

Misc. Interface Devices

• Primary Display (Touchscreen)
  • Basic pointer functionality
  • Multitouch Gestures
  • GPIO Pinning (addresses intermittency issue)
• Capacitive Stylus
  • Basic pointer functionality

Misc. Audio Devices

• Built-in Speakers
• Built-in Microphone

IR Devices

• Windows Hello Camera

Some additional software features to test/develop for non-opencore targets:

• Virtual Touchbar (link to project).
  • Refactor for compiling to different macOS versions.
• Fan Control
• (os agnostic)
  • Create ACPI patch to expose basic fan controls
• Windows
  • Recover EC writes from MyASUS driver.
  • Create notebookfancontrol profile (for non-opencore use).
• Linux
  • Port fan control to ASUS linux driver
• macOS
  • Expose fan control through AsusSMC kext
  • Expose fan control through touchbar slider

Cosmetic macOS overrides/features:

• Force dock to primary display.

The currently used APIC pins sidestep #24 but introduce additional instability in touchscreen events, evidenced in missing pressure events (some touches may be skipped).

A current workaround is to revert to polling mode, although this re-introduces #24.

Using VoodooI2C, I2C devices can stop responding intermittently until sleep (even when polling mode is forced).

Regarding interface devices like the trackpad and touchscreen displays, this also appears to be an issue affecting I2C devices with GPIO interrupts (see VoodooI2C/VoodooI2C#435). It also appears to happen with the same controllers (i.e. same pad group) on another comet lake laptop in that issue: VoodooI2C/VoodooI2C#435 (comment).

GPIO pinning may also be silently failing, falling back to I2C polling. They can still report the expected GPIO pin and report GPIO mode when instead using I2C polling. Should have been resolved as per VoodooI2C/VoodooI2C#487 but may be worth checking for regression.

Update: GPIO pinning is failing for all 3 input devices and falling back to polling mode.
voodooI2C.log

The current SSDT-ATKD manually implements many common WMI hotkeys that are redundantly implemented in the Asus-SMC kext (or should be implemented into that project). This includes brightness keys for the primary display and keyboard backlight. Using the WMI/Asus-SMC methods allows for a more standardized implementation less prone to error from model-specific quirks.

Method (_Q0E, 0, NotSerialized)  // _Qxx: EC Query, xx=0x00-0xFF
{
    If ((MSOS () >= OSW8))
    {
        BRTN (0x87)
    }

    Return (Zero)
}

Method (_Q0F, 0, NotSerialized)  // _Qxx: EC Query, xx=0x00-0xFF
{
    If ((MSOS () >= OSW8))
    {
        BRTN (0x86)
    }

    Return (Zero)
}

There are two main implementations that can resolve this issue:

• Adding a MSOS fix should allow for brightness keys to work without SSDT-ATKD (using native methods instead). This will also require a PNLF to XNLF to address a pre-existing PNLF variable so that SSDT_PNLF will work properly.
• The BrightnessKeys kext can also be used to fix backlight keys through the use of a keyboard remap + notifier methods for backlight; Replaces ATKD methods and renames.

Proposal

I'm a beginner and I don't really understand how to use your configuration, do you have a tutorial or can tell me all the steps to follow to succeed in doing it? THANKS!

Anything else?

No response

Does the WiFi chip in the Zenbook's support this feature? Not entirely sure what the requirements are for this to work, but I know it doesn't for me using @shiecldk EFI, just gets stuck attempting to unlock then prompts for a password instead.

For reference, the Wi-Fi card appears to be a derivative of this

Use the following kexts to allow the pcie realtek microsd reader to be detected as a native microsd reader:

• Driver: https://github.com/0xFireWolf/RealtekCardReader
• Lilu Plugin: https://github.com/0xFireWolf/RealtekCardReaderFriend

There is an older alternative, though it presents possible sleep issues and isn't visible in system report, etc:

• https://github.com/cholonam/Sinetek-rtsx

So, after updating Kexts... the trackpad works!

CONNEXION : #4 #3

Working on summary -- pending commits to https://github.com/Qonfused/AsusSMC.

The original repo's usb mapping is not compatible with the UX481FLY motherboard. This can additionally interrupt functionality of devices like bluetooth (in this case using usb 1.1) and the internal webcam (using usb 2.0).

Replacing previous USB mapping kexts with new ones using USBToolbox on windows should resolve some missing/buggy behaviors.

A good breakdown of how this driver works is explained in an InsanelyMac Forum post by @miliuco; the driver scans the BIOS's HiiDatabase for CFG Lock registers, and can set their bits to 0x00 to unlock them.

This is primarily needed for power management (required by the kernel and AppleCPUPowerManagement) as it's needed to define the CPU's C-states or idle states.

Requires:

• UEFIShell.efi - For running commands/drivers interactively.
• ControlMsrE2.efi/CFGLock.efi - For unlocking CFG Lock (ref: 0xE2 MSR register).

Disable:

• ASUS-ZenBook-Duo-14-UX481-Hackintosh/src/config.yml

  Lines 102 to 107 in 0c04436

  	Kernel:
  	Quirks:
  	# Disables 0xE2 MSR modification in XNU kernel.
  	# - Addresses early panic issues due to 0xE2 write conflicts.
  	# - Note: Is equivalent to disabling `CFG-Lock` in BIOS.
  	AppleXcpmCfgLock: Boolean | true

Due to a regression in BluetoolFixup, Bluetooth may be broken on later versions of Ventura and macOS Sonoma.

The below NVRAM patch is required for BluetoolFixup on 13.4+

# Ventura 13.4 fix for BluetoolFixup
NVRAM:
  Add:
    7C436110-AB2A-4BBB-A880-FE41995C9F82:
      bluetoothInternalControllerInfo: Data | 00000000 00000000 00000000 0000
      bluetoothExternalDongleFailed:   Data | 00

(Fix originally contributed by @qcTimb3rlandqc in IntelBluetoothFirmware#435)

Alternatively, an updated binary is provided by @zxystd here, which should also be applicable for users updating to macOS Sonoma.

A basic breakdown of each file is given below:

This is mainly relevant for the UX481FA/FL since the UX581/UX582 models have a media key + native ACPI implementation for toggling thermal policy. For all models, both (2) fans are controlled by the BIOS + embedded controller, though cooling policy is still configurable via ACPI methods as hinted by the system control driver used by MyASUS.

RW-Everything on Windows should show what EC registers are actually being used for fan control, however there should be more standard ACPI methods called by the system control driver (which you should always use rather than writing to EC registers directly).

Below are some observations that may clue into the native ACPI implementation of this:

• An ACPI method \_TZ_.RTMP reads and stores the current CPU temperature.
  • The ECPU EC method reads the current CPU temperature.
  • This method is used under the _TMP method of the THRM thermalzone, which should shed some light on how cooling policy is configured.
• The \_TZ_.RFAN method (in the same scope) is responsible for reading the fan speed.
  • The ECAV EC method checks if the embedded controller is available/ready, otherwise the method aborts with value zero.
  • The ST83 EC method outputs byte values for a given fan idx (range appears to be between 0x00 and 0xFF)
  • The TACH EC method outputs the RPM from a tachometer for a given fan idx (appears to max at 6000 RPM).
• Potentially relevant, under WMND (IIA0=0x00110019) there are several blocks checking a FANF variable.
  • This is likely referenced in the MyASUS driver for fan diagnostics; it potentially refers to fan PWM frequency.

While sleeping, macOS will instant wake whenever the device's USB or power states change. More information is available here: https://dortania.github.io/OpenCore-Post-Install/usb/misc/instant-wake.html.