Contribute
Register

Native Brightness working without 'blinkscreen' using patched AppleBacklight.kext

Status
Not open for further replies.
You're absolutely right. One more time I had booted with the wrong DSDT. I'm really sorry about that, now it's correct, 100% sure :)

Everything looks ok there. Are you using stock AppleIntelSNBGraphicsFB.kext? How do levels compare before/after sleep?

Attached is a DSDT for test. It has some debug traces in it.

Install both ACPIDebug.kext and ACPIPoller.kext:
- ACPIPoller: https://github.com/RehabMan/OS-X-ACPI-Poller
- ACPIDebug: http://www.tonymacx86.com/attachmen...acing-system-log-rehabman-debug-2013-1015.zip

After installing, reboot, look at system.log for ACPIDebug messages. There will be two when the system starts and one output every second. Manipulate brightness up/down, sleep the display, wake the display, etc. Post output here.
 

Attachments

  • dsdt_m.gbt2.aml.zip
    13.6 KB · Views: 79
Everything looks ok there. Are you using stock AppleIntelSNBGraphicsFB.kext? How do levels compare before/after sleep?

I'm using stock AppleIntelSNBGraphicsFB.kext.
Before using your kext and applying your patch, the brightness increased a little after sleep (it was still low after it but a bit higher). Now, before and after sleep it feels the same.

After installing, reboot, look at system.log for ACPIDebug messages. There will be two when the system starts and one output every second. Manipulate brightness up/down, sleep the display, wake the display, etc. Post output here.

I don't have outputs every second. Here are the two outputs when the system starts:

Code:
Jan 15 00:37:27 localhost kernel[0]: ACPIDebug: { "PNLF._INI enter", 0x80000000, 0x1228, 0x80000000, 0x12281228, }
Jan 15 00:37:27 localhost kernel[0]: ACPIDebug: { "PNLF._INI exit", 0x80000000, 0x710, 0x80000000, 0x7100000, }

Back in this thread you said to do this:
- create SMCD device with FCPU method (already part of ProBook patches)
- add a line to FCPU:
Code:
\rmdt.p5("brit", \_sb.pnlf.lev2, \_sb.pnlf.levl, \_sb.pnlf.levw, \_sb.pnlf.levx)

I believe I should do that to have an output every second but I don't know if I should in my non-ProBook computer. Can you give me some more instructions?
Thank you for your attention.
 
I'm using stock AppleIntelSNBGraphicsFB.kext.
Before using your kext and applying your patch, the brightness increased a little after sleep (it was still low after it but a bit higher). Now, before and after sleep it feels the same.

At least they are the same.

I don't have outputs every second.

I made a mistake (TCPU instead of FCPU). Try it again with new file uploaded...

Here are the two outputs when the system starts:

Code:
Jan 15 00:37:27 localhost kernel[0]: ACPIDebug: { "PNLF._INI enter", 0x80000000, 0x1228, 0x80000000, 0x12281228, }
Jan 15 00:37:27 localhost kernel[0]: ACPIDebug: { "PNLF._INI exit", 0x80000000, 0x710, 0x80000000, 0x7100000, }

At least we know the _INI is doing its job...
 
Right after booting:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x500, 0x80000000, 0x7100000, }
After moving brightness slider all the way up:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x710, 0x80000000, 0x7100000, }
After sleep/wake:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x710, 0x80000000, 0x7100000, }
1 key press below the max brightness:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x54c, 0x80000000, 0x7100000, }
1 key press above black screen:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x1c4, 0x80000000, 0x7100000, }

If I think only logically, given this message:
ACPIDebug: { "PNLF._INI enter", 0x80000000, 0x1228, 0x80000000, 0x12281228, }
Then shouldn't the desired next one be:
ACPIDebug: { "PNLF._INI exit", 0x80000000, 0x0710, 0x80000000, 0x07100710, }

Again, I'm just being logical, I have no specific knowledge here.
 
Right after booting:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x500, 0x80000000, 0x7100000, }
After moving brightness slider all the way up:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x710, 0x80000000, 0x7100000, }
After sleep/wake:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x710, 0x80000000, 0x7100000, }
1 key press below the max brightness:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x54c, 0x80000000, 0x7100000, }
1 key press above black screen:
ACPIDebug: { "POLL.TCPU", 0x80000000, 0x1c4, 0x80000000, 0x7100000, }

Everything seems normal there -- that is, as far as these registers... working as I expect.

Except there is one strange thing. The values set to LEVL should be the same values entered into your AppleBacklightInjector (taken from last ioreg you sent): 0000 0034 0052 0073 0094 00be 00fa 0136 0172 01c5 022f 02b9 0360 041a 050a 060e 0710. Why are the values different in your debug output?

