Testers wanted: Improved Backlight for 2010 MBPs

[Sidolin]

Hello everyone,

while investigating gpu switching on a mbp 6,2 I discovered how apple does the backlight setting on the recent mbps.

I added the new method to mbp_nvidia_bl, but as I have only access to one mbp it would be great if someone could test it on other models. Benefits include smooth transitions between brightness levels (like on osx) and doing stuff the right way.

Please only test this if you have sufficient knowledge of installing kernel modules and general linux stuff. And as everything hardware related it's possibly dangerous, just in case.

Howto: Remove all old backlight modules, download source, install it, modprobe mbp_nvidia_bl debug=1, cd /sys/devices/virtual/backlight/mbp_backlight, cat actual_brightness, echo 1 > brightness, echo 15 > brightness.
Additional points for posting the relevant dmesg output from the module here, especially the mux version.

This might also work for older mbps with graphics switching, for this edit /usr/src/mbp_nvidia_bl-0.24.3/mbp_nvidia_bl.c, find your model in the table and replace "nvidia_chipset_data" with "gmux_chipset_data".

Thanks!

[itismike]

Hi Sidolin,

I shouldn't be doing this given my lack of kernel experience, but I'm incorrigible. I got stuck at package installation:

$ sudo dpkg -i mbp-nvidia-bl-dkms_0.24.3_all.deb 
Selecting previously deselected package mbp-nvidia-bl-dkms.
(Reading database ... 151409 files and directories currently installed.)
Unpacking mbp-nvidia-bl-dkms (from mbp-nvidia-bl-dkms_0.24.3_all.deb) ...
Setting up mbp-nvidia-bl-dkms (0.24.3) ...
No packages found matching mbp_nvidia_bl-dkms.
Need NAME, and VERSION defined
ARCH is optional
dpkg: error processing mbp-nvidia-bl-dkms (--install):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 mbp-nvidia-bl-dkms

[Sidolin]

It seems packaging a kernel module is a lot harder than writing one so i'm giving up trying to build a neat .deb. I attached the source to the first post, maybe someone is better at packaging than me. May be it works with loadtarball, probably works if you just install the old mbp_nvidia_bl and replace the .c in /usr/src/mbp_nvidia_bl with mine from the tar.bz2 and rebuild the kernel module with dkms.

[_mario_]

Hi,

I'm currently preparing an update of this package for maverick and I'd like to include your patches of course. Can your provide some more information?

1. Where did you get the mechanism from?
2. What is the formula while writing (outl(0x1af40 / 15 * intensity, 0x774)) and reading (intensity = inl(0x774) / 0x1cc0) used for? If it is to scale to 15 levels as the old interface provided, we can omit it. Scaling to a reasonable range should better be left to userland applications (i.e., g-p-m). The older inferfaces were just that limited. What's the true hardware range?
3. .iostart and .iolen should reflect the true hardware resources being operated. Which ports exactly does the driver need? 0x704-0x707 to get the hardware version? And exactly 0x774 to read write the brightness?

thanks & ciao,
Mario

[Sidolin]

1. Where did you get the mechanism from?

Putting

agclog=10000 agcdebug=4294967295

in /Library/Preferences/SystemConfiguration/com.apple.Boot.plist enables logging for graphics switching and backlight control. It's quite verbose, output can be found in /var/log/kernel.log.

2. What is the formula while writing (outl(0x1af40 / 15 * intensity, 0x774)) and reading (intensity = inl(0x774) / 0x1cc0) used for? If it is to scale to 15 levels as the old interface provided, we can omit it. Scaling to a reasonable range should better be left to userland applications (i.e., g-p-m). The older inferfaces were just that limited. What's the true hardware range?

It's just for scaling, it's possible to use other values as well. I guess the hardware range is 0 - 0x1af40 since that seems to be what osx sets when at full brightness. Setting higher values is possible but i didn't notice any difference when going even higher.

3. .iostart and .iolen should reflect the true hardware resources being operated. Which ports exactly does the driver need? 0x704-0x707 to get the hardware version?

The real range is found in the acpi dsdt, search for gmux. It starts at 0x700 and is 0xff long.
A problem is that the other ports in this region do things like switching the display or powering down the nvidia gpu so I started to write a general gmux driver which does all these things, among setting the brightness. But it's still under heavy development so it certainly won't be ready for maverick. You can find the current version at http://andreas.meetr.de/gmux/apple_gmux.c but it's not really ready yet.

And exactly 0x774 to read write the brightness?

0x774 works for my laptop (mbp 6,2) but if you look at the kernel log it also sets 0x724, I'm not sure why.

[metatechbe]

Sidolin,

You are doing great progress !

