+2 to resetting after s2r cycle.  We may want to condition it to be after Xminutes or x% change in ALS (if applicable) as well but I'd be content w/o that complication initially.

Curious as to if we've heard of feedback on Pixelbook's auto backlight?  I find it too aggressive and am happy to quieten it down using the brightness up/down button.  But I may be an outlier.

I'm mostly annoyed only when it dims & recovers during high speed commute usage.

Could only find this one feedback report ATM:
https://listnr.corp.google.com/product/5015361/report/84938733797

I could see argument for adding a 'disable' auto-brightness button in conjunction w/ this change though for those who would be additionally annoyed after every s2r resetting the disable.

This is a UX question more than anything else. https://chromium.googlesource.com/chromiumos/platform2/+/master/power_manager/docs/screen_brightness.md has some history about how we got to where we currently are.

I agree that we should be having this discussion now that we have a system with frequent brightness adjustments (eve).

I think I'd be on board with making two changes at the same time:

a) Add an "Automatically adjust screen brightness" setting (probably under the "Displays" subpage rather than "Power").
b) Only when that setting is off, restore automatic control after resuming as suggested in this bug.

The setting would be per-user, but we can probably include its current state in the PowerManagementPolicy proto that Chrome already sends to powerd to communicate settings. There are additional open questions, e.g. if we shut down while the brightness is under manual control, should we restore the last-used level automatically at boot?

If someone wants to drive this, please start a doc. This should go through UX review since it'd be adding a new setting.

Drive-by, as I'm browsing brightness-related bugs (currently annoyed by my Eve -- bug 750456)...

I personally hate almost all implementations of "automagic" brightness and turn them off wherever possible. So I'm actually quite happy that I can effectively disable it, as today. If we're going to be more aggressive about re-enabling the magic, then I agree with Dan's (a) and (b)...except:

> b) Only when that setting is off [...]

Did you mean "on"? I'd expect "off" would mean "no automatic brightness".

Other food for thought: would a proposed setting like this cover CABC too, or just ALS? Because CABC is pretty bad right now (bug 750456), and I'd love to turn it off too :)

#6: As to whether I really meant "off" or "on" there... uh, I'm not sure, but I suspect I meant "on". :-/

Thinking about it some more (and again, this should go through UI review, where people are likely to have strong opinions), I think I'd advocate for something simpler to start out with: add an "Automatically adjust screen brightness" setting and automatically uncheck it whenever the user adjusts the brightness. Then we give users an escape hatch if they want to go back to automatic control without rebooting, and we also give people a way to permanently disable automatic control if they want that (i.e. adjust the brightness and don't re-check the setting).

(I'll add that I'm sympathetic, as I'm currently surprised by how poorly my new flagship phone from a large tech company handles automated adjustments. I'm seeing large, unanimated jumps up and down in brightness when using it in stable indoor lighting conditions and don't understand how this feature shipped in this state.)

Just noticed that there's already an earlier bug tracking this.