ACPI Backlight Driver

[Joni_78]

Is that using ACPIBacklight.kext or the native Apple kext?

 With the native Apple kext.

 

ACPIBacklight prior to my version did not save the state of the backlight across reboots (unless you're able to figure out how to write a SAVE method that writes to your native nvram). My version writes/restores the backlight level using OS X "fake NVRAM". The additional DSDT patches allow you to access the entire range of brightness (and control individual levels), allow smooth transitions between brightness levels, and fix problems where the backlight doesn't work prior to display sleep/wake.

 

If you're happy with the way the native Apple backlight driver works, you can just use it. Backlight levels will be restored, provided you force a sleep/wake cycle on your display (use 'blinkscreen' from the ProBook Installer) and you have some solution to nvram in play (eg. FileNVRAM for Chameleon, or using the RC scripts in Clover).

I wouldn't mind if the backlight state wouldn't be restored after reboot as I would only use the default brightness settings. Because the default brightness level is the only issue with native kext I wouldn't mind keeping this as much untouched as possible, if that makes any sense. But is that something that can be fixed with DSDT?

[RehabMan]

With the native Apple kext.

 

I wouldn't mind if the backlight state wouldn't be restored after reboot as I would only use the default brightness settings. Because the default brightness level is the only issue with native kext I wouldn't mind keeping this as much untouched as possible, if that makes any sense. But is that something that can be fixed with DSDT?

Use 'blinkscreen' then.

[RehabMan]

With the native Apple kext.

 

I wouldn't mind if the backlight state wouldn't be restored after reboot as I would only use the default brightness settings. Because the default brightness level is the only issue with native kext I wouldn't mind keeping this as much untouched as possible, if that makes any sense. But is that something that can be fixed with DSDT?

FYI: I just came up with a fix for brightness levels prior to display sleep using the native AppleBacklight.kext. For now I have the DSDT patches required just in the ProBook Patches (later maybe I'll add these to my generic laptop repo).

 

See: https://github.com/RehabMan/HP-ProBook-4x30s-DSDT-Patch (13_Brightness.txt).

[Joni_78]

Use 'blinkscreen' then.

 

I Tried 'Blinkscreen' and 'Brightness' fixes from Probook Installer but both were quite 'ugly' solutions. I found near perfect solution however. The kext in use are these:

AppleBacklight.kext (Native)
AppleBacklightExpert.kext (Native)
ACPIBatteryManager.kext (RehabMan)

Brightness is correct when booting so there is no low backlight like usually just before login screen. Brightness changes correctly when unplugging AC. When going to sleep and back, there is correct backlight, also if I go to sleep with AC and backlight 100%, then return with battery, backlight is reduced when desktop becomes visible. Only thing that doesn't work is restart, backlight is always 100%. I haven't used 13_Brightness.txt patch.

 

This was when using Clover setting backlight 100%. Dunno if this is possible but maybe restart would also work if Clover could detect wether you are booting with AC or not and you could specify two values for backlight. Also would it be possible to compile special version of ACPIBatteryManager.kext that would save the backlight value to fake NVRAM?

 

BTW, on my laptop, native Apple Backlight kext only works with your ACPIBatteryManager.

[RehabMan]

I Tried 'Blinkscreen' and 'Brightness' fixes from Probook Installer but both were quite 'ugly' solutions. I found near perfect solution however. The kext in use are these:

AppleBacklight.kext (Native)
AppleBacklightExpert.kext (Native)
ACPIBatteryManager.kext (RehabMan)

Brightness is correct when booting so there is no low backlight like usually just before login screen. Brightness changes correctly when unplugging AC. When going to sleep and back, there is correct backlight, also if I go to sleep with AC and backlight 100%, then return with battery, backlight is reduced when desktop becomes visible. Only thing that doesn't work is restart, backlight is always 100%. I haven't used 13_Brightness.txt patch.

 

This was when using Clover setting backlight 100%. Dunno if this is possible but maybe restart would also work if Clover could detect wether you are booting with AC or not and you could specify two values for backlight. Also would it be possible to compile special version of ACPIBatteryManager.kext that would save the backlight value to fake NVRAM?

 

BTW, on my laptop, native Apple Backlight kext only works with your ACPIBatteryManager.

 

You might want to look at the link in post #128.

 

ACPIBatteryManager has nothing to do with backlight... only battery status.

 

The correct goal is to have backlight restored to its previous value. Possible using my ACPIBacklight.kext or using native AppleBacklight.kext, provided your 'emulated nvram' is working (need EmuVariable + RC scripts in Clover) and provided you don't have Clover set to set brightness to something else.

 

Blink screen is a work around to make the OS X video driver initialize the backlight registers. You can do the DSDT patch mentioned in post #128 to correct that and thus avoid blinkscreen. Patching native AppleBacklight.kext allows you to get the 'curve' (and upper/lower limit) correct for your display without using ACPIBacklight and associated DSDT patches.

 

Do some reading of the links I've already provided and come to your own conclusions about what you like best.

[Joni_78]

You might want to look at the link in post #128.

 

ACPIBatteryManager has nothing to do with backlight... only battery status.

 

The correct goal is to have backlight restored to its previous value. Possible using my ACPIBacklight.kext or using native AppleBacklight.kext, provided your 'emulated nvram' is working (need EmuVariable + RC scripts in Clover) and provided you don't have Clover set to set brightness to something else.

 

Blink screen is a work around to make the OS X video driver initialize the backlight registers. You can do the DSDT patch mentioned in post #128 to correct that and thus avoid blinkscreen. Patching native AppleBacklight.kext allows you to get the 'curve' (and upper/lower limit) correct for your display without using ACPIBacklight and associated DSDT patches.

 

Do some reading of the links I've already provided and come to your own conclusions about what you like best.

 

Thanks, i'll read those. For some reason your ACPIBatteryManager + Battery DSDT makes native backlight kext working on my laptop. If I delete it, backlight doesn't change when I unplug AC for example.

[RehabMan]

Thanks, i'll read those. For some reason your ACPIBatteryManager + Battery DSDT makes native backlight kext working on my laptop. If I delete it, backlight doesn't change when I unplug AC for example.

Well, that's not that the backlight controls aren't working.. and not that the battery manager is fixing your backlight controls. It is that having working battery status allows the system to detect transitions to/from battery/ac power.

[Joni_78]

Well, that's not that the backlight controls aren't working.. and not that the battery manager is fixing your backlight controls. It is that having working battery status allows the system to detect transitions to/from battery/ac power.

lol, I didn't think of it

 

About your native backlight fix, is it just for HD3000/HD4000 and is the backlight slider working natively in it?

 

I have AMD 7570M, slider works natively, also the hotkeys and sleep. The problem with it is that the slider is on about 60% on default and has to be moved to 100% in every boot (unless using some fix like clover, or blinkscreen). Also if I would fix the NVRAM issue, 

 

I was wondering if it is possible to use similar fix with 7570M and can it be done with DSDT alone as it seems that the native kext works fine without patching?

[RehabMan]

lol, I didn't think of it

 

About your native backlight fix, is it just for HD3000/HD4000 and is the backlight slider working natively in it?

Yes, and Yes. Note: It would also work with Haswell provided the laptop is not using eDP (most Haswell laptops seem to use eDP). So far I haven't found where the hardware controls are for Haswell eDP (I believe somewhere in PCH SystemIO).

 

I have AMD 7570M, slider works natively, also the hotkeys and sleep. The problem with it is that the slider is on about 60% on default and has to be moved to 100% in every boot (unless using some fix like clover, or blinkscreen). Also if I would fix the NVRAM issue, 

 

I was wondering if it is possible to use similar fix with 7570M and can it be done with DSDT alone as it seems that the native kext works fine without patching?

If the slider is actually moving, then probably your nvram is not working. Check with "nvram -p". You can probably use a similar technique to patch the plist for AppleBacklight, but I'm not sure of the range you might be looking for. You'll have to experiment. I don't have any machines with the AMD part.

 

What laptop is this that you have Radeon that isn't switched?

[Joni_78]

Yes, and Yes. Note: It would also work with Haswell provided the laptop is not using eDP (most Haswell laptops seem to use eDP). So far I haven't found where the hardware controls are for Haswell eDP (I believe somewhere in PCH SystemIO).

 

 

If the slider is actually moving, then probably your nvram is not working. Check with "nvram -p". You can probably use a similar technique to patch the plist for AppleBacklight, but I'm not sure of the range you might be looking for. You'll have to experiment. I don't have any machines with the AMD part.

 

What laptop is this that you have Radeon that isn't switched?

 

Yes, my NVRAM is not working yet, I wan't to keep Clover on USB stick until I get everything else working properly. Just to see what happens, I tried your kext patcher + dsdt patch earlier today. With native patched kext and DSDT patch (I had to edit it, my GPU is GFX0, also my DSDT does not have any BAR1 values so MaciASL throws an error).

 

With that the slider works also but moving it from left to right for example brightens the backlight then starts to decrease and again increase). Quite erratic, maybe because the wrong or missing BAR1 values.

 

My laptop is EliteBook 8570p, Intel integrated GPU is disabled by HP. This is my DSDT without any graphics related patches + ioreg.

 

DSDT.aml.zip

MacBook Air.zip

[RehabMan]

Yes, my NVRAM is not working yet, I wan't to keep Clover on USB stick until I get everything else working properly. Just to see what happens, I tried your kext patcher + dsdt patch earlier today. With native patched kext and DSDT patch (I had to edit it, my GPU is GFX0, also my DSDT does not have any BAR1 values so MaciASL throws an error).

 

With that the slider works also but moving it from left to right for example brightens the backlight then starts to decrease and again increase). Quite erratic, maybe because the wrong or missing BAR1 values.

 

