Contribute
Register

Apple Backlight Injector Brightness not saved

Status
Not open for further replies.
Haven't tried anything fancy yet, but this is logged in bdmesg:
Code:
0:713  0:000   Adding Key: backlight-level: Size = 2, Data: 6C 05

That is 0x056c (max brightness) as read from nvram.plist by Clover.
Don't expect kext kernel logs from bdmesg.
 
: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.)
 

Attachments

  • Screen Shot 2017-05-29 at 1.50.57 AM.png
    Screen Shot 2017-05-29 at 1.50.57 AM.png
    856.6 KB · Views: 491
  • kext and SSDT.zip
    37.6 KB · Views: 297
Last edited:
: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.)

I think I would just disable the ALS by patching _STA to return zero.
(note: could be easily done with hotpatch)

I will add a note to the brightness guide... (DONE).
 
Last edited:
Actually, I think it already was returning zero. It wasn't in IOReg at all without making a whole SSDT for it.
 
Actually, I think it already was returning zero. It wasn't in IOReg at all without making a whole SSDT for it.

If it was returning zero, it would have no effect.
 
Incorrect. If it's a hardware device that has direct control over the display and doesn't need software intervention, it will be able to interfere as long as the software doesn't know about it. And before you say "No," yes, these devices do exist: I make them. Your car's AC is an example of an everyday device that needs basically no OS oversight.

Further, to disprove your statement, I just made this SSDT:
Code:
DefinitionBlock ("", "SSDT", 2, "hack", "ALS0", 0x00000000)
{
    External (LHIH, UnknownObj)    // (from opcode)
    External (LLOW, UnknownObj)    // (from opcode)

    Device (ALS0)
    {
        Name (_HID, "ACPI0008")  // _HID: Hardware ID
        Name (_CID, "smc-als")  // _CID: Compatible ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            Return (Zero)
        }
    }
}
It doesn't work.

The only thing that does work is this SSDT, paired with the FakeSMC mod (you do, in fact, require both):
Code:
DefinitionBlock ("", "SSDT", 2, "hack", "ALS0", 0x00000000)
{
    External (LHIH, UnknownObj)    // (from opcode)
    External (LLOW, UnknownObj)    // (from opcode)

    Device (ALS0)
    {
        Name (_HID, "ACPI0008")  // _HID: Hardware ID
        Name (_CID, "smc-als")  // _CID: Compatible ID
        Method (_ALI, 0, NotSerialized)  // _ALI: Ambient Light Illuminance
        {
            Return (Or (ShiftLeft (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
            }
        })
    }
}
So that way the system knows there's something there and can deal with it.
(Note: this SSDT differs slightly in the ACPI tree placement of the sensor than the previous one I uploaded. It doesn't seem to matter which one is used--Apple puts ALS0 on LPCB, but Dell puts it on the root.)
 
Incorrect. If it's a hardware device that has direct control over the display and doesn't need software intervention, it will be able to interfere as long as the software doesn't know about it. And before you say "No," yes, these devices do exist: I make them. Your car's AC is an example of an everyday device that needs basically no OS oversight.

Perhaps you should provide "Problem Reporting" files with _STA disabled that prove your assertion.

Further, to disprove your statement, I just made this SSDT:
Code:
DefinitionBlock ("", "SSDT", 2, "hack", "ALS0", 0x00000000)
{
    External (LHIH, UnknownObj)    // (from opcode)
    External (LLOW, UnknownObj)    // (from opcode)

    Device (ALS0)
    {
        Name (_HID, "ACPI0008")  // _HID: Hardware ID
        Name (_CID, "smc-als")  // _CID: Compatible ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            Return (Zero)
        }
    }
}
It doesn't work.

Not surprising. Your technique is wrong, guaranteed to fail.

You cannot redefine ALS0 as it is already defined in DSDT.
Your SSDT will simply be ignored.
To hotpatch this, you must rename _STA within the existing ALS0 device (using config.plist/ACPI/DSDT/Patches), then provide an SSDT that injects a new _STA into ALS0 scope.
 
Except ALS0 is NOT already defined in the DSDT. It's called ALSD.

To put it plainly, if ALS0 does not show up in IOReg with AppleLMUController, brightness reloading will not work. Period.
These images are pulled directly from my system running right now. My next post will have images pulled from the system with it working.
 

Attachments

  • Screen Shot 2017-05-29 at 12.10.16 PM.png
    Screen Shot 2017-05-29 at 12.10.16 PM.png
    882.6 KB · Views: 317
  • Screen Shot 2017-05-29 at 12.10.57 PM.png
    Screen Shot 2017-05-29 at 12.10.57 PM.png
    829.9 KB · Views: 289
Last edited:
Except ALS0 is NOT already defined in the DSDT. It's called ALSD.

Then you must override ALSD.
If you post your full "Problem Reporting" files I will give you a config.plist patch and SSDT to test.

I'm looking for not just "something that works", but rather the simplest solution possible.
 
Last edited:
Then you must override ALSD.
If you post your full "Problem Reporting" files I will give you a config.plist patch and SSDT to test.

I'm looking for not just "something that works", but rather the simplest solution possible.
Same. Here you go.
I'm not sure how to check ALSE to be 100% sure it's returning 0x02 or not. It looks like it's returning 0, because it only shows up in IOReg if _STA is removed....

EDIT Or maybe set to 0xB...? I've found that in many instances Apple doesn't care about the 4-letter name of the ACPI device variable itself, e.g. it doesn't care if the Power button is PWRB or PBTN--just the PNP/ACPI identifier (like a Windows driver, which for ambient light sensors are ACPI0008) and possibly the _CID (if applicable). I'm pretty sure it also doesn't care if COPR --> MATH, among some other renames.
 

Attachments

  • Brightness Configurations [Problem Reporting Files].zip
    11.6 MB · Views: 240
Last edited:
Status
Not open for further replies.
Back
Top