Regression: In dark conditions autobrightness does not adapt

[taiebot65]

OS ubuntu 15.04
since bq-aquaris.en/mako r.380 autobrightness does not work anymore
See comment #17 for a better description of the bug

[Pat McGowan (pat-mcgowan)]

Not working at all or not well? or not every boot?
I have 381 here and brightness is adjusting

[taiebot65 (dedreuil)]

I mean the autobrightness. i can turn off autobrightness and adjust the brightness manually but the auto brightness do not trigger anything anymore.

[taiebot65 (dedreuil)]

Sorry did not answer properlly. On 381 i cannot get it working even after rebooting. On 379 it was working on some boot but since 380 it has not worked at all.

[Jean-Baptiste Lallement (jibel)]

381 is the release of repowerd.
I noticed than on arale, autobrightness is much slower and it takes several seconds to adjust in bright light.

[Alexandros Frantzis (afrantzis)]

@taiebot65

Can you please attach the /var/log/repowerd.log file?

[Jean-Baptiste Lallement (jibel)]

I ran the following test several times:
- In sunlight, disable autobrightness
- Set the brightness to the minimum
- Enable autobrightness

it takes on average 4.5s to adjust on arale/rc-proposed

[Alexandros Frantzis (afrantzis)]

@jibel

> it takes on average 4.5s to adjust on arale/rc-proposed

That's a normal amount of time for autobrightness changes. Note that we are using Android's autobrightness algorithm with a "debouncing" delay of 4s (which is what powerd was using, and what Android is using). Of course, we can reduce the debouncing delay, the trade-off being increased susceptibility to transient light changes.

[Alexandros Frantzis (afrantzis)]

> Regression: Rc-proposed Nexus 4 autobrightness does not work
> since r.380 autobrightness does not work anymore

Is this information correct? Nexus 4 (mako) has rc-proposed image revisions in the 500's range, MX4 (arale) in the 300's range. Which device is this bug about? Is the correct image type being used on the device?

[Alexandros Frantzis (afrantzis)]

> > Regression: Rc-proposed Nexus 4 autobrightness does not work
> > since r.380 autobrightness does not work anymore

> Is this information correct? Nexus 4 (mako) has rc-proposed image revisions in the 500's range, MX4 > (arale) in the 300's range. Which device is this bug about? Is the correct image type being used on > the device?

OK, mystery solved, the bug reporter is using the bq-aquaris.en/mako channel (not the ubuntu/mako channel).

[taiebot65 (dedreuil)]

OK sorry I have realized it does work after 4.5 sec.But the behaviour changed it used to when enabled changed straight away. Now it takes 4.5sec before changing. Previous behaviour brightness off turning britghness on you could see the change straight away. Current behavior turning it on it takes 4.5 sec to change. That is why I got confused and thought it was not working anymore. I thought it was broken.

[taiebot65 (dedreuil)]

BTW it does not work at the moment. so i suppose this bug is valid. I had a look there is no log file in /var/log for repowerd

[Alexandros Frantzis (afrantzis)]

Can you check whether repowerd or powerd is running:

ps -Af | grep powerd

Also please attach /var/log/syslog

[Alexandros Frantzis (afrantzis)]

> Can you check whether repowerd or powerd is running:
> ps -Af | grep powerd

Please attach the full output of the command, as there are other services with suffix 'powerd' (e.g. upowerd) that are not related.

[taiebot65 (dedreuil)]

OK I have found the error. Brightness does work but the first reading can be buggy. Put yourself in a very dark room put autobrightness to off and put the brightness level to max and put back autobrightness to on. This will never reduce the brightness. However turn a light on put the phone under it and here you can see that autobrightness is working and when you turn back off the light, the brightness level goes to the level it should have been in the first place when you turned on autobrightness.

[Pat McGowan (pat-mcgowan)]

Compared 2 MX4s, stable and proposed, Stable adjusts immediately to a new value, then may readjust later. Proposed does not adjust for at least 4 secs sometimes more

[Pat McGowan (pat-mcgowan)]

My last comment, I was referring to when auto is initially turned on, the behavior is different. The real concern is when it is on and needs to immediately adjust to current conditions as when removing from a pocket.

[taiebot65 (dedreuil)]

I think i should re-title this bug because brightness works but it does not adapt properly.

For my understanding the real bug is the brightness will only adapt if there is a difference between two readings within 4.5 sec when it is turned on. So in very dark conditions when your phone is turned on there in no variation in brightness and the phone stays at the original brightness that when you turned it off (see comment #14) which could be really bright.

To easily reproduce this bug follow this steps.

>Turn off auto brightness.
>Put manually the brightness to maximum
>Cover the proximity sensor with your finger
>turn on auto brightness

==> expected the brightness to be corrected from maximum to minimum

Bug => As long as you keep your finger on the sensor the brightness is kept to maximum.
As soon as you remove your finger from the sensor and approach it from a light source, count 4.5 sec and you will see the brightness changing cover the sensor again and 4.5 sec later it will be at minimum brightness where it should have been.

In user case. In a dark room when you turn on your phone the brightness will never change (That's the reason i thought the brightness was broken)

[Alexandros Frantzis (afrantzis)]

The problem was that the autobrightness algorithm was too slow to react to the first light values after being enabled. This caused both the related issues mentioned in comments in this bug (taeibot65's and jibel's).

The fix is in silo 31 and in the process of being merged:

https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-031/

in case anyone wants to try before it reaches the stable-phone-overlay PPA and an image.

To install follow the instructions here: https://wiki.ubuntu.com/Process/Merges/TestPlans/repowerd

[Alexandros Frantzis (afrantzis)]

After some more experimentation with this fix, I noticed a strange behavior on Nexus4. When autobrightness is enabled and the screen turns on under bright light, the updated repowerd autobrightness algorithm transitions the brightness to a high value (as expected), but the N4 display sometimes doesn't react to this high brightness setting, remaining at an arbitrary lower brightness setting instead. It seems that it takes a screen content update to "remind" the Nexus4 display that the brightness has changed.

This problematic behavior is not present on other devices (krillin, arale), and all findings point to some system layer below repowerd as the culprit.

This Nexus4 behavior doesn't affect the validity of the proposed fix, since repowerd itself is doing the right thing. I will file a new bug for this Nexus4 specific issue when the fix for this bug lands in the image, so that the problem is easy for others to reproduce.

[Selene ToyKeeper (toykeeper)]

On krillin and arale, this appears to be fixed by silo 31. The fix actually allows the brightness to update even faster, by toggling autobrightness off then immediately back on. By doing that, it can update in less than a second instead of the usual 4.5 seconds. And it actually does update now (immediately) instead of waiting for the first change after it's enabled.

In any case, seems to work fine.

[Launchpad Janitor (janitor)]

This bug was fixed in the package repowerd - 2016.08.2+16.10.20160823.1-0ubuntu1

---------------
repowerd (2016.08.2+16.10.20160823.1-0ubuntu1) yakkety; urgency=medium

  * New 2016.08.2 release
    - Fix "Regression: In dark conditions autobrightness does not
      adapt" (LP: #1613871)

 -- Alexandros Frantzis <email address hidden> Tue, 23 Aug 2016 14:22:58 +0000

[Alexandros Frantzis (afrantzis)]

> After some more experimentation with this fix, I noticed a strange behavior on Nexus4.
<snip>
> ... but the N4 display sometimes doesn't react to this high brightness setting, remaining
> at an arbitrary lower brightness setting instead. It seems that it takes a screen content
> update to "remind" the Nexus4 display that the brightness has changed.

An update: In the latest package release 2016.08.2+16.10.20160823.1-0ubuntu1 I have provided a workaround for the Nexus 4, by applying the last normal brightness value before letting autobrightness take over when turning on the display. This is not ideal, but it's what powerd did in the past, and fixes Nexus 4 to have a quick reaction time.

Note that this workaround applies only to Nexus 4. Other devices use the autobrightness setting directly when turning on the display (and autobrightness is enabled, of course), providing a smoother display-on experience.

[taiebot65 (dedreuil)]

Little feedback everything is working ok apart from on first boot. If you are in a dark room on a first boot it will not adapt.