[Sugar-devel] automatic backlight control

[Kevin Gordon]

On Mon, Nov 21, 2011 at 9:22 AM, Paul Fox <pgf at laptop.org> wrote:

> this note is kind of long for what seems like a simple feature, but
> there are some complications i'd like feedback on.
>
> i've implemented one of the more amusing features of the 1.75 laptop,
> which is using its ability to monitor ambient light levels in order to
> turn off the backlight automatically when you're in bright enough
> light where you really don't need it -- i.e., mostly when outside in
> full sun.  support for this feature is in the os11, but it's buggy --
> os12 will be quite a bit better.
>
> this isn't an auto-dim feature -- in bright sunlight, the backlight is
> turned off, and when the environment isn't bright enough, the
> backlight is returned to its previous level.  it's on or off --
> nothing in between.  (the _very_ inexpensive light sensor isn't really
> sensitive enough to allow for finer-grained control than this.)
>
> in working on this, i was reminded that currently, when we manually
> dim the backlight level to 0 (i.e., turn it off) with the keyboard
> keys, we also change the display's mode from color to monochrome.
> switching to mono mode effectively raises the screen resolution,
> giving crisper characters and lines. [1]  to my knowledge, this is the
> only way in which monochrome mode can be invoked.
>
> my auto-backlight code did this too, at first, but once backlight
> control starts happening without user input, this "auto-monochrome"
> feature is a bit annoying.  it looks much better if turning off the
> backlight (which happens in full sunlight) doesn't remove the residual
> color which was there moments before, when, say, a cloud was in front
> of the sun.  (you can see this effect on your XO:  take it into full
> sunlight, and reduce the brightness all the way.  then alternately
> bump it to '1', then back to 0, and you'll see the bit of color that
> gets gained and lost.)  so -- when automatically turning off the
> backlight, i don't switch the display to monochrome.
>
> 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.
>
> but monochrome mode has it's advantages, and in the past i've had
> requests that it should be more available, rather than less.  to that
> end, i've added the ability to force the screen into monochrome
> "hi-res" mode manually -- when enabled, it remains monochrome no
> matter what the brightness is set to.  this essentially makes the
> higher display crispness available indoors as well.  this toggle is
> available with Ctrl-Brightness-Down (for mono) and Ctrl-Brightness-Up
> (for color).  it's also available on the commandline, by
> using"olpc-brightness [mono|color]".
>
> finally:  because i think the user experience needs to be uniform
> across the laptops, these changes will affect XO-1 and XO-1.5 too,
> even though they have no auto-backlight control.
>
>
> i've already had some guarded negative feedback on both of these
> new behaviors, so i'm looking for more of that, as well as positive
> feedback to balance it out.  :-)
>
> the criticisms were that roughly that:
>    1) getting rid of "monochrome when dimmed to 0" is a major UI
>        change.
>
>        for my part, i'm not sure i agree that it's so major a change.
>        plus, i'm not sure the feature was well implemented in the
>        first place.  (i.e., why no mono mode with the backlight on?)
>
>    2) the replacement color/mono control is completely undiscoverable.
>
>        i guess i'd have to agree with this.  there should probably be
>        a UI control for the toggle as well, but i'm not sure it's an
>        important enough feature to warrant frame real estate, for
>        example.
>
>
> please discuss.  i realize it's hard to talk about this in the
> abstract, since most of you don't have 1.75 machines to play with.
> if you do have one, please try it when os12 comes out.
>

Not sure if I have gleaned all of what is desired here, but I will share my
experience.  I have a Samsung N130, a Lenovo S10-2, and an Adam Notion Ink
all with Pixel Qi screens.  Turning the backlight off and automatically
being in monochrome is a desired feature and matches the usage pattern.
Initiating the change to brightness by keystroke, instead of via ambient
light, is also a feature. .  Letting the transreflective aspect of the
screen in mono do it's thing, is also a feature to me.  Of course, turning
off the backlight is accomplished by using  an fn-f2 on one box, an fn-f4,
on another and a special feature key on the last; but, who's looking for
standards?  :-)

I  also  have a another three of all the same devices with their factory
standard LCD screent.  Brightness down to 0 on a colour LCD screen, or
turning the backlight off, (without the transreflective screen in
monochrome) gives me unreadable screens in any light conditions.  Down to 1
and staying in colour is fine enough, imo.  Backlight off direct to mono on
the PQ is fine with me too, imo.  Again, just from my point of view,
auto-dim was one of the most disturbing UI changes to Lion on the Mac, and
one which most of our Mac users have elected to defeat.  One person's user
experience feature can become another's defect.  (Tap-to-click anyone? )
So, if there becomes an ambient light control that in turn auto-dims or
changes mode handling or the screen, I would like there to be an easily
configurable UI to disable that feature.  My 2 cents.

Cheers,

KG


> paul
>
> [1] http://wiki.laptop.org/go/Display#The_theory
> =---------------------
>  paul fox, pgf at laptop.org
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20111121/d14f3eb7/attachment.html>