FN Keyboard Brightness ASUS UX32VD macOS 11.1

[rafaelmaeuer]

Hi and thanks all very much for this great kext.

FN keyboard brightness stopped working on my ASUS UX32VD with upgrading to Catalina.
Now when doing a re-install with Big Sur I try to fix this problem.

I am using the newest kexts: AsusSMC 1.4.1, Lilu 1.5.0 and WEG 1.4.5.
I re-patched my DSDT according to instructions with kbl_ivybridge.txt.
I also tried applying the single fn-key patches, but without any improvements.

After Installation of AsusSMCDaemon everything works perfect, except two things:

1. No changes in keyboard backlight using fn 2 and 3 keys (no options in settings, so backlight is not recognised correctly)
2. No keyboard backlight after sleep, when sleep-mode was initiated by closing the lid once

After reading lots of old issues, it seemed the problem relates to Big Sur, but regarding #20 (comment) and #74 (comment) the issue seems solved and it should work.

Any help is appreciated.

[rafaelmaeuer]

@hieplpvip @Ubsefor @gulios any ideas on this?

[Ubsefor]

Could it be that you need to check your DSDT in terms of correct port mapping? The issue can be due to system not restoring correct power states after sleep => this can be a signal of bad USB port mapping or USB power management. The patch is in DSDT.
Also, I do encourage you to check whether AsusSMCDaemon is not getting killed for some reason and restarts after sleep correctly. This can happen if Mac OS decides to put com.apple.quarantine xattr at daemon, launch-service plist or (if you installed the kext to /L/E) to the kext itself.

There isn’t much I can do to pin-point the problem, I suggest using darwin dumper or system tools to collect boot and sleep logs and check the things I mentioned.

P.S. I hope you use OpenCore instead of Clover, as there are many problems with Acidanthera kexts usage with the latter from what I heard, the devs also suggest using OC with their kexts.

[rafaelmaeuer]

Thank you for the answer! I will check the USB port mapping.

When running launchctl list | grep Asus it outputs 580 0 com.hieplpvip.AsusSMCDaemon after sleep.
Seems like the deamon is running after sleep if this is the correct way of checking this?

At the moment I am still using clover, as the transition to OC will cost me a lot of time.
It might be necessary or worth, but if I can get keyboard backlight working I am happy.

[Ubsefor]

It is actually not that hard to transition from clover to OC, there are guides out there.

Either way, if you have your DSDT patches, then it shouldn’t be hard at all.

[rafaelmaeuer]

Ok after completely re-patching the whole DSDT (which seemed not to work correctly in the previous attempt) it is working now!!! This kext is really great work - thanks to everybody involved! On small problem remains: Using the "Pause" key which is located right to F12 causes display brightness to increase... any idea on how to disable this?

[rafaelmaeuer]

How can I find out the correct key code to patch this key?

[Suzamax]

How can I find out the correct key code to patch this key?

Use Karabiner in order to remap Function keys :-)

[Ubsefor]

How can I find out the correct key code to patch this key?

Use Karabiner in order to remap Function keys :-)

Its a dirty hack. The author needs to find correct keycodes for his keyboard. I suggest browsing through hieplpvip’s ACPI patches as there are the keycodes you are looking for.

[rafaelmaeuer]

It is actually not that hard to transition from clover to OC, there are guides out there.

Either way, if you have your DSDT patches, then it shouldn’t be hard at all.

@Ubsefor I actually tried the transition to OC, the system boots and most things are working. But it seems that loading a patched DSDT is not recommended/working at all. So FN keys are without function with OC now. Yes I do have all my DSDT patches, but how are they applied with OC?

[rafaelmaeuer]

Finally I got FN keys working - I had some trouble injecting the VoodooPS2 kext. Now everything works except changing the keyboard backlight. When pressing the keys I see the overlay symbol which shows that the OS is receiving the commands. But no changes are applied to keyboard backlight. Any idea how to fix this?

[rafaelmaeuer]

No backlight after sleep is back too -> so I am stuck with the original problem: #93 (comment)
@Ubsefor I generally appreciate the transition to OC, but it brought the already solved problem back

EDIT1: I use the debug kext now with -asussmcdbg boot-arg, despite verbose boot how can I see the logs?
EDIT2: Found the logs in Hackintool -> Boot. This is how it looks like when pressing F3/F4:

