- May 3, 2012
- Intel DH67BL
- HD 3000
- Mobile Phone
Thanks for the info, this worked well for me. Now the brightness levels before and after display sleep are the same, also every level from 0 to 16 is different. Sadly, the steps are still uneven and the quarter-steps don't work.
I also have changed the first two brightness values in the DSDT, as they correspond to the brightness set on boot (one for AC power, one for battery), now the brightness is set to the level 1 after boot.
If I have time during the weekend, I will try to write some utility to manually set the brightness intensity hardware level (e.g. 0x012C) from the command line (to test which levels are right for our display), but I don't promise any result just yet, because the exam time is coming and free time is precious these days.
Using RW-Everything in Windows you can determine the range of values that Windows uses. Furthermore, you can determine if any values outside of the range produce lower/higher backlight levels.
Here's a quick how-to:
- run RW-Everything
- determine your BAR1 address, like the guide
- add the BAR1 address to 4824c to come up with a memory address of the controls
- view the resulting memory address
- for example, my BAR1 address is 0xd4000004, so adding 4824c, we have 0xd4048250
- view the memory as 32-bit dwords
- now you can see the 0x80000000 in the first dword at 0xd4048250 and the brightness value at 0xd4048254
- modify the brightness with Fn+brightness keys, note the values placed at 48254.
- modify the value at 48254
Here is the results on my 4530s:
HP ProBook 4530s w/ 1080p, 8GB RAM
BAR1 address, 0xD4000004
range used by Windows: 0x84 to 0x28b, 21 levels (would be 22 including black)
each value: 0x84, 0x8c, 0x94, 0x9b, 0xa3, 0xb2, 0xc1, 0xcc, 0xd8, 0xe3, 0xed, 0xf7, 0x101, 0x120, 0x141, 0x160, 0x17e, 0x19d, 0x1bc, 0x222, 0x28b
And for my 4540s:
HP ProBook 4540s w/ standard screen, 4GB RAM
BAR1 address, 0xD0000004
Windows 8.1 range: 0xcd ... 0xd9f
each value: 0xcd, 0xe8, 0x148, 0x1de, 0x2ab, 0x3ca, 0x4e9, 0x668, 0x75c, 0x839, 0xaa0, 0xd9f
If you were to graph the data, you would notice it is not linear. In fact, it is quite sloppy and does not seem to conform to a function (probably the data was determined by a human, not formula).
I tried higher values than 0x28b and it didn't seem to have a noticeable effect. So 0x28b, for my machine, may be the high limit. I also tried lower levels than 0x84 and was able to go lower, which may come in handy for extending battery life.
I haven't looked at the data for the 4x40s yet. My plan at this point is to work on ACPIBacklight and the DSDT patches. There is no need to be ACPI compliant with either... we can bend the rules to fit our needs and the needs of OS X better. For example, OS X clearly has 64 levels plus OFF (I believe between 0-0x400), ACPI spec calls for unspecified number of levels between 0-100. We can ignore the ACPI spec here and do what makes more sense for OS X.
Here's what I'd like to see in ACPIBacklight:
- save restore across sleep/wake (no need to implement in DSDT)
- save restore via OS X "nvram" across reboot
- quarter levels
- make sure battery/ac transition levels are correct (hard setting or relative to current?)
- smooth transitions (like a real Mac)
- see if it is possible to determine BAR1 offset dynamically (PCI config?)
- are all the brightness levels the same between various machines/screens?
- better, table driven implementation of levels
I'll let you know what I come up with... If you have the inclination to test the data ranges in RW-Everything, post the results here.