Contribute
Register

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

Status
Not open for further replies.
Aside des from the possibility of errors (c
which could be corrected / set to ignore?)

any noticable delay in boot times?

No, still around 30 seconds from power button to login screen (including 3 second Clover menu delay) on HDD. I'm running the system this way for already two days and haven't encountered any problems so far. It seems the Clover's kernel cache injection works fine. My presumption is that it works pretty much like the on-the-fly kext patch function. The catch is only kexts that don't exist in /S/L/E as kext names and/or identifiers can be injected this way.
 
Thx for the hints, I managed to take the lowest value out and re-calibrate the curve (which came handy since the original one ends oddly).
View attachment 78920
For now I will stick to this method.

It ends oddly because I changed the top value originally 0x79d to 0x710 since the display driver is setting the cap to 0x710 (verified using ACPIDebug.kext/ACPIPoller.kext and some debug output in DSDT). You can put a larger value than 0x710 but it will be capped to 0x710 by the hardware.

What is the data you have now?

Eventually, I think I'll modify nguyenmac's script to generate data for AppleBacklight.kext.

But for now, I really want to figure out Haswell brightness. Many Haswell laptops use eDP and for eDP the backlight level is controlled via PCH i/o registers not IGPU system memory. Trying to find the details is next to impossible. I may fire off an email to Intel and see what happens.
 
Maybe. Maybe not. I've played with this kexts injection stuff the last two days. Removed all ProBook-specific kexts (incl. FakeSMC.kext) from /S/L/E, rebuilt the kext cache and put them all in EFI/EFI/Clover/kexts/10.9. Added to config.plist/SystemParameters/Inject kext=yes. Then added the AppleHDA binary patch to config.plist and nguyenmac's injector in /S/L/E and restored the vanilla AppleHDA.kext. The only patched kext left in /S/L/E is the Capri kext, but I think it's a matter of time to be found a solution for it with Clover.

Yes, you can inject any kext not already present and that do not attempt to 'override' iokit data (eg. most injector kexts should work, provided they are adding additional, not conflicting data). But the only effect is that /S/L/E is "cleaner" and boot times slower, although probably not noticeably so.

If you have Info.plists in cache providing conflicting information, you'll get the warnings of "already have XXX"... Quite frankly, I'm surprised it works in a predictable way at all, since Apple's own iokit/kernel documentation states the results are not determinate in this situation. That is, Apple does not state they use version# or anything else to determine which data actually gets used and the results are therefore unpredictable.

But hey, give it a try and experiment...
 
Yes, you can inject any kext not already present and that do not attempt to 'override' iokit data (eg. most injector kexts should work, provided they are adding additional, not conflicting data). But the only effect is that /S/L/E is "cleaner" and boot times slower, although probably not noticeably so.

If there is some boot delay, I haven't noticed it. My system boots up just like before. My friend tried the same technique on his desktop (Z77N-WiFi) and told me that his system boots up even a little faster. I've also noticed a little reduction in the boot time on my desktop (I've migrated it to Clover and this technique too).

If you have Info.plists in cache providing conflicting information, you'll get the warnings of "already have XXX"... Quite frankly, I'm surprised it works in a predictable way at all, since Apple's own iokit/kernel documentation states the results are not determinate in this situation. That is, Apple does not state they use version# or anything else to determine which data actually gets used and the results are therefore unpredictable.

But hey, give it a try and experiment...

I've just checked the log and the only ...already have prelinked... message is about AppleHDA, caused by the nguyenmac's injector which seems to be not loadable via the EFI partition and that's why it's still in /S/L/E.
There are no other messages like that and all support kexts from the Installer are on the EFI partition, even those that I don't need/use.
 
I've just checked the log and the only ...already have prelinked... message is about AppleHDA, caused by the nguyenmac's injector which seems to be not loadable via the EFI partition and that's why it's still in /S/L/E.
There are no other messages like that and all support kexts from the Installer are on the EFI partition, even those that I don't need/use.

Yes, it is only a problem with duplicate/conflicting information, such as the case with AppleHDA...
 
What is the data you have now?
Eventually, I think I'll modify nguyenmac's script to generate data for AppleBacklight.kext.
Yeah I was thinking about modifying that script too, but wanted to test the data a bit first, so I just did it by hand, it's just 16 values...

Code:
hex:
00110000 00340052 00730094 00BE00FA 01360172 01C5022F 02B90360 041A050A 060E0710 
dec:
0, 52, 82, 115, 148, 190, 250, 310, 370, 453, 559, 697, 864, 1050, 1290, 1550, 1808
 
Yeah I was thinking about modifying that script too, but wanted to test the data a bit first, so I just did it by hand, it's just 16 values...

Code:
hex:
00110000 00340052 00730094 00BE00FA 01360172 01C5022F 02B90360 041A050A 060E0710 
dec:
0, 52, 82, 115, 148, 190, 250, 310, 370, 453, 559, 697, 864, 1050, 1290, 1550, 1808

That data works reasonably well on both my 4540s and 4530s in the daylight. I'll find out later in a dark room. Do you find 0x34 (52) is the lower limit for your display?
 
That data works reasonably well on both my 4540s and 4530s in the daylight. I'll find out later in a dark room. Do you find 0x34 (52) is the lower limit for your display?
Do you find the lowest brightness to bright?
Maybe my display could go a little lower, but since it doesn't have a glossy finish but matte, I have the feeling it needs a little more brightness because of the lower transparency of the glass finish.
I can try to get lower but only for didactic purposes because it is not really usable... I tried the lowest brightness lever in pitch-dark and it still looked a bit darker then ideal.
 
Do you find the lowest brightness to bright?

It is brighter than the lowest possible setting, too dark for day time use, but... And probably a bit brighter than my MBA. I'll find out more at night time in a dark room.
 
It is brighter than the lowest possible setting, too dark for day time use, but... And probably a bit brighter than my MBA. I'll find out more at night time in a dark room.
OK. I would suggest you do it to fit you eyes... Then post the lower value here (or the whole scale) and I will give it a try and let you know if my display can handle it.
 
Status
Not open for further replies.
Back
Top