Contribute
Register

Full range of brightness using ACPIBacklight

Status
Not open for further replies.
frantisek.nesveda said:
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.
Click to expand...

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)

For DSDT:
- 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.
 
This looks promising, but are these brightness levels the same for every ProBook display? As far as I know, the brightness levels may be different for display panels from different vendors.
 
My desktop
GA-H77N-WIFI |  i7 3770 |  HD 4000
philip_petev said:
This looks promising, but are these brightness levels the same for every ProBook display? As far as I know, the brightness levels may be different for display panels from different vendors.
Click to expand...

I think they are likely different between displays. Whether we can extract that data and come up with 64-levels automatically inside the DSDT remains to be seen. Do some testing with your machines with Rw-Everything and report back.

FYI: Here is the current state of the patch I'm using on the 4530s. This is also checked into the repo.

Code: 
#Maintained by: RehabMan for: HP Probook 4x30s/4x40s
# 12_Brightness.txt

#
# This patch is to use ACPIBacklight.kext instead of the native
# backlight control.  With it you can have more control over
# the range of brightness.
#
# Note: This patch and ACPIBacklight is a work-in-progress.
#

into device label PNLF remove_entry;
into scope label \_SB insert
begin
Device (PNLF)\n
{\n
    // normal PNLF declares (note some of this probably not necessary)\n
    Name (_HID, EisaId ("APP0002"))\n
    Name (_CID, "backlight")\n
    Name (_UID, 0x0A)\n
    Name (_STA, 0x0B)\n
    //define hardware register access for brightness\n
    // note: base address 0xd4000004 is BAR1 address\n
    // define in PCI config offset 0x10\n
    // you can see this value in RW-Everything under Bus00,02 Intel VGA controler PCI\n
    OperationRegion (BRIT, SystemMemory, 0xd4000004, 0xc8254)\n
    Field (BRIT, AnyAcc, Lock, Preserve)\n
    {\n
        Offset(0x4824c),\n
        LEV2, 32,\n
        LEVL, 32,\n
        Offset(0xc824c),\n
        LEVX, 32,\n
        LEVW, 32,\n
    }\n
    // _BCL: returns list of valid brightness levels\n
    // first two entries describe battery/ac power levels\n
    Name (_BCL, Package()\n
    {\n
        651,\n
        227,\n
        0,\n
        102, 112, 122, 132,\n
        134, 136, 138, 140,\n
        142, 144, 146, 148,\n
        150, 152, 154, 155,\n
        157, 159, 161, 163,\n
        167, 171, 175, 178,\n
        182, 186, 190, 193,\n
        195, 198, 201, 204,\n
        207, 210, 213, 216,\n
        219, 222, 224, 227,\n
        229, 231, 234, 237,\n
        239, 241, 244, 247,\n
        249, 251, 254, 257,\n
        264, 272, 280, 288,\n
        296, 304, 312, 321,\n
        336, 351, 366, 382,\n
        389, 397, 405, 413,\n
        420, 428, 436, 444,\n
        469, 494, 520, 546,\n
        572, 598, 624, 651,\n
    })\n
    // _BCM/_BQC: set/get for brightness level\n
    Method (_BCM, 1, NotSerialized)\n
    {\n
        Store(0x80000000, LEV2)\n
        Store(Match(_BCL, MGE, Arg0, MTR, 0, 2), Local0)\n
        if (LNotEqual(Local0, Ones))\n
            { Store(DerefOf(Index(_BCL, Local0)), LEVL) }\n
    }\n
    Method (_BQC, 0, NotSerialized)\n
    {\n
        Store(LEVL, Local0)\n
        Store(Match(_BCL, MGE, Local0, MTR, 0, 2), Local0)\n
        if (LEqual(Local0, Ones))\n
            { Store(DerefOf(Index(_BCL, 1)), Local0) }\n
        Return(Local0)\n
    }\n
    Method (_DOS, 1, NotSerialized) { ^^PCI0.IGPU._DOS(Arg0) }\n
}\n
end;
 
RehabMan said:
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

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)

For DSDT:
- 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.
Click to expand...

