[Sugar-devel] automatic backlight control

[Bert Freudenberg]

On 21.11.2011, at 18:06, Paul Fox wrote:

> bert wrote:
>> On 21.11.2011, at 15:22, Paul Fox wrote:
>> 
>>> it quickly became clear (to me, at least) that it would be confusing
>>> if user-dimming behaved differently than auto-backlight-control, with
>>> respect to monochrome mode.  whether or not it's confusing to the
>>> user, it's definitely confusing to the code, since it's difficult to
>>> always do the right thing if the user and the sensor are both changing
>>> the brightness at the same time.  so i disabled the switch to
>>> monochrome entirely -- using the brightness keys doesn't change the
>>> color/mono setting.
>> 
>> IMHO (and not having tried it yet) the current behavior (switching
>> to mono when manually reducing brightness) is fine, and the best
>> compromise we found so far.
> 
> have we actually tried anything else?  the coupling of monochrome to
> brightness has been this way forever, as far as i know.

I remember the command line interface, and some GUI tool with checkboxes. Admittedly that's from before the XO-1 was even mass-produced. But I do remember discussing how the keyboard control should work.

> honestly, i'm surprised people consider this coupling to be so
> important.

I personally would like to have a way to toggle it on and off all the time, independent of backlight brightness. I'm just saying coupling it to the brightness control is a brilliantly simple way to make it work for users who aren't even aware of the details.

>  given how subtle the difference between color and mono
> modes with the backlight off, i really doubt most users would even
> notice the change.

To me it's striking how much sharper the image gets all of a sudden. But then I do have a graphics background and am a hobby-typophile.

Most users wouldn't consciously notice the change, agreed. But that's not the same as saying it doesn't matter.

>> When you add the auto-turnoff, it should only toggle the backlight,
>> not the mono-color setting.  I don't think that would be too
>> confusing, from a user's POV it just means when it's bright
>> outside, the backlight's power gets cut.
>> 
>> I can see how it would lead to confusion if you map this desired
>> behavior onto the existing olpc-brightness command.  What's needed
>> I think is an additional "override" independent of the brightness
>> setting that just turns the backlight off.  Everything else would
>> stay the same.
> 
> it's not that easy.  unless neither brightness mechanism messes with
> the mono setting, then they need to be coupled somehow.  otherwise
> if the backlight is auto-offed (still color), then the user uses the
> "dim" key (no brightness change, but now mono), and then the backlight
> auto-ons, it will now be in mono.

That's not what I had in mind. Taking your example, the display would not auto-on since the user explicitly set it to off.

Auto-off should be completely independent of the user adjusting the brightness. E.g.:

Brightness is set to 10. User goes outside, ambient sensor overrides, turning backlight off. User presses brightness-down, level is set to 9. Backlight is still overridden due to ambient light. User goes inside, ambient override stops, backlight comes back on at level 9. 

See what I mean? The user shouldn't have to care about the ambient light sensor turning off the display. All the controls would still work the same. Just like on older XOs.

> do you also object to the new color/mono toggle, via the control
> key (or via the UI)?

Not at all.

> please try os12, when available, and see how it feels.
> 
> paul


Will do.

- Bert -