** Changed in: gnome-power
Status: New => In Progress
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-power-manager in Ubuntu.
https://bugs.launchpad.net/bugs/295560
Title:
Hardware and software don't agree on brightness level
Status in Gnome Powermanager:
In Progress
Status in Hardware Abstraction Layer (HAL):
Invalid
Status in The libsmbios project:
Invalid
Status in “gnome-power-manager” package in Ubuntu:
Triaged
Status in “gnome-power-manager” package in Fedora:
Invalid
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-power/+bug/295560/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
