** 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 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. + 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. + 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.
** Changed in: gnome-power-manager (Ubuntu) Sourcepackagename: hal => gnome-power-manager ** Changed in: gnome-power-manager (Fedora) Sourcepackagename: hal => gnome-power-manager -- Hardware and software don't agree on brightness level https://bugs.launchpad.net/bugs/295560 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