[  583.303948]: HID Activity Tickle (type:0 sender:1000002a8)
[  583.464539]: HID Activity Tickle (type:0 sender:1000002a8)
[  583.777867]: AsusSMC       als: @ (DBG) refreshALS lux 50
[  583.778623]: AsusSMC       fan: @ (DBG) refreshFan speed 3802
[  584.784848]: AsusSMC       als: @ (DBG) refreshALS lux 50
[  584.785475]: AsusSMC       fan: @ (DBG) refreshFan speed 3796
[  584.926221]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.027778]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.162811]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.243010]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.357095]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.442599]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.546241]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.637102]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.740692]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.787063]: AsusSMC       als: @ (DBG) refreshALS lux 50
[  585.788153]: AsusSMC       fan: @ (DBG) refreshFan speed 3802
[  585.831584]: HID Activity Tickle (type:0 sender:1000002a8)
[  585.989290]: HID Activity Tickle (type:0 sender:1000002a8)
[  586.080134]: HID Activity Tickle (type:0 sender:1000002a8)
[  586.794345]: AsusSMC       als: @ (DBG) refreshALS lux 50
[  586.794977]: AsusSMC       fan: @ (DBG) refreshFan speed 3782
[  587.801035]: AsusSMC       als: @ (DBG) refreshALS lux 50
[  587.801694]: AsusSMC       fan: @ (DBG) refreshFan speed 3796

[rafaelmaeuer]

Today I got control over keyboard-backlight twice, but I have no clue where to search for a correlation.

It worked after re-patching the DSDT (not reproducible). I thought it might be related to previous USB- or following ALS-Patches but I tried all possible combinations -> not reproducible.

I investigated if the selected keyboard type has influence (there are Keyboard and Apple Virtual Keyboard as sources available in system-settings) but it doesn't seem to correlate.

When testing, if automatic display brightness in system-settings (based on ALS) has influence, I couldn't find a relation.

Switching between debug and release versions of OpenCore and AsusSMC, seems to have no influence.

Of course I reset nvram and re-installed AsusSMCDaemon a multiple times without any improvement.
I really have no clue where to look further on this problem. Please help!!!

EDIT: While further testing parallel to this writing, I swapped my boot stick to another USB-Ports and voila backlight-control of the keyboard works. But only on first boot on the corresponding USB-port. So I installed OpenCore on internal EFI partition -> not working 🤬

[rafaelmaeuer]

How can I find out the correct key code to patch this key?

Use Karabiner in order to remap Function keys :-)

This is working by the way -> will keep it as solution

[rafaelmaeuer]

It is actually not that hard to transition from clover to OC, there are guides out there.

Either way, if you have your DSDT patches, then it shouldn’t be hard at all.

Already working sleep breaks with OpenCore too - although correctly applied GPRW-Patch (works on other machine). Without any help I need to transition back to Clover for now...

[rafaelmaeuer]

Using OpenCore on my main system now, the move back to clover feels like going a step back/giving up with this laptop.

Therefore in a last effort I rebuilt the Hackintosh from scratch following all the way down of OpenCore's guides. As OC prefers ACPI-hot-patching with SSDT's instead of static ACPI-patching via DSDT, I needed to find solutions for all kind of static DSDT-patches which made the UX32VD working nearly perfect also with Big Sur.

With the latest release I gave OC 0.6.6 a try, as it's the first version running as application instead of a driver. Finding replacement SSDT's for all DSDT-patches was no easy work, but I cover everything important now in form of a SSDT patch (I will update my repo soon).

Therefore I created a working USB-Mapping with USBMap and fixed Power-Management with ssdtPRGen-method to exclude errors @Ubsefor suggested to investigate. I was able to fix the broken sleep with a custom GPRW-patch too.

The most complicated part was to transition the Battery-Patch as OC-Guide says: must be done manually. But with help of RehabMans guide for Battery Status Hotpatch an a lot of patience it was successful at the end.

I am writing all of this to discuss with @hieplpvip which transition will be necessary for this repo to integrate in a future based on OC-conform ACPI-patching. It is also related to #89 and might help answering it. The necessary process of a transition from static DSDT-patching to dynamic SSDT-hotpatch works as follows:

• extract DSDT from the system and convert to .dsl format
• patch DSDT for desired change and export as .aml file (as usual)
• boot with included DSDT.aml (although not recommended) and verify the patch works
• create a diff of DSDT-org and DSDT-patched with diffmerge or kaleidoscope
• create SSDT from DSDT-diff by learnings from RehabMans hotpatch-acpi guide
• export SSDT in .aml format, include it in OC and create ACPI-renames (if necessary)
• boot and verify the patch works as it did with static patching

I did this with kbl_ivybridge.txt patch for testing and this is the outcome of my SSDT-ASMC:

