DDDDDDDDDDDDDDDDDD
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.)