My laptop is EliteBook 8570p, Intel integrated GPU is disabled by HP. This is my DSDT without any graphics related patches + ioreg.

 

DSDT.aml.zip

Interesting. It could be that your backlight is still connected to the IntelHD. Maybe?

 

If you change all instances of IGPU to GFX0 in the patch (there are three), the patch will apply successfully to your DSDT. The BAR1 value is pretty important. The patch actually adds the definition of BAR1 (it is available as 32-bit SystemMemory at offset 0x10 from PCI_Config for GFX0 device).

 

I could not look at your ioreg, as the file is corrupt.

[Joni_78]

Interesting. It could be that your backlight is still connected to the IntelHD. Maybe?

 

If you change all instances of IGPU to GFX0 in the patch (there are three), the patch will apply successfully to your DSDT. The BAR1 value is pretty important. The patch actually adds the definition of BAR1 (it is available as 32-bit SystemMemory at offset 0x10 from PCI_Config for GFX0 device).

 

I could not look at your ioreg, as the file is corrupt.

 

I just edited your patch IGPU->GFX0 and it applied without errors on my DSDT. Now with the patched Apple kext + patched DSDT, the slider works but behaves just as I described earlier. Dunno really what that behavior means, are the BAR1 values even accessed from DSDT and so is pointless to get correct values with RW Everything, or is it just that the values are wrong and the backlight acts like that because of that.

