Apple Backlight Injector Brightness not saved

[RehabMan]

Hi!

I have an XPS 15 with the same behavior. RC install scripts is used, native AppleBacklight kexts are loaded, and even the Nvidia web driver retains its setting on reboots (which also uses NVRAM, right?). It might have something to do with the Dell UEFI setting brightness when the laptop boots depending on whether or not the AC adapter is plugged in.

Btw, thanks for all the laptop info you've written up, RehabMan! It's been super-duper helpful in learning how to make a laptop work with OS X.

Read FAQ, "Problem Reporting"
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/

 

[RehabMan]

I will try to debug clover. And test both lg and dell laptop

At least you can reproduce the problem. That puts you in a better position to solve it...
But I would check your backlight implementation. It is very easy to make a mistake.

 

[KNNSpeed]

Oh, sorry, I'm not reporting a problem yet! I want to see if I can fix it first--I was mainly suggesting it might have to do with the Dell UEFI's having a baked-in brightness setting.

 

[RehabMan]

Oh, sorry, I'm not reporting a problem yet! I want to see if I can fix it first--I was mainly suggesting it might have to do with the Dell UEFI's having a baked-in brightness setting.

Unfortunately, no sense in pursuing a fix until we verify that your backlight control is implemented correctly.
Please attach "Problem Reporting" files.

 

[KNNSpeed]

Here you go.
Note: Currently my build is neither pretty nor totally done yet. Still got USB, HDMI, Type-C and some other stuff to do, although I suppose none of that really matters for this issue.

 

[RehabMan]

Here you go.
Note: Currently my build is neither pretty nor totally done yet. Still got USB, HDMI, Type-C and some other stuff to do, although I suppose none of that really matters for this issue.

