865180 - [settings][display] With "Adjust automatically" enabled, screen brightness changes continuously, erratically

Status: RESOLVED DUPLICATE of bug 1042673

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[Francisco Picolini [:Franc-MH]]

Autoadjust in brightness settings, change the brightness continuously.
Screen has little "jumps" in its brightness when you keep the device awake.
Solution: turn off autoadjust brightness

Comment 1

[Mike Habicher [:mikeh] (high bugzilla latency)]

I see this on every device and it's really jarring--the effect makes it look like my display's backlight is faulty.  One of the first things I do with a fresh install is disable "Adjust automatically" under Settings > Display.

A more civilized approach might be to average the ambient lighting over a few seconds (e.g. 5s) and then pick a target brightness and ramp to that (e.g. over 500ms) and then hold that brightness for at least another 5 to 10s seconds before re-evaluating.

Comment 2

[Mike Habicher [:mikeh] (high bugzilla latency)]

See also bug 816133.

Comment 3

[Alex Keybl [:akeybl]]

Please renominate if this is a new regression, but since it's not a blocker for v1.0.1 or for partners, no need to block for future releases.

Comment 4

[daviddoranmedia]

I noticed this very soon after getting my Geeksphone Peak. I've written a patch that I'm currently trying out here: https://github.com/daviddoran/gaia/commit/fef6324de02887ffacfd5174ffb253f24daa41c7

I've taken the simple approach of requiring some minimum change in computed brightness (e.g. 3%) before I'll actually update the screen brightness. This largely eliminates all the frequent changes and flickering you'd normally experience.
As others have mentioned, the ideal situation is probably:
(1) Large changes in brightness are handled immediately (e.g. walking from a bright room into a dark room);
(2) Smaller changes (e.g. < 10%) are time restricted, e.g. once per 20 seconds.

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to daviddoranmedia from comment #4)
> I noticed this very soon after getting my Geeksphone Peak. I've written a
> patch that I'm currently trying out here:
> https://github.com/daviddoran/gaia/commit/
> fef6324de02887ffacfd5174ffb253f24daa41c7
> 
> I've taken the simple approach of requiring some minimum change in computed
> brightness (e.g. 3%) before I'll actually update the screen brightness. This
> largely eliminates all the frequent changes and flickering you'd normally
> experience.
> As others have mentioned, the ideal situation is probably:
> (1) Large changes in brightness are handled immediately (e.g. walking from a
> bright room into a dark room);
> (2) Smaller changes (e.g. < 10%) are time restricted, e.g. once per 20
> seconds.

That sounds a sane approach. If you implement I would take it and merge it. 20 seconds seems a bit too much. I won't mind having a new settings in build/settings.py to let people customize it since I believe this will also depends on the quality of the hardware of returning false positive.

Comment 6

[daviddoranmedia]

> That sounds a sane approach. If you implement I would take it and merge it.
Great
> 20 seconds seems a bit too much. I won't mind having a new settings in
You may be right. I'll have to play around with the time. The higher the threshold (e.g. 10%) the lower the time would be. I found that when the screen brightness changes unnecessarily it's very distracting, as that normally only happens when the screen's about to turn off.
> build/settings.py to let people customize it since I believe this will also
> depends on the quality of the hardware of returning false positive.
I might let someone else do that if possible. I have no clue about the build system as of yet.

Comment 7

[daviddoranmedia]

I have the new functionality in a branch here: https://github.com/daviddoran/gaia/commits/screen-auto-brightness-2

I'm not sure it solves much, though. Here's the crux of the issue:

The screen brightness UX depends on a few factors: the qualify of the ambient light sensor, the algorithm to determine the optimal screen brightness, the algorithm to decide when it's necessary to actually change the brightness, and the quality of the screen's transition to the new brightness.

Here are my observations based on my Geeksphone Peak:

1) Ambient light sensor -- it's far too sensitive. Sitting on the couch with the phone in hand the calculated brightness can go from 25% to 60% easily, depending on what's directly in the sensor's line-of-sight. It doesn't give you the true "ambient" light really.

2) Auto-brightness algorithm -- it's probably not perfectly tuned but it's fine.

3) The algo to decide whether to update the screen -- here's the tricky part. When you're sitting around using your phone you really don't want the screen changing more than once every few minutes. The problem is that with such a sensitive light sensor it's practically impossible to tell whether the user just walked into a very bright room (we should bump the brightness) or the sensor happened to catch the ceiling light (no need to bump the brightness since the ambient brightness is the same to the user). You can time-limit, smooth, average all you want but it's never going to be very good unless you can trust the ambient light sensor (and I don't).

4) Quality of the screen transition -- at least on the Peak the transition to lighter/darker (even when smoothed by screen_manager) is very noticeable and not particularly smooth.

Comment 8

[Dietrich Ayala (:dietrich)]

I put a patch on bug 816133 to have this feature disabled by default.

OEMs that wish to enable it by default in their distributions should test and configure with the specific device and only enable it by default if an optimal configuration can be achieved on the specific device.

Comment 9

[Benjamin Kerensa [:bkerensa]]

This seems to be happening on the Flame too. Was this ever fixed?

Comment 10

[Dietrich Ayala (:dietrich)]

(In reply to Benjamin Kerensa [:bkerensa] from comment #9)
> This seems to be happening on the Flame too. Was this ever fixed?

Read the comments above. It's "fixed" in that it's off by default. OEMs can turn it on by default if they're able to configure it to a reasonable level of workingness with the particular device.