# Reduce display brightness

asked 2013-12-25 14:40:41 +0300

Is it possible to reduce the brightness of the screen even further as the lowest setting in the UX allows?

Using most of the devices apps without any other source of light is good as long a dark ambiance has been chosen. But after opening the browser and instantly produces an almost 100% white screen that is incredible blinding even at the lowest brigthness settings.

edit retag close delete

4

i have noticed that to...it is very annoying especially if you are in very dark area...

( 2013-12-25 14:42:38 +0300 )edit

Note that with "Adjust automatically" enabled, the lowest brightness level goes darker in a dark environment. It's still not as dark as it could be (compared to wled brightness 1).

( 2014-01-10 06:03:03 +0300 )edit
1

Wouldn't it be solved by the browser having a darker initial background colour until it has loaded the site? Most sites only have parts of the viewport bright white, so starting with a gray background wouldn't blind you as much. It would also remind me of my first browser: Mosaic under OS/2 2.1 :D Adding tag browser to this question.

( 2014-03-16 18:00:22 +0300 )edit

Sort by » oldest newest most voted

answered 2013-12-28 19:40:08 +0300

From this post, writing to the wled LED (/sys/class/leds/wled/brightness) allows the backlight to go lower than 12.

Converted to answer as requested in comment to another answer.

more

2

Thank you! This proves me wrong claiming, that the HW maybe won't allow lower brightnes levels. In combination with the automatic brightness adjustment this is still uncomfortable. Can we turn this into a feature request, that lower of more brightness levels in the UI should be allowed? :-)

( 2013-12-28 21:50:29 +0300 )edit

answered 2014-04-19 07:35:40 +0300

The brightness control will be changed so that

a) in manual mode user can select freely from 1-100% range (instead of the previous 5 step 20,40,60,80 or 100%)

b) the automatic mode has more profiles and the lower ones will allow dimmer backlight than previous ones did

In darkness this can make the dimming very hard to spot, but we are working on that.

more

1

@spiiroin - it is great to read that! Due to the specifics of Jolla UI visuals(transparencies, dimming, etc.) I always felt screen brightness control needs to allow a really high dynamic range. Going really dim in dark situations and really bright in direct sunshine.

( 2014-04-19 09:48:23 +0300 )edit

will there also be an automatic mode without profile? So that it can change the value from 0-100 instead of only 0-20. Nowadays I have to switch between the profiles every night before going to bed and turn it back up when I get outside during the day.

( 2014-04-21 17:09:54 +0300 )edit

@tweek Automatic = uses ambient light sensor profile. There has never been a profile that would use 0-20% range - they all go from N-100%, where N is larger for brighter profiles. Having more profiles just makes it more likely that you can choose a setting that will work most of the times, but there is still a compromise to be made (to compensate for sensor uncertainty at dark environments).

( 2014-04-22 10:35:37 +0300 )edit

@spiiroin In that case the brightness selection algorithm needs an update. If I forget to take my brightness settings off of lowest profile I can't read anything in direct sunlight. When I switch to a brighter profile my brightness instantly goes up.

( 2014-04-23 12:00:39 +0300 )edit

I second @tweek - a better auto management of brightness is need. Currently it does not do the job well.

( 2014-04-23 12:03:30 +0300 )edit

answered 2014-12-29 11:26:21 +0300

After selecting lowest brightness setting via the slider and disabling "Adjust automatically" the backlight brightness at /sys/class/leds/lcd-backlight/brightness should stay at 2 (i.e. 1% of 0-255 range supported by the kernel).

Applications that use bright background colors (e.g. browser & white web page) create related, but separate from backlight control issue - the display is still too bright no matter how low the backlight brightness is set to -> changes need to be made at the side where the display content is drawn/known.

There are plans to take this in to account (and reverse for bright ambient light conditions), but not in the immediate future.

Side note: Update 10 adds ui side fading via compositor to make dimmed display state visible in case backlight brightness is already at so low level that further dimming is not possible.

more

Thank you for the explanaition. I still do not grasp it completely: Obviously the lcd backlight driver does not accept darker settings in /sys. What then could explain, that the display is capable to lower brightnes regardless of the current rendering? Before the display is switched off due to lack of activity, it fades its brightnes in several steps while the content stays the same. Even the darkeset applications gain comfort by these lower levels. Is this fading effect hard coded and not available to user space?

( 2014-12-30 00:37:53 +0300 )edit

@ibins: When display makes transition from "on" to "dimmed" state, the backlight brightness fading from brightness_on to brightness_dimmed is started.

The value of brightness_on is function of brightness setting, adjust automatically setting and lux value from als. The value of brightness_dim is some percentage of brightness_on value -> it is always smaller than brightness_on and some amount of backlight tuning is done. But smaller brightness_on values also mean smaller delta to brightness_dim, i.e. it will be harder to spot the dimming that happens via backlight controls.

