Contribute
Register

Work around for 4x30s screen brightness...

Status
Not open for further replies.
zoltankr said:
Yes, but he has Intel HD4000. I have HD 3000.
[/COLOR]
Click to expand...

That makes sense. Brightness issue is no doubt HD3K driver related...

One other note: I do *not* run patched AppleIntelSNBGraphicsFB.kext...
 
RehabMan said:
Make sure you don't have setbrightness interfering...

And I verified again. I did the following:
- set the brightness 4 levels from brightest (4 dark squares on right)
- restarted
- logged in, waited for blinkscreen to kick in
- checked brightness with F2
- result: brightness was then set to five from brightest (5 dark squares on right)
- set brightness to 4 levels from lowest (4 bright squares on left)
- restarted
- logged in, waited for blinkscreen to kick in
- checked brightness with F2
- result: brightness was then set to three from brightest (3 bright squares on left)

In other words, other than the blinking display and having to login first, it works like it should.

Side note: I tried running the blinkscreen before login, but the OS calls it is making doesn't work at the login screen -- login screen seems 'special'...
Click to expand...

I removed setbrightness. I do not use patched AppleIntelSNBGraphics.
Same issue with Chameleon-trunk 2189.

As you said the problem seems to be HD3000 related. Your ProBook at least remembers the brightness value. Each time I restart the computer OS X jumps back to 100% brightness.

I'm wondering where is the brightness value stored and why is lost during restart.
 
zoltankr said:
I removed setbrightness. I do not use patched AppleIntelSNBGraphics.
Same issue with Chameleon-trunk 2189.

As you said the problem seems to be HD3000 related. Your ProBook at least remembers the brightness value. Each time I restart the computer OS X jumps back to 100% brightness.

I'm wondering where is the brightness value stored and why is lost during restart.
Click to expand...

Maybe some other 4530s owner can verify my results... Hint Hint.

BTW, If I was you, I'd remove the startup items for setbrightness, and call setbrightness directly (probably after blinkscreen) in ~/autoexec.sh.
 
Thank you, I will try something like this:

Code: 
#!/bin/sh
# install to ~/autoexec.sh


# might not be necessary to sleep for a second, you can experiment with/without it...
sleep 1
# blink the screen, fixing the brightness issue...
/usr/bin/blinkscreen

# set brightness
/usr/sbin/setbrightness 0.90

BTW, the brightness value is stored in ioreg:

ioreg.jpg

That value changes in ioreg every time I press FN+Brightness UP/Down. It jumps back to 0x400 after reboot. No messages in console log.
 
zoltankr said:
Thank you, I will try something like this:

Code: 
#!/bin/sh
# install to ~/autoexec.sh


# might not be necessary to sleep for a second, you can experiment with/without it...
sleep 1
# blink the screen, fixing the brightness issue...
/usr/bin/blinkscreen

# set brightness
/usr/sbin/setbrightness 0.90

BTW, the brightness value is stored in ioreg:

View attachment 54183

That value changes in ioreg every time I press FN+Brightness UP/Down. It jumps back to 0x400 after reboot. No messages in console log.
Click to expand...

Yes, there are several values that change in that area of ioreg with brightness...

I think it is stored in "nvram". In quotes because ours is simulated (stored in a file) via /Extra/modules/FileNVRAM.dylib. Try:
Code: 
nvram backlight-level
 
Yes, maybe it is NVRAM related.
I see these:

backlight-level %10%07 (max brightness)
backlight-level L%05 (90% brightness)
backlight-level %0a%05 (80% brightness)

It jumps back to %10%07 after reboot.
 
philip_petev said:
+1
I'm using Chimera 2.0.1
Click to expand...

Try latest Chameleon. I 'upgraded' to Chameleon because I got tired of looking at those startup messages, but also the modules/FileNVRAM.dylib does seem more capable.

Note: This will bite you when it comes to boot-args. Thus why I have 'nvram -d boot-args' in my /usr/bin/autoexec.sh...

Edit: Also if you read the thread, you'll see that zoltankr was able to update FileNVRAM.dylib to a more recent build and continue using Chimera... Edit again: Not so much, he's using Chameleon too.
 
RehabMan said:
Try latest Chameleon. I 'upgraded' to Chameleon because I got tired of looking at those startup messages, but also the modules/FileNVRAM.dylib does seem more capable.

Note: This will bite you when it comes to boot-args. Thus why I have 'nvram -d boot-args' in my /usr/bin/autoexec.sh...
Click to expand...

Seems to work fine with Enoch 2191 + FileNVRAM.dylib 1.1.3

RehabMan said:
Edit: Also if you read the thread, you'll see that zoltankr was able to update FileNVRAM.dylib to a more recent build and continue using Chimera...
Click to expand...

I tried once to use the latest two versions of FileNVRAM.dylib (1.1.3 and 1.1.2) with Chimera 2.0.1, but with no success. Actually, there wasn't any error messages or something, but I wasn't able to login to the Messages service anymore. Once I've restored the file, bundled with Chimera 2.0.1, I was able to use Messages again. Are you sure he's using Chimera with the latest version of FileNVRAM.dylib, because I haven't read such thing in this thread?
 
My desktop
GA-H77N-WIFI |  i7 3770 |  HD 4000
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top