See my previous post, I think I have already determined the range for the stock 768p 4530s display (0x00 - 0x0640), levels above that shine the same as 0x640. The quarter steps can be done via DSDT, just put 65 levels there and OS X (or the current ACPIBrightness.kext. Also, my lowest value in the DSDT (apart from 0x00) is 0x19, and it could be possibly set even lower, although on really low values the backlight starts to blink.

The device memory offset (BAR1 address - 4) could be dynamically found by calling "lspci -v -s 00:00:02 | grep "Memory at [a-f0-9]" | sed 's/.*Memory at \([a-f0-9]*\).*/\1/g'", which could theoretically be used by the ProBook installer, but I don't know if it is exactly what you wanted. Also, it's possible this won't work across devices, we should try to find out if Intel HD Graphics is always on the slot 00:00:02, but so far in every thread or post I saw it was there.

Do you have the ProBook 4530s with or without AMD Radeon? I've got the one with the Radeon (currently disabled in BIOS) and stock screen (768p) and my offset is 0xC4000000.

The numbers 0x00-0x0640 were taken from a DSDT for a Thinkpad T410, so at least between those two machines they are the same. (That doesn't prove anything, though.)
 
frantisek.nesveda said:
See my previous post, I think I have already determined the range for the stock 768p 4530s display (0x00 - 0x0640), levels above that shine the same as 0x640. The quarter steps can be done via DSDT, just put 65 levels there and OS X (or the current ACPIBrightness.kext. Also, my lowest value in the DSDT (apart from 0x00) is 0x19, and it could be possibly set even lower, although on really low values the backlight starts to blink.
Click to expand...

See my latest post and patches. I don't have a 4530s with standard screen (currently). Mine is 1080p AUOv4. I have already done all you're saying and realized it the moment somebody mentioned the Shift+Option key. It would be nice to get confirmation of the 0x640 from someone else with a 4530s standard screen setup.

The device memory offset (BAR1 address - 4) could be dynamically found by calling "lspci -v -s 00:00:02 | grep "Memory at [a-f0-9]" | sed 's/.*Memory at \([a-f0-9]*\).*/\1/g'", which could theoretically be used by the ProBook installer, but I don't know if it is exactly what you wanted. Also, it's possible this won't work across devices, we should try to find out if Intel HD Graphics is always on the slot 00:00:02, but so far in every thread or post I saw it was there.
Click to expand...

I would like to do it by reading the PCI config data in DSDT and making the OperationRegion for SystemMemory start there. I've seen it done in other DSDTs but I'm not 100% clear on the details. Some script thing to edit the patch on-the-fly is a good fallback, assuming the "levels specific to display" issue can be resolved.

Do you have the ProBook 4530s with or without AMD Radeon? I've got the one with the Radeon (currently disabled in BIOS) and stock screen (768p) and my offset is 0xC4000000.
Click to expand...

All my machines are Intel integrated only.

The numbers 0x00-0x0640 were taken from a DSDT for a Thinkpad T410, so at least between those two machines they are the same. (That doesn't prove anything, though.)
Click to expand...

Might mean they have same/similar displays.
 
Just applied the patch from RehabMan's repo, installed acpibacklight.kext and my god... so much nicer for my eyes. Thanks a lot!

FYI: I have a 4530s with no radeon card and with the standard display.
 
RehabMan said:
I would like to do it by reading the PCI config data in DSDT and making the OperationRegion for SystemMemory start there.
Click to expand...

DONE.

New patch determines BAR1 address automatically...

Relevant changes:
Code: 
into device label IGPU code_regex (OperationRegion\s\(IGD2,\sPCI_Config[^\}]*\}) remove_matched;
into device label IGPU code_regex (OperationRegion\s\(IGDP,\sPCI_Config[^\}]*\}) replace_matched
begin
%1\n
OperationRegion (IGD2, PCI_Config, 0x10, 4)\n
Field (IGD2, AnyAcc, NoLock, Preserve)\n
{\n
	BAR1,32,\n
}\n
end;

...
    OperationRegion (BRIT, SystemMemory, \_SB.PCI0.IGPU.BAR1, 0xc8254)\n


Note: I'm going to work on ACPIBacklight.kext next, primary task is to store last backlight level in nvram. At this point I'm not sure how complex that is going to be. It might involve a daemon to watch for changes in ioreg and push them to nvram. We'll see. I'll also implement a few other things... The details on the data table can wait for now.

Please do submit your feedback. I'm somewhat surprised about the lack of feedback. This approach fixes a long standing problem with LCD brightness levels and allows us direct control. Hopefully the approach is valid on all generations of Intel HD graphics.

Big thanks to pwd for finding this information and posting it here!
 
Here is the data from my ProBook 4540s, standard screen, 4GB RAM, Windows 8.1

I have not installed the brightness key handler from HP yet.

BAR1 address, 0xD0000004

Windows 8.1 range: 0xcd ... 0xd9f

With HP key handler installed: 0xcd, 0xe8, 0x148, 0x1de, 0x2ab, 0x3ca, 0x4e9, 0x668, 0x75c, 0x839, 0xaa0, 0xd9f
(12 values)
 
nguyenmac said:
The DSDT patch in repo and PNLF device here: http://www.tonymacx86.com/hp-proboo...rightness-using-acpibacklight.html#post723046 do not work for my HD4000. Only this http://www.tonymacx86.com/hp-proboo...rightness-using-acpibacklight.html#post722473 works.


EDIT: It's the methods in PNLF (_BCL, BCM,...) of your patch that do not work.
Click to expand...

I'm not surprised.

I'm just getting started on the 4540s. It requires different data (the methods are fine). See my latest post.

Perhaps you should collect your data (see post #11). Your 8470p may even be different from the 4540s.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top