1055965 - [System][Flame] The screen luminosity changes too frequently

Status: RESOLVED DUPLICATE of bug 1042673

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

Description

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

On Flame, when the luminosity setting is set to "auto-adjust", the screen's luminosiy changes too much and too frequently, even when the environmental light does not change much.

This makes the "auto-adjust" functionality barely usable.

It's not as noticeable on other phones I tried, probably because the light sensor is less sensitive. Still we can see the issue too, even if it changes less frequently.

[Blocking Requested - why for this release]:
* One important feature is broken on Flame.

Comment 1

[Andrew Overholt [:overholt]]

Dietrich noted that auto-adjust is very device-specific and is off by default because it needs to be tuned by the device vendor.  Since this is done by those producing the devices, it isn't going to stop us from shipping 2.0.

Comment 2

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

Well, there _is_ some code in apps/system/js/screen_manager.js that seems to be related to this feature. 

What's device-dependent is the light sensor (that we get through the "devicelight" event). In the code we see that we change the screen brightness at each received "devicelight" event. We should use an hysteresis instead to avoid changing the brightness down if we just changed it up, and vice versa.

It's too late for v2.0 now so asking a 2.1 blocking flag. This is merely a way to increase the priority on this, I'd be happy enough if this landed in 2.2. But this is annoying enough on Flame that I'd want it rather sooner than later.

Comment 3

[Gregor Wagner [:gwagner]]

Is this a regression?

Comment 4

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

I think I've seen this in all devices; however on Flame it's much more visible, probably because the light sensor sends data more frequently.

What does it mean? It means that it will definitely happen on future devices as well, but can be tuned at the hardware level.

From what I've seen in the code, it looks fairly easy to hack though. As said previously, I'd be happy enough if it's in the backlog for some team for v2.2. Otherwise, it bugs me so much I might as well fix it myself.

Comment 5

[Dietrich Ayala (:dietrich)]

While I would love to see this fixed (I was the one who landed the patch disabling this by default with tears in my eyes), we reviewed in triage, and this (again) doesn't meet blocking criteria in multiple ways:

* not a regression
* fixed per device by vendor
* didn't block previous releases on it

I'd love to see a fix where some sensor data smoothing was applied, would make our out-of-the-box experience maybe good enough to turn back on! If you have something landed on master soon, ask for approval ;)

Comment 6

[Josh Schmitt [Joshs]]

(In reply to Gregor Wagner [:gwagner] from comment #3)
> Is this a regression?

Removing QAwanted as I believe Comment 5 answers this question.

Comment 7

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

Some work started in bug 1042673