[RehabMan]

I just edited your patch IGPU->GFX0 and it applied without errors on my DSDT. Now with the patched Apple kext + patched DSDT, the slider works but behaves just as I described earlier. Dunno really what that behavior means, are the BAR1 values even accessed from DSDT and so is pointless to get correct values with RW Everything, or is it just that the values are wrong and the backlight acts like that because of that.

Post your ioreg (using IORegistryExplorer v2.x) if you want me to look at what you have.

 

There is no need to get the BAR1 values from RW-Everything since the DSDT patches get it automatically.

 

Did you patch your AppleBacklight.kext?

 

Note: I'm still not certain your backlight is controlled via IntelHD registers. The only way to find that out would be to use the other DSDT patches (again editing for GFX0/IGPU) and ACPIBacklight.kext. Or you could go into RW-Everything and verify from there.

 

Another note: Your description of the slider behavior getting brighter... then at some point "rolling over" back to lower levels indicates your brightness is controlled not by IntelHD and instead something else. And that something else has a lower "cap" for maximum brightness. Effective brightness is evidently (brightness_level mod cap). In other words, you should probably use different patch data for AppleBacklight.kext (eg. one with smaller overall data values). You could experiment with the slider, while watching in IORegistryExplorer the "RawBrightness" value you see in PNLF/AppleIntelPanelA object (set your ioreg updates to every second and manipulate the slider, while keeping any eye on the current value set and its effects).

[Joni_78]

Post your ioreg (using IORegistryExplorer v2.x) if you want me to look at what you have.

 

There is no need to get the BAR1 values from RW-Everything since the DSDT patches get it automatically.

 

Did you patch your AppleBacklight.kext?

 

