Contribute
Register

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

Status
Not open for further replies.
RehabMan said:
Set IORegistryExplorer to update every second, instead of every 30.
Click to expand...
Nope, doesn't help... the data refreshes fast if I set the brightness with the keys, but nothing changes after it gets dimmed before turning off. It does it for you?
 
m.gbt said:
Yeah I could imagine that. But hey, take a look at AppleBacklightAtBoot and AppleMaxBrightness. They used to be 4648 and 1808 respectively. Now they are the same, but instead of increasing AppleMaxBrightness, it decreased AppleBacklightAtBoot. I believed I should have changed 1808 to 4648, you see? Am I wrong? Also, the max brightness value I got in Windows was 122A (4650), which is very near to 4648... But 1808 is too low...
Click to expand...

AppleBacklightAtBoot is a reading taken early in the boot process. Its value will depend on the backlight level initialized via BIOS and/or the previous OS you ran depending on whether your BIOS sets the backlight level or leaves it alone.

AppleMaxBrightness will always be 0x710.

Windows levels don't matter. We are doing things the OS X way here, where 0x710 is the value for max brightness. This is what the DSDT patch is doing... initializing the PWM hardware to be what OS X expects.

Logically, the effective brightness level is ApplePanelRawBrightness/AppleMaxBrightness (a number between 0 and 1, where 0 is black, and 1 is full brightness).
 
m.gbt said:
Hmm ok... So what is your final conclusion? My laptop is not compatible with this method, or the user didn't follow it correctly?
I replaced it but nothing changed, my max brightness is still similar to the Windows' min... :(
Click to expand...

Is the brightness changing as you move the slider? Is it the same before and after display sleep?

In DSDT brightness patch, for my PC I think it should say \_SB.PCI0.IGPU instead of ^PCI0.IGPU
Click to expand...

That is just the compiler changing things for you. In the context that the reference is in, they refer to the same thing (^ is "parent of this")
 
m.gbt said:
Brightness slider and brightness after sleep always worked fine, the only problem is the max brightness.
Also, maybe I should say that this only happens when AppleIntelSNBGraphics.kext is loaded. If I remove that kext, then I have max brightness, but everything else is crap (video memory, resolution, all wrong...)
The fixes on this thread, as far as I could notice, only changed AppleBacklightAtBoot value to be the same as AppleMaxBrightness (1808). The whole behavior is intact...
Click to expand...

You didn't answer my question. I will try to be more clear. Is the brightness slider prior to sleep working? Is the range of brightness experienced the same before and after sleep with the DSDT patch here and the backlight injector?
 
RehabMan said:
Set IORegistryExplorer to update every second, instead of every 30.
Click to expand...
Nope, doesn't help... the data refreshes fast if I set the brightness with the keys, but nothing changes after it gets dimmed before turning off. It does it for you?
 
kpkp said:
Nope, doesn't help... the data refreshes fast if I set the brightness with the keys, but nothing changes after it gets dimmed before turning off. It does it for you?
Click to expand...

I'll look at it here. Actually working on my Envy/HD4600 right now, but I don't see why it would be any different.

Make sure you have your current brightness set relatively high.
 
RehabMan said:
I'll look at it here. Actually working on my Envy/HD4600 right now, but I don't see why it would be any different.

Make sure you have your current brightness set relatively high.
Click to expand...

Just tested... and yes... I see that value does not update. It is probably because the value is temporary and not "committed".

The only way to see what value is being set is to do some debugging with ACPIDebug.kext.

Here's roughly what I do do dump these registers in system.log:
- use ACPIDebug.kext and DSDT patches: https://github.com/RehabMan/OS-X-ACPI-Debug
- use ACPIPoller.kext (already part of ProBook kexts)
- 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)

Now you can see every second what the registers are set to by monitoring system.log.

This is how I figured out the meanings of the HD4600 registers (because the docs are poor and Windows is doing something else, I think) and what OS X is setting these registers to in the case of HD3000/HD4000. Without blinkscreen (or the patches), for example, you can see both pre-display sleep and post-display sleep values, etc.

Note: Just did this and noticed that the first 16-bits of the data is not used as documented (by the link on insanely in post #1). So the OP of that thread has it wrong. Not sure what those first 16-bits are used for... Instead the driver is setting the screen brightness to the lowest value in the rest of the table (eg. the second 16-bits).
 
rob1980 said:
Is it my eyes playing tricks on me, or does this allow the screen to go brighter than the original method?
Click to expand...

It shouldn't, but it would depend on how you set the data using ACPIBacklight.

There are two numbers involved and the relative brightness is determined by the ratio of the two numbers. The value in the high 16-bits of LEVX is the denominator and the value placed in LEVL is the numerator.

At least that is my understanding so far from experimentation and reading the Intel docs (see post #1 for links). Really hard to compare without two identical machines for a side by side comparison. The human brain can play tricks.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top