Contribute
Register

Apple Backlight Injector Brightness not saved

Status
Not open for further replies.
KNNSpeed said:
:DDDDDDDDDDDDDDDDDDD

Fixed it.

I found this thing in the DSDT:
Code: 
    Device (ALSD)
    {
        Name (_HID, "ACPI0008")  // _HID: Hardware ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If ((ALSE == 0x02))
            {
                Return (0x0B)
            }

            Return (Zero)
        }

        Method (_ALI, 0, NotSerialized)  // _ALI: Ambient Light Illuminance
        {
            Return (((LHIH << 0x08) | LLOW))
        }

        Name (_ALR, Package (0x05)  // _ALR: Ambient Light Response
        {
            Package (0x02)
            {
                0x46,
                Zero
            },

            Package (0x02)
            {
                0x49,
                0x0A
            },

            Package (0x02)
            {
                0x55,
                0x50
            },

            Package (0x02)
            {
                0x64,
                0x012C
            },

            Package (0x02)
            {
                0x96,
                0x03E8
            }
        })
    }
It's actually a top-level device, too--not on LPCB or anything.

Here we can see that ALSE--Ambient Light Sensor Enable, most likely--is read from hardware (it's defined in a memory region in my laptop's SaSsdt), but this ALSD sensor, which I think is actually some funky Dell content-based adaptive brightness thing, does not seem to work under macOS. My curiosity as to why this device was defined led to faking it on LPCB as the MacBook Air's ALS0 device, because apparently Airs have dedicated light sensors and Pros don't (???).

Anyways, I had to mod FakeSMC (attached) and use the attached SSDT to get AppleLMUController to load, and the ioreg image is the result. Brightness now gets reloaded correctly. Well, more like Dell's BIOS loads its setting, then during boot the NVRAM.plist setting is applied over top.

If someone else could please try using this kext (it's the latest downloadable version of RehabMan's FakeSMC repo with additions from here) plus corresponding SSDT on a Dell exhibiting the same problem, that would be great. I need to make sure I'm not just going crazy. (I also want to try a couple more things, but at the very least it would be nice to have confirmation that the ALS is the common cause.)
Click to expand...

Based on this..., although I can't reproduce the problem on my systems, I wanted to see if there was a way to make a generic ALS, and if FakeSMC.kext with those extra keys was a problem on other computers...

So I added the keys... this is the diff (it was a little unclear which keys you were adding, but this is what I gathered by reading between the lines):

Code: 
SPEEDY-NUC:kozlek.git rehabman$ git diff
diff --git a/FakeSMC/FakeSMC-Info.plist b/FakeSMC/FakeSMC-Info.plist
index 3ebd61cd..8d2bf9e8 100755
--- a/FakeSMC/FakeSMC-Info.plist
+++ b/FakeSMC/FakeSMC-Info.plist
@@ -151,6 +151,31 @@
                                                <string>si8</string>
                                                <data>BQ==</data>
                                        </array>
+                                       <key>RMde</key>
+                                       <array>
+                                               <string>char</string>
+                                               <data>QQ==</data>
+                                       </array>
+                                       <key>ALV0</key>
+                                       <array>
+                                               <string>{alv</string>
+                                               <data>ARAGdQEgALYO4A==</data>
+                                       </array>
+                                       <key>ALRV</key>
+                                       <array>
+                                               <string>ui16</string>
+                                               <data>AAE=</data>
+                                       </array>
+                                       <key>ALI0</key>
+                                       <array>
+                                               <string>{ali</string>
+                                               <data>BwECAA==</data>
+                                       </array>
+                                       <key>MSLD</key>
+                                       <array>
+                                               <string>ui8 </string>
+                                               <data>AA==</data>
+                                       </array>
                                </dict>
                                <key>Types</key>
                                <dict>

The FakeSMC.kext with this change is attached.
I didn't have any issue with the updated FakeSMC.kext (without SSDT-ALS0.aml) on a desktop, nor any of my laptops.

So..., then I move on to enabling a Fake ALS that is generic...

I did a little reading on ALS in the ACPI spec... and decided to create a minimal SSDT-ALS0.dsl to serve as a generic, never changing, fake ALS:
Code: 
// Fake ambient light sensor device
DefinitionBlock("", "SSDT", 2, "hack", "ALS0", 0)
{
    Device(_SB.ALS0)
    {
        Name(_HID, "ACPI0008")
        Name(_CID, "smc-als")
        Name(_ALI, 300)
        Name(_ALR, Package()
        {
            //Package() { 70, 0 },
            //Package() { 73, 10 },
            //Package() { 85, 80 },
            Package() { 100, 300 },
            //Package() { 150, 1000 },
        })
    }
}
//EOF

As you can see, the version above always returns 300 for the _ALI and only has one mapping in _ALR: a neutral mapping (100) for 300 lux)
I actually tested both ways with the other items in the list, and without...
Both same result...
This does get me the "Automatically adjust brightness" checkbox in SysPrefs->Displays, so maybe it is also adequate to fix the brightness restore (and relies on no specifics of any particular native ACPI).

The pre-built SSDT-ALS0.aml is also attached.

Please test.
 

Attachments

  • FakeSMC.kext.zip
    33.7 KB · Views: 486
  • SSDT-ALS0.aml
    101 bytes · Views: 948
Last edited:
@RehabMan : I have tested your solution with the FakeSMC.kext and SSDT and the Brightnes is saved after every reboot. Thank you for this.
 
RehabMan said:
Based on this..., although I can't reproduce the problem on my systems, I wanted to see if there was a way to make a generic ALS, and if FakeSMC.kext with those extra keys was a problem on other computers...

So I added the keys... this is the diff (it was a little unclear which keys you were adding, but this is what I gathered by reading between the lines):

Code: 
SPEEDY-NUC:kozlek.git rehabman$ git diff
diff --git a/FakeSMC/FakeSMC-Info.plist b/FakeSMC/FakeSMC-Info.plist
index 3ebd61cd..8d2bf9e8 100755
--- a/FakeSMC/FakeSMC-Info.plist
+++ b/FakeSMC/FakeSMC-Info.plist
@@ -151,6 +151,31 @@
                                                <string>si8</string>
                                                <data>BQ==</data>
                                        </array>
+                                       <key>RMde</key>
+                                       <array>
+                                               <string>char</string>
+                                               <data>QQ==</data>
+                                       </array>
+                                       <key>ALV0</key>
+                                       <array>
+                                               <string>{alv</string>
+                                               <data>ARAGdQEgALYO4A==</data>
+                                       </array>
+                                       <key>ALRV</key>
+                                       <array>
+                                               <string>ui16</string>
+                                               <data>AAE=</data>
+                                       </array>
+                                       <key>ALI0</key>
+                                       <array>
+                                               <string>{ali</string>
+                                               <data>BwECAA==</data>
+                                       </array>
+                                       <key>MSLD</key>
+                                       <array>
+                                               <string>ui8 </string>
+                                               <data>AA==</data>
+                                       </array>
                                </dict>
                                <key>Types</key>
                                <dict>

The FakeSMC.kext with this change is attached.
I didn't have any issue with the updated FakeSMC.kext (without SSDT-ALS0.aml) on a desktop, nor one one of my laptops.

So..., then I move on to enabling a Fake ALS that is generic...

I did a little reading on ALS in the ACPI spec... and decided to create a minimal SSDT-ALS0.dsl to serve as a generic, never changing, fake ALS:
Code: 
// Fake ambient light sensor device
DefinitionBlock("", "SSDT", 2, "hack", "ALS0", 0)
{
    Device(_SB.ALS0)
    {
        Name(_HID, "ACPI0008")
        Name(_CID, "smc-als")
        Name(_ALI, 300)
        Name(_ALR, Package()
        {
            //Package() { 70, 0 },
            //Package() { 73, 10 },
            //Package() { 85, 80 },
            Package() { 100, 300 },
            //Package() { 150, 1000 },
        })
    }
}
//EOF

As you can see, the version above always returns 300 for the _ALI and only has one mapping in _ALR: a neutral mapping (100) for 300 lux)
I actually tested both ways with the other items in the list, and without...
Both same result...
This does get me the "Automatically adjust brightness" checkbox in SysPrefs->Displays, so maybe it is also adequate to fix the brightness restore (and relies on no specifics of any particular native ACPI).

The pre-built SSDT-ALS0.aml is also attached.

Please test.
Click to expand...

This does get me the "Automatically adjust brightness" checkbox in SysPrefs->Displays, so maybe it is also adequate to fix the brightness restore (and relies on no specifics of any particular native ACPI).
---> yes, i saw this check box in SysPrefs->Displays. actually not work

anyway brightness save is good working. thank you
 
sherlocks said:
---> yes, i saw this check box in SysPrefs->Displays. actually not work
Click to expand...

Yes... Not expected to work (it is fake). The ALS implementation always returns 300 for _ALI.
 
i confirmed one.

slice's fakesmc r43 has 5 keys as default. just need to add ALS0.aml.

r40 doesn't have 5 keys
 
sherlocks said:
i confirmed one.

slice's fakesmc r43 has 5 keys as default. just need to add ALS0.aml.

r40 doesn't have 5 keys
Click to expand...

I will test on as many computers here before I release a new FakeSMC on github/bitbucket.
I'm just careful that way...

But yeah, so far, the extra keys don't seem to cause any problem.
 
RehabMan said:
I will test on as many computers here before I release a new FakeSMC on github/bitbucket.
I'm just careful that way...

But yeah, so far, the extra keys don't seem to cause any problem.
Click to expand...

yes. i just saw difference of max brightness from my eyes. if use ALS0 on my LG laptop, max brightness is lower than not use ALS0. i think actually 2 steps(?). just when I saw the panel myself

it's same setting(0x056c, shown same brightness in ioreg) both Dell and LG. PNLF+Brightnessinjector.kext+Your Panel patch.

so, i disabled ALS0 on LG laptop
 
RehabMan said:
Actually, just checked... and the MacBookAir6,2 does have an ALS...
It is hidden within the camera.

So, really the question comes in why are some computers affected by this issue and not others...
(I have no issue on my Lenovo u430 that does not have ALS, but is using MacBookAir6,2).

Without the fake ALS, do you have the checkbox for "automatically adjust brightness" in SysPrefs->Displays?
Click to expand...
Only shows up with ALS.

Also, using the setting "Slightly dim the display while on battery power" setting causes the brightness to reload with a maximum of 50%. In other words, if you restart on AC power at a certain brightness >50%, that will stick. However, on battery power, it will get reset to 50% (settings less than 50% will persist, however). Disabling this setting in "Energy Saver" causes the battery brightness to behave just like AC power brightness. I'm fairly confident that this is how it is supposed to work normally. :)
 
KNNSpeed said:
Only shows up with ALS.
Click to expand...

That's what I figured...

Also, using the setting "Slightly dim the display while on battery power" setting causes the brightness to reload with a maximum of 50%. In other words, if you restart on AC power at a certain brightness >50%, that will stick. However, on battery power, it will get reset to 50% (settings less than 50% will persist, however). Disabling this setting in "Energy Saver" causes the battery brightness to behave just like AC power brightness. I'm fairly confident that this is how it is supposed to work normally. :)
Click to expand...

I will check on my Apple MacBookAir6,2 later today.
I think it is probably designed that way.
 
I just found something weird: Brightness is also only saved, given my suggestions, if "automatically adjust brightness" is enabled. (At least on battery.) The "half-brightness" thing I mentioned also only works if this same setting is enabled.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top