DefinitionBlock("", "SSDT", 2, "hack", "AsusSMC", 0)
{
    External(_SB.ATKD, DeviceObj)
    External(\_SB.PCI0.LPCB.EC0.WRAM, MethodObj)
    
    Scope (_SB.ATKD)
    {
        Method (SKBV, 1, NotSerialized)
        {
            ^^PCI0.LPCB.EC0.WRAM (0x044B, Arg0)
            Return (Arg0)
        }
    }
}

I booted with AsusSMC.kext and SSDT-ASMC.aml included and enabled in OC. On one boot I had success in controlling the keyboard-backlight, but this was again a one-time shot and no reproducable behavior. So this method seems to work and adapt to OC's way of ACPI-patching, but it doesn't solve the problem which came with the transition to OC.

On every boot the option of changing keyboard-backlight is visible which means the required device is recognized correctly. But the alternation of keyboard-backlight is rarely/randomly working wether with static or dynamic ACPI-patch.

[rafaelmaeuer]

just found SSDT-ATK-BDW.dsl and SSDT-RALS.dsl in hieplpvip/Asus-Zenbook-Hackintosh repo - will give it a try.

[rafaelmaeuer]

Ok with hieplpvip's repo I was finally able to nail the issue:
The problem was SMCLightSensor.kext enabled which conflicts AsusSMC.kext in handling the ALS sensor.

Now with just AsusSMC.kext enabled and SSDT-patches inspired by SSDT-ATK-BDW.dsl and SSDT-RALS.dsl the control of keyboard backlight is working again - what a ride 😬

[rafaelmaeuer]

How can I find out the correct key code to patch this key?

Use Karabiner in order to remap Function keys :-)

Its a dirty hack. The author needs to find correct keycodes for his keyboard. I suggest browsing through hieplpvip’s ACPI patches as there are the keycodes you are looking for.

As the required keycodes for Pause (F15 in karabiner) and Print (F13 in karabiner) are not in hieplpvip’s ACPI patches, I followed this guide to get the keycodes. ACPI-Debug doesn't gave any output for me, but with VoodooPS2 (Debug) I got e045=71 and e037=69. I don't know if its possible to convert them to the _QXY format so I keep the karabiner-solution for now.

[rafaelmaeuer]

I am wondering about two last things:

1. There is no feedback with ALS-toggle (Fn+A), but I remember there was once some overlay, maybe from AsusNBFnKey times. Using AsusSMC-Daemon there must be a possibility to give an overlay-feedback like backlight/volume-changes?
2. Karabiner offers the possibility to toggle the LED in CAPS-lock key. There is such a LED in the F2 key too. Is there a possibility to enable this LED by ACPI-patch to wether represent WiFi or maybe ALS on/off-state?

These are really cosmetic things, but would improve daily work with a Hackintosh using AsusSMC. Thanks again everybody for this great kext and sorry for flooding this issue with the progress of my problem, but it might help others to read this.

[shiecldk]

@rafaelmaeuer @Ubsefor I followed this topic to create my SSDT for my ASUS Comet Lake laptop. However, I cannot get the keyboard backlight and other FN keys work pm Catalina 10.15.7, nor is ASUSSMC.kext seemed to be loaded when I checked kextstat | grep -i ASUSSMC. However, launchctl list | grep Asus shows653 0 com.hieplpvip.AsusSMCDaemon. Could you help me check my SSDT?

SSDT-ATK.dsl.txt
SSDT-RALS.dsl.txt

[hoaug-tran]

Hey everyone, is there anyway guide for patch keyboard blacklight? tks

[rafaelmaeuer]

Have a look at the following links which should get you started:

• https://github.com/rafaelmaeuer/Asus-UX32VD-Hackintosh/blob/master/ACPI/README.md#als--keys-fnbacklight
• https://dortania.github.io/Getting-Started-With-ACPI/ssdt-methods/ssdt-long.html

[hoaug-tran]

I tried patch according to SSDT-ATK.dsl.txt
and SSDT-RALS.dsl.txt but my keyboard blacklight not work (and cant control ), it just show control keyboard blacklight at Control Center. Please help me, thank you

[ouija]

Just wanted to mention that I gained some insight from this thread on how to successfully build my own SSDT patch for Kaby Lake based systems!

This patch is based off a combination of the [kbl] Kaby Lake/Kaby Lake-R patch and the Fake ALS patch available on the AsusSMC repo (both are required for keyboard backlight to illuminate)

• No additional function key patches were added; Use in conjunction with BrightnessKeys.kext, VirtualSMC, and the SSDT-PNLF.aml generated by SSDTTime.
• Note that the SMCLightSensor.kext should not be installed/enabled as it is unnecessary and might conflict with AsusSMC and the Fake ALS patch.