| 2008-11-08 13:59:55 |
Andrea Ratto |
bug |
|
|
added bug |
| 2008-11-08 14:00:58 |
Andrea Ratto |
bug |
|
|
assigned to libsmbios |
| 2008-11-08 14:01:33 |
Andrea Ratto |
bug |
|
|
assigned to gnome-power |
| 2008-11-08 14:02:28 |
Andrea Ratto |
bug |
|
|
added subscriber The Dell Team |
| 2008-11-26 07:46:33 |
Andrea Ratto |
bug |
|
|
assigned to hal (Fedora) |
| 2008-11-26 07:51:28 |
Andrea Ratto |
description |
Binary package hint: hal
Since Intrepid 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>
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.
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 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 model's brightness, though it had only 8 levels and did not work with a BIOS password. |
Binary package hint: hal
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>
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.
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 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 model's brightness, though it had only 8 levels and did not work with a BIOS password. |
|
| 2009-01-09 09:38:05 |
Andrea Ratto |
description |
Binary package hint: hal
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>
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.
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 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 model's brightness, though it had only 8 levels and did not work with a BIOS password. |
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. |
|
| 2009-01-09 09:38:42 |
Andrea Ratto |
hal: bugtargetdisplayname |
hal (Ubuntu) |
gnome-power-manager (Ubuntu) |
|
| 2009-01-09 09:38:42 |
Andrea Ratto |
hal: bugtargetname |
hal (Ubuntu) |
gnome-power-manager (Ubuntu) |
|
| 2009-01-09 09:38:42 |
Andrea Ratto |
hal: statusexplanation |
|
|
|
| 2009-01-09 09:38:42 |
Andrea Ratto |
hal: title |
Bug #295560 in hal (Ubuntu): "Hardware and software don't agree on brightness level" |
Bug #295560 in gnome-power-manager (Ubuntu): "Hardware and software don't agree on brightness level" |
|
| 2009-01-09 09:39:10 |
Andrea Ratto |
hal: bugtargetdisplayname |
hal (Fedora) |
gnome-power-manager (Fedora) |
|
| 2009-01-09 09:39:10 |
Andrea Ratto |
hal: bugtargetname |
hal (Fedora) |
gnome-power-manager (Fedora) |
|
| 2009-01-09 09:39:10 |
Andrea Ratto |
hal: statusexplanation |
|
|
|
| 2009-01-09 09:39:10 |
Andrea Ratto |
hal: title |
Bug #295560 in hal (Fedora): "Hardware and software don't agree on brightness level" |
Bug #295560 in gnome-power-manager (Fedora): "Hardware and software don't agree on brightness level" |
|
| 2009-01-09 09:50:58 |
Andrea Ratto |
bug |
|
|
assigned to hal |
| 2009-01-22 11:01:11 |
Andrea Ratto |
gnome-power: status |
New |
Unknown |
|
| 2009-01-22 11:01:11 |
Andrea Ratto |
gnome-power: importance |
Undecided |
Unknown |
|
| 2009-01-22 11:01:11 |
Andrea Ratto |
gnome-power: statusexplanation |
|
|
|
| 2009-01-22 11:34:15 |
Bug Watch Updater |
gnome-power: status |
Unknown |
New |
|
| 2009-01-28 18:08:36 |
Pedro Villavicencio |
gnome-power-manager: status |
New |
Triaged |
|
| 2009-01-28 18:08:36 |
Pedro Villavicencio |
gnome-power-manager: importance |
Undecided |
Low |
|
| 2009-03-13 14:56:32 |
Pedro Villavicencio |
libsmbios: status |
New |
Invalid |
|
| 2009-03-13 14:56:32 |
Pedro Villavicencio |
libsmbios: statusexplanation |
|
|
|
| 2009-03-13 14:57:04 |
Pedro Villavicencio |
hal: status |
New |
Invalid |
|
| 2009-03-13 14:57:04 |
Pedro Villavicencio |
hal: statusexplanation |
|
One task is enough for now. |
|
| 2009-03-17 13:54:53 |
Pedro Villavicencio |
gnome-power-manager (Fedora): status |
New |
Invalid |
|
| 2009-03-17 13:54:53 |
Pedro Villavicencio |
gnome-power-manager (Fedora): statusexplanation |
|
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. |
|
| 2010-09-16 19:27:40 |
Bug Watch Updater |
gnome-power: importance |
Unknown |
Medium |
|
| 2012-03-27 16:25:59 |
Bug Watch Updater |
gnome-power: status |
New |
In Progress |
|