I have a few questions :
- I tried to activate the "agcdebug" on my MBP 2009 but my kernel.log does not show anything. Is there an equivalent for these models ?
- should the apple_gmux.c work on MBP 2009 with 2 graphic cards ?
- do the brightness & graphic card controls work in EFI mode ?
- in BIOS mode does "lspci" report both graphic cards ?
- how do you find the address of the acpi dsdt ?

Thanks,

metatechbe

[Sidolin]

- I tried to activate the "agcdebug" on my MBP 2009 but my kernel.log does not show anything. Is there an equivalent for these models ?

Did you reboot afterwards? Can you paste your full Boot.plist?

- should the apple_gmux.c work on MBP 2009 with 2 graphic cards ?

Not at the moment, but after a few modifications it could work. At least if apple didn't change how the gmux works. But at least the detection which graphics card is the integrated one and the check for the gmux hardware revision have to be changed beforehand.

- do the brightness & graphic card controls work in EFI mode ?

Yes. If brightness control or apple_smc doesn't work for you in EFI mode it's probably because you use the noefi boot parameter which disables dmi (to check just run dmidecode, if it doesn't output your model etc. dmi doesn't work) which is used by some drivers to detect the model.
This patch (not by me) let's you boot without noefi: http://140.211.166.79/mailarchive/li...4607435/thread

- in BIOS mode does "lspci" report both graphic cards ?

No, BIOS mode hides the integrated card. Maybe it's possible to somehow unhide it but for now the intel card requires efi.

- how do you find the address of the acpi dsdt ?

sudo apt-get install acpidump iasl
sudo acpidump > acpidump.txt && sudo acpixtract acpidump.txt && iasl -d DSDT.dat && ls -l DSDT.dsl

[metatechbe]

Hi Sidolin,

Thanks for your responses...

Did you reboot afterwards? Can you paste your full Boot.plist?

Regarding the AGC log not working, I was still running under MacOS 10.6.1, so after upgrading to 10.6.4 I get the following entries in the log (amongs many others):

Sep 17 22:16:39 MBP kernel[0]: AGC: 2.8.63, HW version=1.8.8, flags:0, features:4
Sep 17 22:16:57 MBP kernel[0]: AGC:: setMuxRegister:1444 (750, 1, 1)
Sep 17 22:16:57 MBP kernel[0]: AGC:: setMuxRegister:1444 (750, 1, 0)
Sep 17 22:16:57 MBP kernel[0]: AGC:: getMuxRegister:1425 (716, 1) = 5
Sep 17 22:16:57 MBP kernel[0]: AGC:: setMuxRegister:1444 (714, 1, 0)

- should the apple_gmux.c work on MBP 2009 with 2 graphic cards ?

Not at the moment, but after a few modifications it could work. At least if apple didn't change how the gmux works. But at least the detection which graphics card is the integrated one and the check for the gmux hardware revision have to be changed beforehand.

Apart from the 0x8086 PCI Device ID, do you foresee anything else that will need modifications ? If you need more debug info, please ask.

sudo apt-get install acpidump iasl
sudo acpidump > acpidump.txt && sudo acpixtract acpidump.txt && iasl -d DSDT.dat && ls -l DSDT.dsl

Device (GMUX)
{
    Name (_HID, EisaId ("APP000B"))
    Name (_CID, "gmux")
    Name (_STA, 0x0B)
    Name (_CRS, ResourceTemplate ()
    {
        IO (Decode16,
            0x0700,             // Range Minimum
            0x07FF,             // Range Maximum
            0x01,               // Alignment
            0xFF,               // Length
            )
    })

The gmux range on the MBP 2009 (MacBookPro5,3) also starts at 0x700 and is 0xff long.

If you have a version that should work on MBP 2009, I can try it.

Regards,

Metatechbe

[Sidolin]

Well that looks promising, almost no difference to the newer mbps. And I guess the only things that need to get changed really are just the device id and the gmux version check to include 1.8.

But the switching driver is just one part, the other being the graphics card driver which also has to support switching. It's only possible with nouveau at the moment and I don't know if the current implementation supports two nvidia cards instead of just one nvidia and one intel. But thats certainly fixable.

I'll be on vacation for two weeks starting tomorrow without any internet access or time for developing anything, but I'll certainly try to finish the driver afterwards. There are still a few other things that need fixing (such as suspend not working, some audio hardware on the dedicated card interfering, proper hardware detection etc.) so it could take a while.
But I'm happy to have someone who could test it on some other hardware, and as far as I know there are no other dual gpu configurations from apple?

[metatechbe]

Sidolin,

Thanks to your findings, this other thread's long standing quest was finally solved.
http://ubuntuforums.org/showthread.php?t=1076879

For your information, a MacBookPro5,1 has a gMux version of 1.7.3, so it would be nice if your switching driver would also recognize this model.

Thanks again,

metatech