Ok, I thought you mentioned ignoring the 0 backlight value to prevent black screen at boot.
I can't do it since it would break a legit reason to turn the backlight to zero.
Suppose I did that logic:
Code:
if(saved_backlight==0)
startup_backlight=some_default; // half max?
Then if the saved backlight level is zero, it won't use it.
But if the user connects an external monitor, turns their laptop backlight to zero (because they wan't it black while using external), shuts down, then restarts, the backlight on the laptop will turn on instead of restoring to black as probably desired.
And I'm not sure I want to get into trying to determine if there is an external monitor connected... maybe I'll try and see if I can come up with a reliable method. eg:
Code:
if(saved_backlight==0 && external_display_is_connected())
startup_backlight=some_default; // half max?
What is the use of XOPT=2?
Formerly it was one kernel object... just ACPIBacklight that attached to PNLF. Now there are two independent objects, ACPIBacklight which is still attached to PNLF, but also a new object IntelBacklightHandler (if you look at ioreg, you'll see it). IntelBacklightHandler calls into ACPIBacklight to indicate it would like to handle the details of setting the backlight. That is easy, it just does a waitForService("ACPIBacklight"), then calls into ACPIBacklight's setBacklightHandler method.
But when ACPIBacklight starts it must set the backlight early in the boot process to set the backlight level to the value saved in NVRAM. When ACPIBacklight starts, IntelBacklightHandler may not have started yet, and therefore may not have called setBacklightHandler. The order of different objects starting is not specified by IOKit. So, XOPT with bit1 set, tells ACPIBacklight to wait until IntelBacklightHandler is ready before trying to restore the backlight.
So startup sequence is:
- ACPIBacklight and IntelBacklightHandler start in some indeterminate sequence
- IntelBacklightHandler waits for ACPIBacklight to be ready before calling setBacklightHandler (IntelBacklightHandler's call to waitForService is satisfied by ACPIBacklight's call to registerService).
- ACPIBacklight calls registerService prior to waiting for IntelBacklightHandler
- IntelBacklightHandler calls setBacklightHandler, so ACPIBacklight knows where to satisfy requests to change the backlight
- ACPIBacklight now waits for IntelBacklightHandler before doing any backlight setting/getting (ACPIBacklight's call to waitForService is satisfied by IntelBacklightHandler's call to registerService)
Now, you don't want ACPIBacklight waiting for a backlight handler in the case none will arrive, such as would be the case with a pure ACPI setup (eg. using "Backlight Fix (ACPI 100)" or native OEM ACPI backlight calls). So we need a way to force the synchronization only for the Intel case.
I still haven't visited all the patches (eg. the ProBook versions).
Nothing bad happens if you don't specify XOPT=2. All that happens is the first few calls to change the backlight don't work (because the are going through ACPI, which don't work on 10.11), so the transition at startup is not quite as smooth at the beginning (it is actually hard to notice, but may depend on timing). Although, if you were to turn off smooth transitions, the startup backlight setting would be missed entirely.
EDIT: Off topic, but I think you should remove CFBundleExecutable in Backlight injector, because I see the errors mentioning Exectuable not found for the injector kext.
Will do.
Side Note: When I have the time, I'll create a new IntelBacklight.kext that attempts to strip all ACPI dependencies from ACPIBacklight.kext.