Therefore, if difference between brightness_on and brightness_dimmed is small enough:

• The pale blue led pattern is activated
• A "somebody, please make display darker" dbus signal is sent
• Compositor (=lipstick) listens to these signals and animates blending of a black rectangle with whatever ui content that happens to be on screen.

The last part was added in update 10 and makes sure the transition to dimmed state always results in perceivable difference in display brightness.

Technically the same approach could be used to make the ui less bright also while the display is in the "on" state, but it can't be done unconditionally as apps with dark background would get too dim -> needs relatively cpu/gpu friendly way to analyze screen content or/and application side processing.

( 2014-12-30 10:00:47 +0300 )edit

@spiiroin: Now I got it: It is _not_ possible to reduce the brightness of the displays backlight any further, you have to do it with the compositor. This explains why it is not that easy to implement. I can fully understand that this is not priorized higher. I even doubt, that it's worth the effort to program a filter for the screen content to modify the black transparent rectangle only to compensate for the deficiency of the backlights capabilities. This is especially the case as the current hardware does not get any younger in age and will be replace eventually.
Maybe it would be an acceptable compromise in view of effort and effect by simply overlaying the "dumb" and not content aware black rectangle you mentioned with the transparancy of the dimming animation in its middle? The brightness settings would need one more positioning step to the left in order to integrate well to the auto brightness setting.
Downside: As you said: Applications with dark background might get to dim - which I doubt. And: Unfortunatelly a darker setting would not save any battery power, as the real backlight can not be dimmed any further.
Upside: Any brighness reduction is highly appreciated in absolute dark environments in case of bright backgrounded apps.
Anyways: Thank you very much for the insight and the explanation of the problem!

( 2014-12-30 22:24:55 +0300 )edit

@ibins: One idea we entertained was to extent the 0...255 hw range to virtual 0...N+255, where low portion would be done via compositor, pretty much as you suggested. To support something like this the signal content is already "animate to opacity N% in T ms", i.e. compositor just does what it is told to do and actual logic is in mce (where also the rest of the brightness control happens). It would however require largish changes in various state machines & configuration files and producing (perceived as) linear brightness fading curve might not be trivial either (= takes time, more pressing issues have taken priority so far). And potential performance penalty from blending active ui should be investigated too - for dimming this is not an issue as it happens only when the device is not actively used.

( 2014-12-31 09:17:58 +0300 )edit
1

I tried to reduce the min/etc/mce/20als-defaults.iniimal brightness on my Jolla as well. I would like to be the minimal automatic brightness setting to be 2 (or the brightness that echo 2 > /sys/class/leds/wled/brightness results in). I tried changing the "LimitsProfileX"-values and restarted mce, but it does not work:

< LevelsProfile0=1;3;5;7;9;11;13;15;17;19;20;28;36;44;52;60;68;76;84;92;100
---
> LevelsProfile0=1;1;5;7;9;11;13;15;17;19;20;28;36;44;52;60;68;76;84;92;100


As far as I understood, the "LevelsProfile" are applied if the "LimitsProfile" are reported by the light sensor, so what else would I have to change?

( 2016-07-28 11:46:07 +0300 )edit

answered 2013-12-25 17:17:19 +0300

Hm, I found /sys/devices/platform/msm_fb.591105/leds/lcd-backlight/brightness The lowest setting I have seen in this was 12. Writing any lower number into that file does not darken the display significantly. So it seems, the minimal brightness is HW related.

more

4

A solution might be lowering the screen's color temperature. This vastly improves comfort while viewing the screen under low-light conditions. There's an app called f.lux that does this, though it's PC/iPhone only.

( 2013-12-27 02:03:17 +0300 )edit
2

The colour (color) temperature seems a bit high anyway, the colours (colors) would improve if it were closer to 5600 K.

( 2013-12-27 04:39:58 +0300 )edit
2

That might be true! But what I'm really getting at is a dynamic adaption of color temperature depending on what time it is and where on the planet you are situated. This is what f.lux does. But a setting (or an app) that simply lets you control the screen's color temperature would do just fine!

( 2013-12-27 05:01:02 +0300 )edit

@FireFly That's great news! Makes the color temperature thing less of a necessity (but still a desirable feature in my mind). Maybe you should convert your comment into a second answer instead by the way?

( 2013-12-28 19:57:00 +0300 )edit
3

@gukke For linux there's a project similar to f.lux called redshift. It might be possible to get it to run on the Jolla if its display interfaces as a regular display (it should be possible I think).

( 2013-12-28 20:19:44 +0300 )edit

answered 2014-02-13 01:01:27 +0300

Hi, I've found a solution to dimm the brightness until reboot.

Do the following in terminal:

devel-su

(enter passwort to become root)

echo 10 > /sys/class/leds/lcd-backlight/brightness

