Jump to content

Lenovo T530 Clover - Brightness Level resets to max after reboot


5T33Z0
 Share

13 posts in this topic

Recommended Posts

So I have a great working Lenovo T530 with configs for Clover and OpenCore. I worked really long on them. OpenCore is perfect but I noticed when I switch to Clover for testing things, the brightness always resets to maximum on Reboot and I don't know why. It uses the same SSDT-ALS0 and SSDT-PNLF files for both Clover and OpenCore.

 

If anybody is interested in having a look, here's my Repo with all the files (under Releases) : https://github.com/5T33Z0/Lenovo-T530-Hackinosh-OpenCore

 

Thanks

 


Like audio volume level, brightness level is normally retained in NVRAM; at least, that's the case on my Dell Hackintosh laptops (with no dynamic brightness/ambient light sensing enabled), including my Ivy Bridge/HD4000 Latitude E6230 and my Skylake/HD520 Latitude E7270, both booting Big Sur (+ Monterey in the case of the E7270) with Clover r5133. Check that you have NVRAM fully working.


Like I said: everything is working in OpenCore, so I'm pretty sur that NVRAM is fully working. I can boot everything from High Sierra up to Monterey. My guess it's related to SSDT-PNLFs.

 


Are there any ACPI Samples included in Clover? The SSDT-PNLF.aml or SSDT-ALS0.aml use in OpenCore doesn't seem to work correctly in Clover. Every time I reboot my Noteboo,k the brightness is reset to 100 % and I don't know why.


Are there any ACPI Samples included in Clover? The SSDT-PNLF.aml or SSDT-ALS0.aml use in OpenCore doesn't seem to work correctly in Clover. Every time I reboot my Noteboo,k the brightness is reset to 100 % and I don't know why.

Do you have working nvram?


Sent from my iPhone using Tapatalk

@SavageAUS Yes, I do. In Open Core everything works perfectly fine.

 

From the Preboot.log

 

Quote

5:937  0:000  found boot-args in NVRAM:applbkl=1 brcmfx-country=#a -gux_defer_usb2, size=44
5:937  0:000  after NVRAM boot-args=applbkl=1 -gux_defer_usb2 brcmfx-country=#a
5:937  0:000  === [ Dump SMC keys from NVRAM ] ================
5:984  0:000  === [ GetEfiBootDeviceFromNvram ] ===============
21:819  0:000  OC: OcLoadNvramSupport...
21:887  0:000  SetNvramVariable (system-id, guid, 0x2, 16): -> writing new (Success)
21:887  0:000  SetNvramVariable (MLB, guid, 0x6, 17): -> writing new (Success)
21:887  0:000  SetNvramVariable (ROM, guid, 0x6, 6): -> writing new (Success)
21:887  0:000  SetNvramVariable (FirmwareFeatures, guid, 0x6, 4): -> writing new (Success)
21:888  0:000  AddNvramVariable (FirmwareFeaturesMask, guid, 0x6, 4): -> writing new (Success)
21:888  0:000  AddNvramVariable (HW_BID, guid, 0x6, 20): -> writing new (Success)
21:889  0:000  AddNvramVariable (security-mode, guid, 0x6, 5): -> writing new (Success)
21:889  0:000  AddNvramVariable (backlight-level, guid, 0x6, 2): -> writing new (Success)
21:889  0:000  DeleteNvramVariable (DefaultBackgroundColor, guid = Not Found):
21:889  0:000  SetNvramVariable (UIScale, guid, 0x6, 1): -> writing new (Success)
21:890  0:000  SetNvramVariable (EFILoginHiDPI, guid, 0x6, 4): -> writing new (Success)
21:890  0:000  SetNvramVariable (flagstate, guid, 0x6, 32): -> writing new (Success)
21:890  0:000  SetNvramVariable (csr-active-config, guid, 0x6, 4): -> writing new (Success)
21:890  0:000  DeleteNvramVariable (bootercfg, guid = Not Found):
21:891  0:000  DeleteNvramVariable (nvda_drv, guid = Not Found):
21:891  0:000  DeleteNvramVariable (recovery-boot-mode, guid = Not Found):
21:891  0:000  AddNvramVariable (wake-failure, guid, 0x6, 5): -> writing new (Success)
21:892  0:000  SetNvramVariable (efi-boot-device-data, guid, 0x7, 110): -> writing new (Success)
21:894  0:000  SetNvramVariable (efi-boot-device, guid, 0x7, 216): -> writing new (Success)
21:897  0:000  DeleteNvramVariable (IOHibernateRTCVariables, guid = Not Found):
21:897  0:000  DeleteNvramVariable (boot-image, guid = Not Found):

 

Edited by 5T33Z0

It seems you're a little confused. What's the relation with OpenCore or the relevance of being able to "boot everything from High Sierra to Monterey" and having NVRAM working under Clover? If you switch from OC to Clover, make sure you 1st reset NVRAM so that you don't keep any leftover from OC. You may then be able to verify whether you have NVRAM working under Clover or not. The PNLF table is not specific to the bootloader. If brightness control works, the table can be considered Ok. I'd also check that the ACPI patches you've applied to rename the iGPU ACPI device to "IGPU" are operating as expected.


NVRAM is working. I've verified it. NVRAM Reset is a given.

 

If the problem was related to NVRAM, storing brightness should work after emulating NVRAM, right?. So I added EmuVaribleUefi.efi. Same result. So I conclude it's related to something else. The renames all work, otherwise the brightness shortcut keys wouldn't work either. So, I guess unless somebody takes a look at the EFI we are done here.

  • Sad 1

8 minutes ago, 5T33Z0 said:

NVRAM is working. I've verified it. NVRAM Reset is a given.

 

If the problem was related to NVRAM, storing brightness should work after emulating NVRAM, right?. So I added EmuVaribleUefi.efi. Same result. So I conclude it's related to something else. The renames all work, otherwise the brightness shortcut keys wouldn't work either. So, I guess unless somebody takes a look at the EFI we are done here.

try adding ALS0.aml

  • Haha 1

Well, so far, you've not shown any evidence of working NVRAM under Clover; you simply limited yourself to stating it did and the only NVRAM logs you provided were Opencore's. You've not even stated if brightness control worked at all. Ok...

 

