Hardware and software don't agree on brightness level

[Andrea Ratto]

Binary package hint: gnome-power

Since Intrepid (and Fedora 10) gnome-power-manager has found a way using xrandr of setting brightness on my laptop (Dell Latitude D630) which interferes with the FN-buttons and the old libsmbios way.

The brightness applet now works decently. It has many different possible levels and change of brightness is continuous, though not immediate. On hardy it worked with 8 levels of brightness, but maybe a little smother.

The FN-keys (in my understanding) instead handle the brightness "in hardware" using 8 possible levels and the BIOS notifies the event to the operating system, so that the user can see a bar indicating the level just set. The BIOS also remember what value is currently set for ac and battery modes on its own, and changes that when power supply changes.

In hardy this way of handling the brightness was the only and so it was coherent. Now having two mechanisms causes confusion between them.

_______________________________________________________________________
The following description is a little complicated, but if you just play around with brightness controls, you will easily see for yourself what I am talking about.

Changing trough the FN-keys is a different story:
It takes 9 key strokes to go from maximum to minimum brightness,
the brightness level indicator that pops out on the screen has 20 steps.
On the contrary going from minimum to maximum requires all the 20 steps, even though some of them, especially the first 4, don't seem to do anything.

This mismatch causes confusion and weird behaviour of gnome-power-manager, as the effective brightness is different than the reported brightness. Basically the screen is never bright exactly as you want it to be... the whole thing is just "buggy".

I tried using dellLcdBrightness and found out that it gets confused too.

It's hard to fully explain, but basically I can easily have gnome think that brightness is 100% when it is actually at minimum or viceversa. That goes for dellLcdBrightness as well.
______________________________________________________________________

A quick way to fix this is to revert to the old libsmbios based mode of handling this laptop's brightness, though it had only 8 levels and did not work with a BIOS password.
Another (nicer) way would be to make the BIOS completely stop handling brightness when gnome-power-manager starts, making the Fn keys normal keys. Can it be done, Dell?
The best way would be to make libsmbios and xrandr agree.

[Mario Limonciello (superm1)]

For the libsmbios task, what makes you think this part is broken? It reports 8 levels, which is likely all your machine supports. When using the command line utility you have to specify if you are plugged into a battery or AC. Are you doing so?

[Andrea Ratto (andrearatto)]

Yes I am doing so.

sudo dellLcdBrightness -a
Read AC Mode Setting
    current: 0
        min: 0
        max: 7

libsmbios worked well in hardy, but now it gets confused too. For example if I do this:
1: Fn+down till mininum brightness
2: raise brightness to the maximum from the panel applet
I end up having about half the brightness, while gnome/hal think it's at 100%, and libsmbios at 0%.

the applet reads and change the brightness in some other way. It also appears to have a lot more possible levels.
I really don't kwnow how it does it, but it does not agree with libsmbios and the fn-keys, so the result is not good.

[Andrea Ratto (andrearatto)]

I did some further investigation and updated the description. I think that some kind of cooperation between all the project marked as affected is necessary, at least for an initial decision.

I would like to know (from Dell?) if the bios can be made stop handling brightness at all from userspace (and if there are errors in my description)

It's now been some time and I like to see this bug at least triaged and acknowledged; especially since it took _me_ a lot to find the cause of that other problem with brightness that caused crashes on Latitudes with a bios password, only to have brightness not working again in a few months.
As of now I think I've done all that I can.

[Mario Limonciello (superm1)]

I don't forsee any method to stop the BIOS from adjusting brightness whtn the FN brightness keys are pressed. On Dell laptops, the xrandr controls should simply not be used I say.

Mario Limonciello
Dell | Linux Engineering
<email address hidden>

-----Original Message-----
From: <email address hidden> on behalf of Andrea Ratto
Sent: Fri 1/9/2009 3:38 AM
To: <email address hidden>
Subject: [Bug 295560] Re: Hardware and software don't agree on brightness level

** Description changed:

- Binary package hint: hal
+ Binary package hint: gnome-power

- The following description is a little complicated, but if you just play
- around with brightness controls, you will easily see for yourself what I
- am talking about.
-
- Since Intrepid (and Fedora 10) Gnome has found a new way of setting
- brightness on my laptop (Dell Latitude D630) which interferes with the
- FN-buttons and the old libsmbios way.
-
- I don't know how it does it, since ACPI does not support brightness setting on my model:
- cat /proc/acpi/video/VID*/LCD/brightness
- <not supported>
- <not supported>
+ Since Intrepid (and Fedora 10) gnome-power-manager has found a way using
+ xrandr of setting brightness on my laptop (Dell Latitude D630) which
+ interferes with the FN-buttons and the old libsmbios way.

  The brightness applet now works decently. It has many different possible
- levels and change of brightness is continuous, though not immediate and
- responsive. On hardy it worked with 8 levels of brightness, but maybe a
- little smother.
+ levels and change of brightness is continuous, though not immediate. On
+ hardy it worked with 8 levels of brightness, but maybe a little smother.
+
+ The FN-keys (in my understanding) instead handle the brightness "in
+ hardware" using 8 possible levels and the BIOS notifies the event to the
+ operating system, so that the user can see a bar indicating the level
+ just set. The BIOS also remember what value is currently set for ac and
+ battery modes on its own, and changes that when power supply changes.
+
+ In hardy this way of handling the brightness was the only and so it was
+ coherent. Now having two mechanisms causes confusion between them.
+
+ _______________________________________________________________________
+ The following description is a little complicated, but if you just play around with brightness controls, you will easily see for yourself what I am talking about.

  Changing trough the FN-keys is a different story:
  It takes 9 key strokes to go from maximum to minimum brightness,
  the brightness level indicator that pops out on the screen has 20 steps.
  On the contrary going from minimum to maximum requires all the 20 steps, even though some of them, especially the first 4, don't seem to do anything.

  This mismatch causes confusion and weird behaviour of gnome-power-manager, as the effective brightness is different than the reported brightness. Basically the screen is never bright exactly as you want it to be... the whole thing is just "buggy".

  I tried using dellLcdBrightness and found out that it gets confused too.
- It only has 8 possible levels.

- It's hard to fully explain, but basic...

[Hongli Lai (honglilai)]

I have a Dell Inspiron 6400, and I confirm this bug after a day of debugging gnome-power-manager. Both gnome-power-manager and the kernel/BIOS/something-that-is-not-gnome-power-manager try to change the brightness when I press the brightness keyboard keys.

How about adding a HAL property that indicates whether the BIOS controls the backlight, and have gnome-power-manager not adjust the backlight (and let the BIOS do it) if this property is true?

[Andrea Ratto (andrearatto)]

my conclusion is that gnome power manager can:
notify change events to the user (brightness bar) (ok here)
dim the screen after a period of inactivity, if user wishes so. (and set it back the previous level) (probably ok too, when the xrandr issue is fixed)

and must not:
1: use xrandr
2: set brightness upon login/battery/ac events

A couple of new gconf settings could give the user enough control to impose this behaviour.
eg brightness_method = auto | hal | xrandr | wathever (fixes 1)
brightness_on_power_change, a boolean (fixes 2) (should also disable "set brightness to" slider in preferences)

[Pedro Villavicencio (pedro)]

One task is enough for now.

[Pedro Villavicencio (pedro)]

if no one provided a link to the fedora bug tracker it makes no sense to keep this open, closing the fedora task. Please only open tasks for another distribution if you have a bug to link to, thanks.