You can also choose a smaller (min 0) or higher (max 255) value than 10 (default system minimal value is 51). Brightness will change immediately but it doesn't stay because the file will be overriden after switch off/on display. To avoid this do:

chmod 400 /sys/class/leds/lcd-backlight/brightness

Now your settings keep stay until reboot. The permission for writing the file will than be reseted by the system and the default minimum value will be written again.

more

This file is the same than /sys/devices/platform/msm_fb.591105/leds/lcd-backlight/brightness (see answer above). The command "pwd -P" shows this. The problem is, that values lower than 12 don't reduce brigness any more. Using the device in a complete dark environment is still much to bright, especially when using apps with a bright background (like the browser viewing together.jolla.com :-)

Adjusting the value in /sys/class/leds/wled/brightness does reduce brightness - until the automatic adjustion hits again.

( 2014-02-14 22:49:26 +0300 )edit

Ok, you have to disable the automatic brightness setting mode in the ui before editing the file and changing the permissions. I don't use this mode.

After executing 'chmod 400'-command the automatic settings (if you enable it again) will have no effect until reboot.

I wrote the first answer here because the original question ( https://together.jolla.com/question/12372/screen-brightness-adjustment-is-too-bright-even-low-level/ ) was closed and linked to here. So it is just a dirty workaround to reduce the display brightness until reboot.

Yes, I didn't recognize before that a value between 0 and 12 makes no difference. Right, it could be darker or a lower color temperature (espacially apps with bright background). When automatic display setting mode is disabled the minimum ui-slider-value is 51.

Friendly Greetings

( 2014-02-15 00:53:57 +0300 )edit

answered 2015-04-10 00:31:57 +0300

I'm not sure if it can help in any way, but that's what I can see on my Jolla: https://yadi.sk/i/hr2NqcCJftR6D

This is a result of Twilight Android app work (https://play.google.com/store/apps/details?id=com.urbandroid.lux&hl=en) - it not only just dims a display to any selected level, but also can change its color temperature. Unfortunately all this works only inside Android apps, as you can see at the screenshot... (

But maybe there's a way to spread this effect further on the SFOS UI or use it's mechanism (obviously overlaying the screen with selected color) to implement „night mode” on Jolla?

more

answered 2014-02-25 23:08:58 +0300

I wrote a small service and a shell script for automatic doing the dirty 'chmod 400'-workaround (which I described above) during boot time.

Here is the service file (name it for example: changedisplaybrightness.service) which simply calls a shell script.

[Unit]
Description=Change Display Brightness (Dirty Way:)
Before=default.target

[Service]
Type=forking
ExecStart=/path/to/shellScript.sh

[Install]
WantedBy=default.target


Here is the called shell script:

#!/bin/sh
echo 12 > /sys/class/leds/lcd-backlight/brightness
chmod 400 /sys/class/leds/lcd-backlight/brightness


Enter a terminal and become root. Now create (use 'vi' or 'nano') the .service-file inside '/etc/systemd/system'-folder (or copy it with 'cp' or 'mv'). The script can be named and placed how and where ever you want. Just modify the 'ExecStart=/path/to/shellScript.sh'-line in the .service-file and don't forget to make the shell script executable:

chmod +x /path/to/shellScript.sh


Enable the service with the command:

systemctl enable changedisplaybrightness.service


Now the display brightness will be set to the prefered value before entering runlevel 5 at startup. (default.target = graphical.target = runlevel5.target).

more

answered 2014-12-08 12:57:56 +0300

I think it's already released? Update 8 included modification to lower the brightness even lower, therefore the LED is used to indicate screen is turning of in a second because no more dimming is possible with the lowest brightness set.

more

@drummer12 I don't think it is released. In the dark the display is still as bright as before. I could also not see any changes in the settings. Please note that this is not about automatic lowering screen brightness before switching of. It is about lowering the brightness permanently to 1%. That is needed for nighthawks who want to use their phone in the darkness without being dazzled. Edit: I checked what you said about the LED turning on. Yes, you are right, just before switching off, the LED turns blue, but in addition the screen brightness is still lowered even more before the screen actually switches off. And I want to get that lowest brightness as permanent setting.

( 2014-12-09 10:09:46 +0300 )edit

So maybe I'm wrong and it's released in Update 9 because in my case brightness is as low that the display is not able anymore to dim...

( 2014-12-09 10:51:25 +0300 )edit

If you turn of automatic display brightness in my case it's the darkest setting.

( 2014-12-09 10:52:47 +0300 )edit

@drummer12 I have switched off automatic display brightness since long. But I haven't got update 9 yet (the version check says I am up-to-date with 1.0.8). Now I am looking forward to update 9 and hope you are right. :-)

( 2014-12-09 11:00:18 +0300 )edit

## Stats

Asked: 2013-12-25 14:40:41 +0300

Seen: 5,079 times

Last updated: Apr 10 '15