Backlight implementation looks fine.
Current backlight-level is 0x016d (both in NVRAM and ApplePanelRawBrightness).
That is the value, if you rebooted in this state, you should expect to find in nvram.plist and loaded in the Clover bootlog.
Last loaded value from NVRAM is 0x0x01d5 (I can't remember if that is on a different scale 0-0x400? or in the same scale as ApplePanelRawBrightness... certain that is something to check).

 

[KNNSpeed]

Well, I just rebooted having set the brightness to ~50%, and it came back at 100%. From where did you get those values? Since I uploaded those files the NVRAM value has been 0x1701 and 0x1e01 (converting the base64 number from nvram.plist to hex, and it seems to change between reboots. Though, this makes sense since I've been changing the brightness).

 

[RehabMan]

Well, I just rebooted having set the brightness to ~50%, and it came back at 100%. From where did you get those values? Since I uploaded those files the NVRAM value has been 0x1701 and 0x1e01 (converting the base64 number from nvram.plist to hex, and it seems to change between reboots. Though, this makes sense since I've been changing the brightness).

ApplePanelRawBrightness is under PNLF. It is the current brightness level of the backlight. It is set by AppleBacklight. It usually matches one of the values in PNLF.AppleIntelPanelA.ApplePanel.FxxTxxxx (eg. one of the major values in the backlight level array).

Then there is the current NVRAM contents. This is at AppleEFIRuntime.AppleEFINVRAM.backlight-level. This generally should be in sync with ApplePanelRawBrightness.

In theory, that backlight-level is the value that ends up in nvram.plist (on EFI partition) when you shutdown or restart. Clover then loads that value at boot time and injects it... you will see this action in your Clover bootlog. Those same NVRAM values should be injected by Clover.

Note there is some trickery in the Clover code:

  // Download-Fritz: Do not mess with BacklightLevel; it's OS X's business
  if (gMobile) {
    if (gSettings.BacklightLevelConfig) {
      SetNvramVariable(L"backlight-level", &gEfiAppleBootGuid, Attributes, sizeof(gSettings.BacklightLevel), &gSettings.BacklightLevel);
    } else {
      AddNvramVariable(L"backlight-level", &gEfiAppleBootGuid, Attributes, sizeof(gSettings.BacklightLevel), &gSettings.BacklightLevel);
    }
  }

Note that it depends on gMobile... so you better make sure your SMBIOS data is correct.

And you want to make sure gSettings.BacklightLevelConfig is zero.
Yours is not set, so if you make the mistake of going into Clover options it will be 0xFFFF and this code will run... (unless you set it to zero).

Well, I just rebooted having set the brightness to ~50%, and it came back at 100%. From where did you get those values? Since I uploaded those files the NVRAM value has been 0x1701 and 0x1e01 (converting the base64 number from nvram.plist to hex, and it seems to change between reboots. Though, this makes sense since I've been changing the brightness).

Maybe you mean 0x0117 and 0x011e, because 0x1701 and 0x1e01 are out of range for your hardware (valid backlight levels for your system are 0-0x56c).

 

[KNNSpeed]

BacklightLevel set to 0 in config.plist, and SMBIOS compared directly against the clover source code. As far as I can tell, gMobile will absolutely be set true with my settings. I did notice I was behind by one Apple BIOS update, though.

Result: It seems to be saving a backlight level, but's it's definitely not the last level I was using. How long does it take for clover to write to the NVRAM?

I have noticed that Clover r4077 feels much more sluggish/less responsive than r4061, if that might be some indication of something.

Maybe you mean 0x0117 and 0x011e, because 0x1701 and 0x1e01 are out of range for your hardware (valid backlight levels for your system are 0-0x56c).

Yeah, whoops. Endianness trips me up.

EDIT: It seems PNLF (ApplePanelRawBrightness) has a pretty hefty write delay. Any way to speed it up?
I have to use an SSDT to intercept ACPI brightness keys, so would adding Notify (PNLF, [some hex value goes here]) to the intercepting SSDT be sufficient to get to update in realtime?

RawPanelBrightness = 0x3fb, NVRAM backlight-level = LwU= (= 0x52f)
At first glance, that's not what I'd call in-sync, unless there's some funky mapping going on here... Which @RehabMan you mentioned there may very well be. If that's the case, and if 0x400 maps to 0x56C, I guess that'd mean they're spot on. Nice!

EDIT 2: Spoke too soon. After changing the brightness and waiting for about a minute, RawPanelBrightness is at 0x3f, but NVRAM is still way too high at LwU=. My brightness setting is at ~25%. Definitely not in-sync. In fact, it seems the NVRAM parameters only feel like updating some of the time, particularly when brightness is more towards max.

EDIT 3: Well this is odd: NVRAM is actually saving the values as it's supposed to; I'm just being dumb. What's happening is it saves the value correctly (after RawPanelBrightness takes a little bit to update), and it may even be loading it on reboot, but at some point either macOS or the laptop is like "nope!" and applies a brightness setting on top of that. Question is, where might this setting be coming from? I think the answer might be the BIOS............ (The brightness level that keeps overriding the saved NVRAM value is ~75%, which is what I set the "AC Power" brightness setting to in the BIOS. Granted, this setting seems to occur on battery, too.)

 

[RehabMan]

Result: It seems to be saving a backlight level, but's it's definitely not the last level I was using. How long does it take for clover to write to the NVRAM?

nvram.plist is updated on shutdown/restart when the rc scripts run.
You should not expect nvram.plist to be constantly updated with current nvram values...

EDIT: It seems PNLF (ApplePanelRawBrightness) has a pretty hefty write delay. Any way to speed it up?
I have to use an SSDT to intercept ACPI brightness keys, so would adding Notify (PNLF, [some hex value goes here]) to the intercepting SSDT be sufficient to get to update in realtime?

I'm not sure what you're referring to, but even the mechanism that IntelBacklight.kext uses to write NVRAM values suffers from a delay. Which means you need to give it time before restart or you'll miss the latest change. I'm not sure if AppleBacklight.kext uses the same mechanism or if it has the same delay.

RawPanelBrightness = 0x3fb, NVRAM backlight-level = LwU= (= 0x52f)
At first glance, that's not what I'd call in-sync, unless there's some funky mapping going on here... Which @RehabMan you mentioned there may very well be. If that's the case, and if 0x400 maps to 0x56C, I guess that'd mean they're spot on. Nice!

From my experience with IntelBacklight.kext (and ACPIBacklight.kext), the system sends brightness levels 0-0x400 (linear) which are then mapped to actual brightness levels for the PWM controls (non-linear).

EDIT 3: Well this is odd: NVRAM is actually saving the values as it's supposed to; I'm just being dumb. What's happening is it saves the value correctly (after RawPanelBrightness takes a little bit to update), and it may even be loading it on reboot, but at some point either macOS or the laptop is like "nope!" and applies a brightness setting on top of that. Question is, where might this setting be coming from? I think the answer might be the BIOS............ (The brightness level that keeps overriding the saved NVRAM value is ~75%, which is what I set the "AC Power" brightness setting to in the BIOS.

If you can correlate this directly with the BIOS setting, then you're on to something...
Please continue to dig/verify.