Both of these patches have been dropped as of 2.26.1, so I'm marking as
closed. Thanks for the work!
** Changed in: gnome-power-manager (Ubuntu)
Status: New = Fix Released
--
Brightness control is slow and not costant with
90-Add-guarded-brightness-stepping-functions.patch
** Changed in: gnome-power-manager (Ubuntu)
Importance: Undecided = Low
--
Brightness control is slow and not costant with
90-Add-guarded-brightness-stepping-functions.patch
91-Using-guarded-and-scaled-stepping-when-dimming.patch
https://bugs.launchpad.net/bugs/345318
You received this bug
I guess that won't change until hardware developers start building with
linux in mind... A less eloquent solution in the mean time might be to
create a gpmbightness.conf file that users can manually set
GPM_BRIGHTNESS_DIM_LEVELS to suit their needs. This could be parsed
first and if null a default
I have modified the '90-Add-guarded-brightness-stepping-functions' patch in
order to get 12 levels of brightness adjustment, and changed the formulas used
to calculate the next step for decreasing/increasing brightness in order to get
constant steps.
It seems to work good on Samsung NC10.
It definitely decreases the number of steps, but still has 2 too many
for my AAO. I think setting GPM_BRIGHTNESS_DIM_LEVELS to 12 by default
is the problem. Is it possible to set it to the value of
laptop_panel.num_levels as reported by hal? I attached my lshal output
above and it seems to report
Looking at the code in 'gpm-brightness.c', it seems that xrandr is
preferred over hal when both are available. I don't know why but there
is certainly a good reason if it's so.
--
Brightness control is slow and not costant with
90-Add-guarded-brightness-stepping-functions.patch
Is GPM_BRIGHTNESS_DIM_LEVELS set using xrandr? The patch seems to set it
to 12 by default.
+#define GPM_BRIGHTNESS_DIM_LEVELS 12
--
Brightness control is slow and not costant with
90-Add-guarded-brightness-stepping-functions.patch
91-Using-guarded-and-scaled-stepping-when-dimming.patch
No, it's manually set. It was set to 24 in the original patch, I changed it to
12 to get bigger steps.
IMHO this is not a good solution, because a fixed value is not good for
everyone, as you stated.
However, I just modified the original patch, I don't know if there is a more
generic way to set
What about setting it to the value reported by laptop_panel.num_levels
from hal. I borrowed the code below from https://fedorahosted.org/hal-
cups-
utils/browser/systemv/hal_lpadmin?rev=63db99983c74ba8c7efaee60e9b509e986a9204f
for a possible way to incorporate the hal-get-property command. It
It seems that hal support is not always available. For example, 'lshal' does
not report any UDI for backlight on Samsung NC10. Apart from that, it would be
a bad idea to use hal in gpm xrandr functions.
Looking at the code, there are two distinct way to set brightness, xrandr and
hal.
--
It seems that hal support is not always available. For example 'lshal' does not
report any UDI for backlight on Samsung NC10. Apart from that, it's a bad idea
to use hal in xrandr functions.
As I said in a previous comment xrandr is preferred over hal when both are
available, and hal support
As far as I can tell, this is the last Jaunty bug listed on the
AspireOne Community page that doesn't have a workaround. Even though
this bug doesn't limit the ability to change brightness, it is highly
visible. As Ubuntu is trying to make headway into the netbook market,
and the AAO is a very
Here is the output from lshal for my backlight:
udi = '/org/freedesktop/Hal/devices/computer_backlight'
info.addons = {'hald-addon-generic-backlight'} (string list)
info.capabilities = {'laptop_panel'} (string list)
info.category = 'laptop_panel' (string)
info.interfaces =
Also an issue on my AAO. I haven't tried removing above mentioned
patches. If someone posts them or a modified deb, I could have a go at
it. Thanks.
--
Brightness control is slow and not costant with
90-Add-guarded-brightness-stepping-functions.patch
Well I tried installing some older versions (gnome-power-
manager_2.24.2-2ubuntu4 and gnome-power-manager_2.24.2-2ubuntu5) that
should have been released prior to the patches in question. This didn't
seem to change the brightness indicator's step number. I'm not sure if
this was a valid test. If
Did you restarted gnome-power-manager?
--
Brightness control is slow and not costant with
90-Add-guarded-brightness-stepping-functions.patch
91-Using-guarded-and-scaled-stepping-when-dimming.patch
https://bugs.launchpad.net/bugs/345318
You received this bug notification because you are a
I think so. I ran killall gnome-power-manager gnome-power-manager...
That should have done it right? With v4 it switched back to old style meter
and v5 had new style.
On Fri, Apr 3, 2009 at 10:43 PM, Andrea Cimitan
andrea.cimi...@gmail.comwrote:
Did you restarted gnome-power-manager?
--
Hm, I tried dropping the patch on a Samsung NC10 and a Dell Latitude
D430. On both, brightness changes have far too many steps which renders
the brightness keys hard to use.
However, I do not see a difference with or without the patch.
--
Brightness control is slow and not costant with
Ted, do you still remember why those were applied?
gnome-power-manager (2.24.0-1mactel3) unstable; urgency=low
* Nonlinear stepping for smooth dimming
* Patch trimming for upstream
-- Henrik Rydberg rydb...@euromail.se Tue, 28 Oct 2008 02:55:08
+0100
There are no bug references, no tags
On Thu, 2009-03-19 at 16:23 +, Martin Pitt wrote:
Ted, do you still remember why those were applied?
Yes, they were to deal with laptops that have a ton of levels, so you
want to smoothly go through the levels. So if you have a 1000 levels
switching from 10% to 20% shouldn't be a large
it could work well on your macbook but it makes the brightness control
not usable here :)
What will happen in yout macbook without the patch?
--
Brightness control is slow and not costant with
90-Add-guarded-brightness-stepping-functions.patch
21 matches
Mail list logo
