Backlight keeps getting darker on MacBookPro

Bug #285815 reported by Henrik Rydberg on 2008-10-19
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mactel Support
Undecided
Unassigned
gnome-power-manager (Ubuntu)
Low
Unassigned
hal (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: hal

<email address hidden>:

i am using a macbook pro 3.1 with intrepid beta and the nvidia driver. i finally managed to have the backlight keys F1 and F2 working but now i face another problem. when i change the backlight setting, it resets itself after some minutes to an average light level. then i use f2 to increase backlight again and some time later it goes down again.i have deactivated the shade setting in the gnome power management. the light is also turned down while moving the mouse or typing.

Henrik Rydberg (rydberg) wrote :

This is a continuation of the problem adressed with upstream commit
95bd4f1bf9a62f1551461841d64f6f1cdea6a92e, to this problem: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/226894

It is correct that MacBookPro3,1 and later are not listed to use the macbookpro addon. However, the light_sensor and keyboard_backlight devices are also driven by the same addon, and thus the newer macbooks should not be listed there either.

Assuming that the gnome-power-manager still treats the listed but missing light sensor, the symptom described in this bug makes sense.

The suggested fix is to remove MacBookPro3,1;MacBookPro3,2;MacBookPro4,1 completely from fdi/policy/10osvendor/10-macbookpro-utils.fdi, and instead implement keyboard_backlight and light_sensor through the mechanism outlined in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/125918.

Henrik Rydberg (rydberg) wrote :

Here is a patch to gnome-power-manager that seems to fix the problem.

Henrik Rydberg (rydberg) on 2008-11-24
Changed in mactel-support:
status: New → Fix Released
Pedro Villavicencio (pedro) wrote :

Thanks for your work, Ted could you have a look to the patch? thanks.

Changed in gnome-power-manager:
assignee: nobody → ted-gould
importance: Undecided → Low
status: New → Confirmed
Alex Murray (alexmurray) wrote :

I am seeing this same bug on my MacBook Pro 5,1 with Ubuntu 8.10 using the mactel-support ppa with all relevant packages from the PPA installed and kernel modules loaded. This includes the updated package of gnome-power-manager from the PPA, and the only way to fix the problem is to disable the 'Use ambient light to adjust LCD brightness' option in g-p-m. Perhaps the light sensor reading is not correct? I am familiar with linux kernel development and debugging (just not on the MacBook Pro - this is my first) am just not too sure where to start debugging this one - any ideas?

Alex Murray (alexmurray) wrote :

Seems I needed to adjust the correction_factor gconf key in gnome-power-manager - in good light, the light sensor would be

cat /sys/devices/platform/applesmc.768/light
(4,0)

and then covering it with my hand, I'd get

cat /sys/devices/platform/applesmc.768/light
(0,0)

So it seems to be reading quite low, changing correction_factor to 10000 seems to give some appropriate results... I am a little concerned about the 0 reading from the right sensor though - is this something specific to the applesmc driver on MBP 5,1 or is it more indicative of some hardware
fault??

Henrik Rydberg (rydberg) wrote :

>So it seems to be reading quite low

Yes, this is the experience on several models: MBA11 and MBP41 fall into the same category as your MBP51. The readings are low, but the full span 0-255 is actually used, which can be seen when exposing the sensor for extreme light. The real problem seems to be that neither the kernel nor gnome is equipped to handle sensor readings with such a large dynamic range. For instance, the hal interface used by g-p-m is far too course-grained, only allowing integer percentage values.

>is this something specific to the applesmc driver on MBP 5,1

At least on my MBA11, the behavior is precisely the same. This could most likely be improved upon in the driver, it has just not been done.

Alex Murray (alexmurray) wrote :

By improving the driver, do you mean getting it to scale values based upon which machine it is running on to report a larger dynamic range under 'normal' light conditions? This should be relatively straight forward, provided we can obtain some data about which machines report these lower values - do you have access to any other machines which you could provide info for and I'll see what I can do about hacking on the driver.

Ricky Campbell (cyberdork33) wrote :

Alex,

I am pretty sure that the mactel-support team can get most, if not all, of the of the Apple portables covered from users in the forum. Just let us know what you need from each model.

Alex Murray (alexmurray) wrote :

I guess we need to first get the values which the light sensor reports for each of the different models under varying light conditions - then we can identify which models need correcting / scaling for - ie. as I mentioned before my MBP 5,1 reports only 4 out of 255 in a reasonably well lit room so that is one candidate I would suggest - problem is that I think we'll need to be able to easily adjust it - I suggest instead what we do initially is add another sysfs file for applesmc called light_scaling or something similar which can by written to by root and that will then be used to scale the light sensor value by the driver - users can then experiment to find a good value - then for each model we can collect the scaling values which users report working well for them an integrate them into a fixed table in the driver - but we can also leave the light_scaling file available so it can be set manually still. What do you reckon?

Alex Murray (alexmurray) wrote :

See new bug report which I just opened for a patch to add light_scale to applesmc-dkms https://bugs.launchpad.net/mactel-support/+bug/315485

Henrik Rydberg (rydberg) wrote :

Although I am happy that you are looking into this problem, I think the patch is doing the wrong thing:

1. It is introducing more state to the desktop setup - it should be possible to determine the right scaling automatically.

2. The scaling factor in the patch is integral - this is causing all sorts of hysteresis problems, and is the source of the light sensor problem in the first place, since HAL does not treat fractional percent in the dbus interface. Continuing along that track cannot be good.

The problem with the low light sensor reading seems to have to do with the new macbooks, starting with MBP41, via MBA11 to the MAP51. Evidently the interface changed, since the new models report a SMC key length of 10, compared to the old 6. Most likely the applesmc_light_show() could be fixed for those models, since the current code only reports values for the left sensor, although two sensors are present.

Alex Murray (alexmurray) wrote :

Thanks for the feedback rydberg - after looking into it some more it seems the new MBP / MBA's use the 10 byte light value from the left sensor as follows:

first 2 bytes seem to always be 01
next 2 bytes are a big endian 16-bit value of the ambient light value with a maximum value of 65535
next 2 bytes are a big endian 16-bit value of the ambient light value but is somehow scaled down from the first one and perhaps has a different dynamic range
next 2 bytes are a big endian 16-bit value of the ambient light value with a maximum value of 1023
last 2 bytes I got no idea about

So I've cooked up a patch to use the value which reports 1023 as max which just basically divides this by 4 to give us a value which we can return with a maximum of 255 like the max value on the older machines.

It also seems the right sensor doesn't ever report anything so we just return 0 for this.

Please test the attached patch and if possible can this be merged into the applesmc-dkms mactel package?

Alex Murray (alexmurray) wrote :

Actually scrub the previous patch - this one is much simpler and doesn't break the case for the old machines.

Alex Murray wrote:
> Actually scrub the previous patch - this one is much simpler and doesn't
> break the case for the old machines.
>
> ** Attachment added: "Improved patch"
> http://launchpadlibrarian.net/21101822/applesmc-dkms-light-sensor-fix.patch
>

Thank you for the patch! This one seems neat; I will only need to trim it a
little bit to send it to kernel.org. Also thanks for looking into the byte
encoding, these things are surely non-trivial.

Cheers,
Henrik

Hi! How can I use the patch to test in MBP5,1? Is there any step-by-step documentation?
Thanks, Nikos

Sorry for the 2nd post: I am confused. Is this about scaling the sensor readings to have actually ambient light adjust the brightness (display/keyboard) or not?

Alex Murray (alexmurray) wrote :

This patch is about making the applesmc driver report sensible values for the ambient light sensor - it has already been integrated into the applesmc dkms package in the mactel ppa so if you're running that then you've already got it and don't need to do anything with the patch itself.

Thanks for the explanation.

But does it really do its job? I mean, If I use the ambient light sensor checkbox (under in g-p-m), it only brings display brightness down to a certain level ( using an MBP5,1). There is no other reaction against ambient light inensity.

Magnus Blåudd (msvensson) wrote :

Workaround for this bug is to uncheck the "Use ambient light to adjust LCD brightness" which is found on the "General" tab in Gnome's Power management preferences.

The patch is in the source for applesmc-dkms - 0.14.4-0ubuntu1~mactel-support1~jaunty5 from 2009-05-10 but still the screen is randomly dimmed very low after a short time.

Well, I find the whole idea of automatically dimming quite annoying so I'm happy with just turning it off....

Slick (slick666) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. If you could test the current Ubuntu development version, this would help us a lot. If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect <bug #>, and any other logs that are relevant for this particular issue.

I've confirmed that this is not a problem on a MacBook 1,1 using the kernel Linux Macintel 2.6.31-20-generic

Changed in hal (Ubuntu):
status: New → Invalid
Ted Gould (ted) on 2011-03-28
Changed in gnome-power-manager (Ubuntu):
assignee: Ted Gould (ted) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers