[Sugar-devel] automatic backlight control
bert at freudenbergs.de
Mon Nov 21 12:38:42 EST 2011
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
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.
- Bert -
More information about the Devel