maemo.org Bugzilla – Full Text Bug Listing
|Summary:||minimum backlight level is too bright at night|
|Product:||[Maemo Official Platform] System software||Reporter:||Frantisek Dufka <dufkaf>|
|Status:||RESOLVED FIXED||QA Contact:||dsme-bugs|
|Priority:||Medium||CC:||andre_klapper, harriv+maemo, karstenb, kevinverma, matt, quim.gil, timeless|
|Bug Depends on:||1261|
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 brightness 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 better). 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 /system/osso/dsm/display/max_display_brightness_level (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 fine IMO.
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 this? 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.
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 N770 though.
(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 releases..
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 too.
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 for Fremantle? (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.