[Guide] Laptop backlight control using AppleBacklightFixup.kext

[RehabMan]

I finished writing the post. It is located at here. If you find any error, please feel free to edit it. Thanks

Thanks. Added link to post #1.

 

[Archangeliques]

EmuVariable only optional if you know your native NVRAM is functional.
Requires testing native NVRAM...

Is mine functional from the files you got already?

It corresponds to backlight level 0x00f7 (it is byte reversed in the data, aka Intel byte order).

So? Remember, I'm not a coder. (thank you for the explanations though, I'm doing my best to understand them as a designer Does it mean 100% or anything else? At least we can continue what the problem is with my backlight level. If it's 100%, then whatever I set is not registering. If it's 30-40% then system is not reading that config file or plist on the next boot or resets it on boot. If it's anything than the 2 I just said, then the data it gets not connected to what I set or what system sets (100%).

In that case, what should we do next?

Thanks

Ps: I just reread DSDT/SSDT patching guide and it says:

Finally, keep in mind you cannot provide patched SSDTs without dropping the OEM SSDTs that they replace. The easiest way is to use DropSSDT=Yes (Chameleon) or ACPI/SSDT/DropOem=true (Clover) to drop all the SSDTs, then provide the patched (and unpatched) files for loading by the bootloader.

I didn't set DropOem=true through Clover, Do you think this might be the issue? Also Should I place all SSDTs to patched folder even the ones I haven't patched or just the patched ones are enough like I did? (I have all of them in Clover/ACPI/Original folder anyway)

Thanks

 

[RehabMan]

Is mine functional from the files you got already?

You can only know if your native NVRAM is functional by testing it.

So? Remember, I'm not a coder. (thank you for the explanations though, I'm doing my best to understand them as a designer Does it mean 100% or anything else?

Your hardware likely uses a range of 0-0xad9, so 0xf7 is relatively low in that range.

In that case, what should we do next?

First you should verify NVRAM is working.
Then troubleshoot from there.
If you haven't looked at your native NVRAM contents (use the UEFI shell), then it is probably time to do that also...

I didn't set DropOem=true through Clover, Do you think this might be the issue? Also Should I place all SSDTs to patched folder even the ones I haven't patched or just the patched ones are enough like I did? (I have all of them in Clover/ACPI/Original folder anyway)

Your questions are answered in the ACPI patching guide.

 

[AlistairOvereem]

Thx again #RehabMan! brightness is working, but i didn't change DropOEM from "false" to "true". When i do that (DropOem=true), after loading screen, i see a black screen and there is nothing i can do.

I'll post my files here, if you wanna take a look. Is everything ok?

 

[RehabMan]

Finally brightness is working, but i didn't change DropOEM from "false" to "true". When i do that (DropOem=true), after loading screen, i see a black screen and there is nothing i can do.

Your ACPI patching mistake is off-topic.
You should open a separate thread.

 

[RehabMan]

I'll post my files here, if you wanna take a look. Is everything ok?

SSDT-7.aml and SSDT-PNFL.aml are duplicates. Remove SSDT-7.aml.
Also, in your case SSDT-Config.aml is not needed... remove it.
SSDT.aml and SSDT-0.aml are duplicates. SSDT.aml should have the output from ssdtPRgen.sh. Remove SSDT.aml and replace with ssdtPRgen.sh output.

But, your main mistake is that you renamed GFX0->IGPU only in DSDT... Because config.plist/ACPI/DSDT/Patches apply only to OEM SSDTs, OEM DSDT, and patched/DSDT.aml. Those patches do not apply to SSDTs in ACPI/patched. So you have a situation where DSDT has the rename, but the SSDTs do not. That is probably the cause of your boot fail.

 

[AlistairOvereem]

I've just learned how to rename GFX0 to IGPU using Clover hotpatch. Didn't know that is only a patch for DSDT. To patch SSDT i have to use Maciasl patching option?

 

[RehabMan]

I've just learned how to rename GFX0 to IGPU using Clover hotpatch. Didn't know that is only a patch for DSDT. To patch SSDT i have to use Maciasl patching option?

Do you have some reason why you have all SSDTs in ACPI/patched?
If you're doing renames with hotpatch, why do you have them there?

I don't see that you applied any patches to the SSDTs, so you should really have DropOem=false, and no OEM SSDTs in ACPI/patched. Then your GFX0->IGPU rename will work as you expected (as it applies to patched/DSDT.aml and the OEM SSDTs provided by BIOS).

 

[Archangeliques]

First you should verify NVRAM is working.
Then troubleshoot from there.
If you haven't looked at your native NVRAM contents (use the UEFI shell), then it is probably time to do that also...

Seems like NVRAM is working. nvram.plist back-light value changes on everyboot.

UEFI Shell:
Mapping table:
FS0: Alias(s): HD0a65535a:;BLK1:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
FS4: Alias(s): HD0a65535a:;BLK6:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
FS1: Alias(s): HD0a65535a:;BLK2:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
FS2: Alias(s): HD0a65535a:;BLK3:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
FS3: Alias(s): HD0a65535a:;BLK4:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
BLK0: Alias(s): HD0a65535a:;BLK1:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)
BLK5: Alias(s): HD0a65535a:;BLK1:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)

I don't know if they mean anything to you but neither "sudo nvram -p" nor "nvram -p" commands work in Shell UEFI.

You know what I realized? It's native NVRAM! Because whenever I restarted or turn on the laptop, backlight screams, ASUS logo bright as hell, then Clover boot screen and Apple Loading logo are the same. And you know what? I can change the brightness level in Shell UEFI screen with Fn+F5 and F6 (default Asus brightness keys).

What is your suggestion at this level? I already deleted EmuVariableUefi-64.efi and tried, rebuilt cache, upgrade Clover with the same settings (to install EmuVariableUefi-64.efi and RC Scripts) nothing happened.

 

[RehabMan]

Seems like NVRAM is working. nvram.plist back-light value changes on everyboot.

UEFI Shell:
Mapping table:
FS0: Alias(s): HD0a65535a:;BLK1:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
FS4: Alias(s): HD0a65535a:;BLK6:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
FS1: Alias(s): HD0a65535a:;BLK2:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
FS2: Alias(s): HD0a65535a:;BLK3:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
FS3: Alias(s): HD0a65535a:;BLK4:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1.GPT,...
BLK0: Alias(s): HD0a65535a:;BLK1:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)
BLK5: Alias(s): HD0a65535a:;BLK1:
PCIRoot (0x0)/PCi(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)

I don't know if they mean anything to you but neither "sudo nvram -p" nor "nvram -p" commands work in Shell UEFI.

You know what I realized? It's native NVRAM! Because whenever I restarted or turn on the laptop, backlight screams, ASUS logo bright as hell, then Clover boot screen and Apple Loading logo are the same. And you know what? I can change the brightness level in Shell UEFI screen with Fn+F5 and F6 (default Asus brightness keys).

What is your suggestion at this level? I already deleted EmuVariableUefi-64.efi and tried, rebuilt cache, upgrade Clover with the same settings (to install EmuVariableUefi-64.efi and RC Scripts) nothing happened.

You should not expect the backlight level to restore until macOS boots.
My suggestion:
- fresh install
- make sure your NVRAM configuration is correct (EmuVariable + "RC scripts")
- do CMOS reset
- test result