Note: I'm still not certain your backlight is controlled via IntelHD registers. The only way to find that out would be to use the other DSDT patches (again editing for GFX0/IGPU) and ACPIBacklight.kext. Or you could go into RW-Everything and verify from there.

 

I'll attach it soon. With patched kext and my old DSDT (without your patch) the backlight had same erratic behavior.

[RehabMan]

I'll attach it soon. With patched kext and my old DSDT (without your patch) the backlight had same erratic behavior.

I suspect your issue is above in "Another note:"

 

Use different brightness data for the patch to AppleBacklight.kext. Or... use ACPIBacklight.kext if your ACPI methods actually work.

[Joni_78]

I used IORegistryExplorer 3.0.2, it also loaded with it. Where do I get 2.x version?

[RehabMan]

I used IORegistryExplorer 3.0.2, it also loaded with it. Where do I get 2.x version?

Use google. But I'm not sure it will do much good. I've already given you your next task...

[Joni_78]

Use google. But I'm not sure it will do much good. I've already given you your next task...

 

Yeah. I'm trying that now.

Edit:

What values do I need? Lowest and highest?

[RehabMan]

Yeah. I'm trying that now.

 

Edit:

What values do I need? Lowest and highest?

Lowest will likely be zero. But yes, you want to find out the valid range. Then provide that data in your Info.plist.

[Joni_78]

Lowest will likely be zero. But yes, you want to find out the valid range. Then provide that data in your Info.plist.

 

Ok, 0x710 is maximum value, after that, it turns black again.

 

I have this in the info.plist (ApplePanels > F10T0258)

00110000 001F0034 004F0071 009B00CF 010E015D 01BB022F 02B90360 0429051E 06440710

[RehabMan]

Ok, 0x710 is maximum value, after that, it turns black again.

 

I have this in the info.plist (ApplePanels > F10T0258)

00110000 001F0034 004F0071 009B00CF 010E015D 01BB022F 02B90360 0429051E 06440710

 

Now you have me confused... What do you mean by after 0x710 it turns black again? How could it go past 0x710 when the highest value in your Info.plist is 0x710?

[Joni_78]

Now you have me confused... What do you mean by after 0x710 it turns black again? How could it go past 0x710 when the highest value in your Info.plist is 0x710?

 

When moving slider the backlight gradually increases from 0% to around 40%, then it goes black, then starts to increase again and then decreases. It does that several times until it arrives at around 99% (0x6f6) then it goes again to almost black (0x703) when I move the slider to 100%, like it would start all over again.

 

I checked the ApplePanel data when native apple kext was loaded and it had this. 

00000740 0AF7FFFE

Edit:

Sorry, my bad it goes to 0x6f6 then turns black at 0x703.

[RehabMan]

I have no idea. When moving slider the backlight gradually increases from around 0 to 40, then it goes black, then starts to increase again and then decreases. It does that several times until it arrives at around 99% (0x710) then it goes again to almost black when I move the slider to 100%, like it would start all over again.

In other words your valid range is somewhere between 0 and 40 (is that 40 decimal or 40 hex?). Your effective brightness as you move it from 0 to 0x710, where 'B' is the brightness level, is (B mod 40) (eg. remainder of B divided by 40).

 

Seems like you want to use different panel data. Data which increases from 0 to 40. Also, you should verify the same result before and after display sleep.

 

I checked the ApplePanel data when native apple kext was loaded and it had this. 

00000740 0AF7FFFE

 

That is the value for "Default"... it is what is used when it doesn't recognize the panel (no dictionary entry for your panel). I'm not sure of the meaning of the data.

[Joni_78]

In other words your valid range is somewhere between 0 and 40 (is that 40 decimal or 40 hex?). Your effective brightness as you move it from 0 to 0x710, where 'B' is the brightness level, is (B mod 40) (eg. remainder of B divided by 40).

 

Seems like you want to use different panel data. Data which increases from 0 to 40. Also, you should verify the same result before and after display sleep.

Sorry, I meant when I move the slider from 0% > 40%.

 

Do I edit the hex values of my current panel data?

[RehabMan]

Sorry, I meant when I move the slider from 0% > 40%.

 

Do I edit the hex values of my current panel data?

To determine the values to enter, you need to determine the actual values being used, and how they affect the brightness. Look in ioreg at RawBrightness as you change the slider. The percentage of slider position is meaningless.

 

Note: you will find the current value under PNLF:ApplePanelRawBrightness