hieplpvip / AsusSMC

A VirtualSMC plugin provides native macOS support for ALS, keyboard backlight and Fn keys on Asus laptops
MIT License
170 stars 21 forks source link

FN Keyboard Brightness ASUS UX32VD macOS 11.1 #93

Open rafaelmaeuer opened 3 years ago

rafaelmaeuer commented 3 years ago

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 https://github.com/hieplpvip/AsusSMC/issues/20#issuecomment-751487095 and https://github.com/hieplpvip/AsusSMC/issues/74#issuecomment-751441425 the issue seems solved and it should work.

Any help is appreciated.

rafaelmaeuer commented 3 years ago

@hieplpvip @Ubsefor @gulios any ideas on this?

Ubsefor commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Suzamax commented 3 years ago

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

Use Karabiner in order to remap Function keys :-)

Ubsefor commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

No backlight after sleep is back too -> so I am stuck with the original problem: https://github.com/hieplpvip/AsusSMC/issues/93#issue-775351745 @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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/hieplpvip/AsusSMC/issues/89 and might help answering it. The necessary process of a transition from static DSDT-patching to dynamic SSDT-hotpatch works as follows:

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 commented 3 years ago

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

rafaelmaeuer commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

rafaelmaeuer commented 2 years ago

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

hoaug-tran commented 2 years ago

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 commented 2 months ago

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.