Here are details of the setup on my Ivy Bridge/HD4000 Dell Latitude E6230 laptop (you've not provided any specs but I understand the ThinkPad T530 to be an Ivy Bridge/HD4000 model too):

  • BIOS operating in UEFI mode of course
  • Clover r5133
  • no patched ALS0 table
  • "standard"/regular/well-known/readily available (at Dortania for instance) SSDT-PNLF table -> SSDT-PNLF.aml.zip
  • additional Dell-specific patch for brightness keys (irrelevant for your T530 of course)
  • EmuVariableUefi.efi Clover driver/module (because my E6230 needs emulated NVRAM)
  • RC scripts (for obvious reasons)

Clover drivers installed (many, such as audio/FAT/mouse, may not be relevant to your setup of course, some are even old leftovers) :

Clover_r5133_installed_drivers.jpg

 

Brightness level resides in NVRAM parameter backlight-level (audio level resides in NVRAM parameter SystemAudioVolume) as shown with Terminal command nvram -p:

admin@E6230 ~ % nvram -p
[...]
backlight-level %10%07
SystemAudioVolume %1d
[...]

 

The above backlight level is for max. brightness settings (level 16) on my E6230. If I reduce brightness, I can see this being immediately reflected in the NVRAM parameter (for audio volume, only after reboot):

  • brightness down to level 10:
backlight-level /%02
  • brightness down to to level 4:
backlight-level %94%00
  • brightness down to to level 2:
backlight-level R%00

 

With regards to your patched SSDT-PNLF table, I went back to your GitHub repo as per the link you posted above and found that, in that Clover r5139 setup of yours, you use (I quote) "an updated version based on latest ACPI Samples to improve Windows Compatibility" (whatever this may be and/or the likely (ir)relevance to Clover) which defines no ACPI device "PNLF" and injects all PNLF patch code directly under IGPU... -> 5T33Z0_SSDT-PNLF.aml.zip

 

Allow me to remind you the purpose of the patched SSDT-PNLF table as stated here, in the Dortania documentation:

SSDT-PNLF_purpose.jpg

 

I'd invite you to revert to the SSDT-PNLF table you had in your Clover r5138 setup (-> 5T33Z0_Clover-r5138_SSDT-PNLF.aml.zip) or to a standard one such as the version I posted above or the version available at Dortania (see link right above).

 

Once you've verified your PNLF patch and established for sure it was Ok, I invite you to check again that NVRAM is working properly under Clover and check your settings in the Clover PrefPane; install it if you haven't. No need to mention RC scripts, you know all about these of course.

Clover_PrefPane.jpg

 

Oh, I could not help but notice that additional boot arg in your Clover config: applbkl=1; 'pretty sure you can get rid of this, I don't believe it's necessary and I always understood it was meant to be used with a null value to disable backlight patches.

WEG_appblk.jpg

 

But I believe it's deprecated stuff:

https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.OldPlugins.en.md

applblk.jpg

 

And, on this, I'm done. Good luck.


Fair enough. But I think there are a also few things you still need to learn about Dirvers. And  If you don't beleve me, go check Slice's Documentation Thread for Clover - it's all in there.

  • DataHubDXE > Unnecessary. Fully Integrated in Clover since r5129.
  • EmuVariableUefi > Only necesseary in NVRAM is  not available (legacy systems) or working incorrectly. (I tested this already, so that's not it)
  • FSInject.efi > Fully integrated in Clover. Necessary only for legacy versions of macOS ≤ 10.7 (Lion) which are able to load individual kexts instead of prelinkedkernel. So in other words: redundant.

2. Here's an excerpt from the Clover's Preboot.log from in regards to NVRAM (of course it says "OcLoadNvramSupport", since Clover uses OpenRuntime since r5123):

5:941  0:000  after NVRAM boot-args=applbkl=1 -gux_defer_usb2 brcmfx-country=#a
5:941  0:000  === [ Dump SMC keys from NVRAM ] ================
5:984  0:000  === [ GetEfiBootDeviceFromNvram ] ===============
31:316  0:000  OC: OcLoadNvramSupport...
31:384  0:000  SetNvramVariable (system-id, guid, 0x2, 16): -> writing new (Success)
31:384  0:000  SetNvramVariable (MLB, guid, 0x6, 17): -> writing new (Success)
31:384  0:000  SetNvramVariable (ROM, guid, 0x6, 6): -> writing new (Success)
31:384  0:000  SetNvramVariable (FirmwareFeatures, guid, 0x6, 4): -> writing new (Success)
31:385  0:000  AddNvramVariable (FirmwareFeaturesMask, guid, 0x6, 4): -> writing new (Success)
31:385  0:000  AddNvramVariable (HW_BID, guid, 0x6, 20): -> writing new (Success)
31:385  0:000  SetNvramVariable (prev-lang:kbd, guid, 0x6, 7): -> writing new (Success)
31:386  0:000  AddNvramVariable (security-mode, guid, 0x6, 5): -> writing new (Success)
31:386  0:000  AddNvramVariable (backlight-level, guid, 0x6, 2): -> writing new (Success)
31:386  0:000  DeleteNvramVariable (DefaultBackgroundColor, guid = Not Found):
31:386  0:000  SetNvramVariable (UIScale, guid, 0x6, 1): exists(0x7, 1)DeleteNvramVariable (UIScale, guid = Success):
31:388  0:000  SetNvramVariable (EFILoginHiDPI, guid, 0x6, 4): -> writing new (Success)
31:388  0:000  SetNvramVariable (flagstate, guid, 0x6, 32): -> writing new (Success)
31:388  0:000  SetNvramVariable (csr-active-config, guid, 0x6, 4): -> writing new (Success)
31:389  0:000  DeleteNvramVariable (bootercfg, guid = Not Found):
31:389  0:000  DeleteNvramVariable (nvda_drv, guid = Not Found):
31:389  0:000  DeleteNvramVariable (recovery-boot-mode, guid = Not Found):
31:389  0:000  AddNvramVariable (wake-failure, guid, 0x6, 5): -> writing new (Success)
31:390  0:000  SetNvramVariable (efi-boot-device-data, guid, 0x7, 110): -> writing new (Success)
31:392  0:000  SetNvramVariable (efi-boot-device, guid, 0x7, 216): -> writing new (Success)
31:395  0:000  DeleteNvramVariable (IOHibernateRTCVariables, guid = Not Found):
31:395  0:000  DeleteNvramVariable (boot-image, guid = Not Found):

Looks pretty much like working NVRAM to me. But lets try nvram -p as well (excerpt):

security-mode	none
prev-lang:kbd	en-US:0
SystemAudioVolumeDB	%f4
EFILoginHiDPI	%01%00%00%00
backlight-level	%ff%ff
csr-active-config	%ff%07%00%00
SystemAudioVolume	G

If NVRAM wasn't working none of these variables could have been created.

  • Haha 1

I added SMCLightSensor.kext (which i don't need in OpenCore) and then it worked.

 

@Hervé You know, I took a lot of time and effort here to write Guides that other helped other people to successfully update to the new Clover and save their you know what. This guide along with my OpenCore Update gude alone have about 50.000 hits. These are probably the best and most on-point update guides in the whole realm of hackintoshing. I spent a lot of time developing the workflow and explainations.

 

I'v build my Laptop and PC EFIs from scratch with all SSDTs, no patched DSDT and learnt aml basics along the way and on top of that created repos and translated daliansky's OC Little repo from chines into english along the way…

 

I think I deserve better than being treated like a noob! On that note, I am glad I fixed it…

 

 


 Share

×
×
  • Create New...