maemo.org Bugzilla – Bug 375
minimum backlight level is too bright at night
Last modified: 2009-04-28 15:34:04 UTC
You need to
before you can comment on or make changes to this bug.
Please consider changing it to the minimum really possible by the hardware. It
is very useful at night in bed when someone sleeps next to you :) Almost every
PDA has this problem and for most of them exist 3rd party utilities to change
the minimum because manufactures underestimate this setting. Or is there
technical reason for not going to the minimum?
Even turning it completely off can be useful on direct sun.
Frantisek, which version of the product image have you been using? AFAIK, there
has been some adjustment in the brightness adjustment along the way.
There really was adjustment for IT2006 beta and it is better, but the
is still too bright when used at night. In fact even the lowest brightness
possible by hardware (see my hack for IT2005
http://fanoush.webpark.cz/maemo/#backlight ) is still too bright (but much
It looks like current 2.6.16 kernel in IT2006 beta changed the
/sys/devices/platform/omapfb/panel/backlight_level maximum from 16 to 127 like
it is in my hack, but the lowest brightness that can be set in the brightness
applet is value 3, not 1.
Can you change the brightness applet to use slider instead of few preset values
(10 steps?) and allow full 1-127 interval?
Also there is interesting gconftool 'registry' setting
(can be seen by executing command 'gconftool-2 -R /system/osso/dsm/display').
When setting this value to bigger value (like 15 o more) the brightness applet
is more fine-grained (after reboot) but only the original first levels are
usable, the new ones use same (maximum) value. Maybe there could be another
gconf list value called possible_display_brightness_values with real brightness
levels. Same method is used already for dim and blank timeouts (can be seen by
gconftool-2 command mentioned above).
I agree. This makes use of maemo-stars outdoors meaningless.
I don't see why the lower limit can't be lowered even more. Upper limit is
This issue got much worse with first OS2008 beta for N800. Minimum brightness
level in UI is now at value 25 and we now have only 5 levels. Is this bug or
feature? If this is feature, can anyone responsible explain rationale behind
Why simple slider with full range available by hardware is not the best and
natural solution to this?
I can see someone even cared enough to implement fancy fade effect when
changing between those 5 hardcoded levels in OS2008. This even increases
frustration since everyone can see now how fine-grained the control of HW
really is but users are stuck with 5 choices.
see also N800-specific bug #1261
copying from bug #1261:
"there's an alternative available that gives you full control
over the backlight: https://garage.maemo.org/projects/adv-backlight/ "
anybody having a N810 also complaining about this?
i set the brightness to the lowest level and when the screen is dimmed (because
of inactivity) there's nearly no difference to before. can't compare to N800 or
(In reply to comment #9)
> anybody having a N810 also complaining about this?
> i set the brightness to the lowest level and when the screen is dimmed (because
> of inactivity) there's nearly no difference to before.
You do it with stock Nokia applet or the advanced applet you mentioned? If you
mean the stock Nokia applet there is difference between N800 and N810. N800
doesn't have light sensor so the brightness of each step is much higher, with
light sensor and N810 each step is much dimmer, this is explained in bug #1261
comment 4 and can be simulated on N810 too (see also comment 3 there for
confirmation of this behaviour on real N800).
The advanced applet uses feature of dsme (and dsmetest binary) in initfs added
in OS2008, which finally allows fine grained brightness control (needed for
light sensor controlled brightness on N810)
chroot /mnt/initfs dsmetest -l x (where x is 0-255)
This means hacking kernel is no longer needed for OS2008 but suggestion to
improve Nokia applet is still valid. Either by using gconf values as suggested
in end of comment 3 here, so we can set our own values (similar 'hackable'
entries are there for list of device inactivity timeouts) or by using full
slider like it is for sound volume as suggested in bug #1261
Agreed - I voted for this and am a n810 owner.
Having said that, knowing about the workaround now (via this bug report) using
the third-party app makes it a lower priority for me. Having said /that/
though, I suspect a relatively small proportion of tablet owners will be
looking in maemo bugzilla and given 21 votes at time of writing (high compared
to the average on here), it seems like a worthwhile enhancement for future
Removing keyword moreinfo. The questions asked have been properly answered long
ago. Also, thanks for the additional info.
See my comments in Bug 1261
Could be considered this bug as 375 the same? At the end what is being
requested is the possibility to let the user define brightness 0-100%
I think that a possible solution for bug #1261 could be a solution for this
This would indeed be fixed by fixing bug 1261, hence adding dependency.
Quim: As bug 1261 will be fixed for Fremantle, can this also be closed as FIXED
(Quim has much more access than I have to such information, hence asking.)
Fixing requires changes that are too heavy to backport though, so for Diablo
this is definitely a WONTFIX.
Closing as FIXED for Fremantle as per last comment.
This is WONTFIX for Diablo.
Setting Target Milestone to Fremantle SDK beta.