Unless you're using different data now? Maybe send the ioreg that corresponds to this system.log output.

If I think only logically, given this message:
ACPIDebug: { "PNLF._INI enter", 0x80000000, 0x1228, 0x80000000, 0x12281228, }
Then shouldn't the desired next one be:
ACPIDebug: { "PNLF._INI exit", 0x80000000, 0x0710, 0x80000000, 0x07100710, }

Again, I'm just being logical, I have no specific knowledge here.

Not really. Evidently OS X doesn't use the low-order 16-bits of LEVX. Notice the value which it is set to after display sleep, 0x7100000. That value is set by the display driver, not DSDT. Evidently the value there is some sort of "alternate" only used if some other bit is set on the hardware (selects an alternate clock or something). I decided it would be best to set it to the same value that OS X set it to after display sleep. You can read more if you're interested by following the links to the Intel docs in post #1.

One thing you could do... is some experimentation with ACPIBacklight. What happens if you give it full range from 0 - 0x1228 using ACPIBacklight.kext?
 
Except there is one strange thing. The values set to LEVL should be the same values entered into your AppleBacklightInjector (taken from last ioreg you sent): 0000 0034 0052 0073 0094 00be 00fa 0136 0172 01c5 022f 02b9 0360 041a 050a 060e 0710. Why are the values different in your debug output?

Unless you're using different data now? Maybe send the ioreg that corresponds to this system.log output.

I've been doing so many confusion and I know you can't trust me by this time, I've reinstalled the system since our last messages some hours ago, so obviously I lost AppleBacklightInjector and I forgot to reinstall it, in the middle of many other things to solve :(
I've reinstalled it and I can confirm you the max brightness didn't change and the values are the ones you pasted now ;) tested one by one...
Sorry again...

One thing you could do... is some experimentation with ACPIBacklight. What happens if you give it full range from 0 - 0x1228 using ACPIBacklight.kext?

I've always wanted to do that but I had the impression that the injector was a more modern way of doing the same thing, and also you told me that the value 0x710 is just the way a Mac works...
Well I'll try it and post back here with some results. Thanks a lot for all your attention.
 
I've been doing so many confusion and I know you can't trust me by this time, I've reinstalled the system since our last messages some hours ago, so obviously I lost AppleBacklightInjector and I forgot to reinstall it, in the middle of many other things to solve :(
I've reinstalled it and I can confirm you the max brightness didn't change and the values are the ones you pasted now ;) tested one by one...
Sorry again...

No worries. Just making sure there was nothing going on that I didn't understand...


I've always wanted to do that but I had the impression that the injector was a more modern way of doing the same thing, and also you told me that the value 0x710 is just the way a Mac works...
Well I'll try it and post back here with some results. Thanks a lot for all your attention.

I prefer using ACPIBacklight actually. More control, and definitely better for poking at the hardware to see how it responds. You get some extra features not there with the native kext too.
 
So, I quickly did as suggested in ACPIBacklight #1 post. So far I didn't care about the number of brightness levels, I've just used the same obtained from Windows (8 levels + zero).
The max brightness I believe that is still the same, but one thing got my attention in the ioreg.
In the one I sent to you, with your patch and injector, backlight-level (inside AppleEFINVRAM) was 1007; now, it is 0105, which kind of represents my perception... I mean, my full brightness at Mac feels lower than the minimal one at Windows, and the value I got in Windows for that was 0x111 (273). It makes sense to me...
Is there a way to set that brightness-level, maybe with an NVRAM file..? I'm booting with Clover btw.
 
So, I quickly did as suggested in ACPIBacklight #1 post. So far I didn't care about the number of brightness levels, I've just used the same obtained from Windows (8 levels + zero).
The max brightness I believe that is still the same, but one thing got my attention in the ioreg.
In the one I sent to you, with your patch and injector, backlight-level (inside AppleEFINVRAM) was 1007; now, it is 0105, which kind of represents my perception... I mean, my full brightness at Mac feels lower than the minimal one at Windows, and the value I got in Windows for that was 0x111 (273). It makes sense to me...
Is there a way to set that brightness-level, maybe with an NVRAM file..? I'm booting with Clover btw.

The backlight-level in nvram is only the initial setting. Assuming your nvram is working, it is the last value you set, and will carry over when you reboot. Why the focus on that value?
 
The backlight-level in nvram is only the initial setting.
Yeah it was just inverted bytes from the BacklightLevel parameter in Clover configuration file... It was set in my config to 0x0501.
Why the focus on that value?
Because we have no idea why it doesn't work in my computer so I'm trying to raise whatever I believe could be a cause... :(
 
Status
Not open for further replies.
Back
Top