Just tested in now quickly (with tired eyes...) the screen doesn't flicker and it seems to handle it fine... But on the other hand if I out the brightness to the lowest setting I didn't notice the brightness reduction, but it might be just my sleepy eyes... Will test it better tomorrow. But at least it doesn't make my screen freak out.

Click to expand...

Interesting.

Do you think that it's possible that just some specific values create that flickery effect (low, but maybe not the lowest the backlight can handle), since you seem to know much more then me about how this backlight is being handled.

Click to expand...

Could be. I don't have that issue here at all with either laptop, so can't really say. It would require experimentation using ACPIBacklight.kext and ioio.

RehabMan, you say this should work for every laptop with Intel HD 3000, but what about the DSDT patch? From what I've read in the ACPIBacklight topic, the brightness values are laptop dependent. Also, I tried anyway to patch my DSDT but it gives errors on "LEVL" and "LEV2" commands saying they don't exist.

Click to expand...

The brightness levels for this technique will generally be the same because of the way OS X expects the backlight control registers to be initialized (range of 0-0x710). I think it will even work on some Haswell systems, provided the laptop does not use eDP (eDP controls are somewhere in the PCH instead of the IGPU).

And the general technique of patching DSDT is the same since the registers to control this hardware function are at the same offsets (they are at fixed offsets from BAR1, which is at fixed offset 0x10 from PCI_config).

The details of your DSDT may be different and that is what might be causing the error. In particular the patches depend on the original PCI_Config being called IGDP, and they depend on the GFX0 device being named IGPU (we rename it other ProBook patches).

Also tried to get my own brightness values in RW-Everything but all I could get was my BAR1 address (0xF0000004), then I summed 0x4824C to it, resulting 0xF0048250, but I can't seem to find anything like that in dword 32-bit mode... Are there some more general instructions so that I could also apply it to my Samsung NP530U3B laptop?

Click to expand...

What do you mean 'find anything like that in dword 32-bit mode?' . After you determine the address F0048250, you use Access -> Memory and type in that address as the address of memory to view. Then you should see the values change as you change the brightness.

The problem I'm facing is only related to the max brightness after boot. Brightness after wake is ok, it also changes according to AC/Battery supply, but the 100% value is so dark I can only reasonably work with it in the night...

Click to expand...

Yes... exact symptoms that we have. It is because of a difference in the way our laptop BIOS initializes the backlight controls and the way OS X expects them to be initialized (by Mac firmware). The DSDT patch takes care of this difference, initializing it when OS X boots, such that display sleep is not necessary.

You`re very kind, sir. So far I`ve managed to do so many things on my own but it seems right now I`m just exhausted...
I have attempted to such details (GFX0 and other device names), but anyway I can`t deal with all the differences. Sorry for that.
If that really won`t bother you, I`m attaching here my pure DSDT and also my patched DSDT (the one I`m using right now). Both of them successfully boot my laptop but the patched one includes all fixes for Sandy Bridge so probably there would be something wrong with the pure one that I didn`t have the time to notice

You don't really need to know this data for this method. The whole idea here is to use an OS X friendly range (0-0x710) instead of the laptop's native range. The values you have above are useful for the ACPIBacklight.kext+DSDT patch method as covered in the related thread. Although it is good to know that the values at BAR1+4824c are being used and correspond in Windows.

Ok, I`ve successfully patched my DSDT (GFX0 -> IGPU, and then Brightness patch), compilation went fine and I could boot with it without problems.Then I followed the instructions for patching AppleBacklight. Two files were created inside ˜patched˜ folder: AppleBacklight.kext and AppleBacklightInjector. Then I installed only AppleBacklightInjector via Kext Utility and rebooted, nothing changed and in kextstat, this kext does not appear.I went to Terminal to try something more manual:

Also tried renaming the CFBundleExecutable to AppleBacklightInjector but didn`t work. Any ideas?Attaching here my DSDT after this thread`s patches and the AppleBacklightInjector.kext generated by script.

Click to expand...

Read the instructions in post #1. You must repair permissions & rebuild cache.

Check your ioreg in IORegistryExplorer. What do you see under PNLF.AppleIntelPanelA.Apple Panel?

Could be. I don't have that issue here at all with either laptop, so can't really say. It would require experimentation using ACPIBacklight.kext and ioio.

Click to expand...

Where do you read that "11" value? It is "hardcoded" in the driver?

I can conform that the dimmed screen isn't and darker then my lowest brightness... At-least nothing noticeable.
I tested by putting the value to the 2nd lowest waited for the dimming to occur and then lowered to the lowest brightness level and the brightness doesn't change in a noticeable way.

I can conform that the dimmed screen isn't and darker then my lowest brightness... At-least nothing noticeable.
I tested by putting the value to the 2nd lowest waited for the dimming to occur and then lowered to the lowest brightness level and the brightness doesn't change in a noticeable way.

Click to expand...

Best to look at ioreg to see what ApplePanelRawBrightness is being set to...

Don`t worry, I`ve read the instructions. Kext Utility repairs permissions and rebuilds cache automatically, but I did it on my own when I saw it was not working, anyway this was not the cause of the problem. ioreg -l gives this: