"Display brightness" adjustable but does nothing when "Adjust automatically" is on

Bug #1314678 reported by Matthew Paul Thomas on 2014-04-30
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
powerd (Ubuntu)
Wishlist
Unassigned

Bug Description

Ubuntu 14.10 r2

1. Navigate to System Settings > "Brightness".
2. Check "Adjust automatically".
3. Drag the "Display brightness" slider.

What happens:
2. The emitted brightness changes to the automatic value, but the slider does not move.
3. Nothing.

What should happen:
2. The slider jumps to the automatic brightness value.
3. The emitted brightness changes, matching the slider.

<https://wiki.ubuntu.com/BrightnessAndDisplays#Phone>: "Therefore, the “Display brightness:” slider should be sensitive regardless of whether 'Adjust automatically' is checked or unchecked. If it is checked and you adjust the brightness manually, the function that determines the automatic brightness should be adjusted such that, in future, the current ambient light value would result in your just-chosen brightness being chosen automatically."

Iain Lane (laney) wrote :

Thanks.

In this case system-settings is sending the values to powerd (via indicator-power); it is for powerd to implement the desired algorithm and to . I'm reassigning the bug there.

I think what's needed

For (2) - powerd to have a property and change signal for the current brightness so that when you toggle auto-brightness this value is updated; then indicator-power need to be taught to notice and will relay it to us
For (3) - the algorithm in the spec needs to be implemented

affects: ubuntu-system-settings (Ubuntu) → powerd (Ubuntu)
Changed in powerd (Ubuntu):
status: New → Confirmed
Changed in powerd (Ubuntu):
importance: Undecided → Wishlist
Evan Wang (wsy324) wrote :

Exists the same issue with build r179 on Arale phone.
When "Adjust automatically" is on, manually adjust brightness does not work.

$ system-image-cli -i
current build number: 179
device name: m75
channel: ubuntu-touch/vivid-proposed
last update: 2015-04-21 18:09:15
version version: 179

Matthew Paul Thomas (mpt) wrote :
Download full text (4.1 KiB)

This info was written by Seth Forshee (~sforshee) in February last year:

Android requires devices supply an xml config file that defines a number of brightness parameters. Among these is a table which defines ambient light sensor levels and the corresponding brightness which should be used at that ambient level. powerd supports reading in these files (currently they're located in
/usr/share/powerd/device_configs/config-<device>.xml). When autobrightness is enabled powerd requests ambient light level updates and maintains two moving averages of the ambient brightness, one "slow" and one "fast".

The slow average responds more slowly in changes to ambient brightness. It's used to decide when the ambient brightness has changed enough to trigger a reevaluation of screen brightness. This avoids too frequently changing the brightness for temporary ambient changes, e.g. quickly passing by a window.

Once the delta in slow average exceeds a hysteresis value, the fast average is used to determine the new brightness level. If the slow average were used the adjustment is too gradual, so using the fast average gets us to the new "ideal" brightness more quickly while still filtering out very brief transients and jitter in the sensor readings.

Once we've initiated a brightness change powerd will do a sort of polling every couple of seconds until the brightness level is at the ideal brightness for the ambient, within a hysteresis. In my testing it usually got within the hystersis on the first try, but occassionaly it required 2 or (rarely) 3.

Also a note about the ambient to screen brightness mappings. The table we get from android requires interpolation between the points. powerd uses monotonic cubic spline interpolation for this, because that's what Android uses for the same values (and it seems like an exceedingly reasonable choice besides).

So regarding your proposal. With what's there today we start with is a set of default manually defined brightness points which has been provided by the device manufacturer, which when combined with the
interpolation gives the mapping function you described. What would be missing is a algorithm to make adjustments to the table based on user feedback, APIs for making these adjustments, and a non-volatile location for storing the table after user changes have been made.

You seem to have an algorithm in mind, so I won't dwell on that, except to make one comment. What you seem to be trying to do is provide a way for the user to say, "map the ambient brightness level at this particular moment to the screen brightness I give you." The concern I would have about this would be races, i.e. the ambient brightness level changing such that the user-supplied brightness gets mapped to an ambient brightness other than the one which was intended. That said, I can't think of a better way to let the user tweak the autobrightness levels.

I think you should consider storage before the API, i.e. who will be storing the new user table. As of right now powerd doesn't store any user settings, and the widely agreed upon plan has been that as a system service it should not store user settings. If that model is maintained then the shell w...

Read more...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers