Partially implemented backlight control logic

[Mychaela Falconia]

Hello again everyone,

This explanatory update will probably only be useful to DS as he is
the only person on the planet besides me at the present moment who has
the necessary hardware, but others may find it educational, so here it
goes...

FC Tourmaline firmware has two Luna build targets: luna1 and luna2.
luna1 is for Luna LCD on iWOW DSK board, luna2 is for the same Luna LCD
on FC Caramel2.  If you do a 'diff targets/luna[12].h', you will see
how tiny the differences are: just a few diffs in terms of how some
GPIO and multifunction pins are wired on the two respective
motherboards.  Running the wrong one by mistake should not produce any
catastrophic effects, but if you make this mistake, please correct it
as soon as you notice it.

Past the luna1 vs. luna2 difference, if you get our current Tourmaline
fw running on either of them, you will see some odd behaviour that
requires explanation - so let me explain it now.  The issue is that I
am seeking to implement Pirelli-like backlight control logic, but I
only got it partially implemented, and the current half-implemented
state presents utterly odd behaviour to the uninitiated - but then
this active-development Tourmaline fw is absolutely NOT cleared for
end users at the present stage.

Here is how Pirelli's backlight logic works: when the phone is not in
an active call (idle state or navigating through menus, composing SMS
etc), when the display lights up, there is a 30 s timer running - or
rather 30 s is the default, and there is a menu setting that makes it
longer or shorter.  I find 30 s to be sensible though.  When this 30 s
timer expires without the user pressing any button (and no events like
incoming calls etc), the display goes dark.  When the display is dark,
a special logic is applied to the keypad: any keypad button press that
is made when the LCD is dark is "swallowed", i.e., pressing any keypad
button when the display is dark "wakes up" the phone and lights the
LCD, but the normal action of that button (what it would do when
pressed with a lit display) is suppressed - that's what I mean by
backlight-enabling keypress being "swallowed" just for that display-
on action.  I consider this logic to be essential: if the display is
dark, I want to be able to press any button and have the display turn
on, but take *no* other action.  Motorola's firmware does not have
this keypress swallowing logic, but Mot C139 LCD is just as unreadable
without the backlight as Pirelli's, thus Motorola's fw is deeply flawed
in this regard - just one of many factors contributing to Mot C139
running Motorola fw being unusable for me.

Pirelli's fw applies a further logic complication during active calls:
if you are in an active call, the 30 s backlight timer is replaced
with a shorter 10 s timer, and the LCD never goes totally dark: if you
are in a call and the 10 s timer expires, the LCD backlight intensity
is reduced to minimum and the separate keypad backlight goes out, but
the LCD always remains at least partially lit and readable.  Keypresses
occurring in this state are NOT swallowed: a button press will do its
normal action, and also bring the LCD back to full brightness for the
next 10 s.

I really like Pirelli's approach to backlight logic, and I wish to
fully replicate it (both idle and in-call modes) in FreeCalypso phone
fw, both on our future FC handset hw and on Mot C139.  C139 hw does
not have different intensity levels for the LCD backlight, but in the
call state (active call, 10 s timer expired) my current idea is to
keep the LCD backlight on, but turn off the keypad backlight - the two
are separately controlled on C139 hw just like on the Pirelli.

Now here is the current state of partial implementation of this logic
in FC Tourmaline running on our Luna platform:

* Luna LCD hw does not have backlight intensity control, but there is
an on/off control.

* As it stands right now, our Tourmaline fw never turns off the LCD
backlight, i.e., it remains always on.

* There is a "logical" backlight state (not currently propagated to
the physical LCD backlight control) that is indicated on the PWL LED.
This LED is red on Caramel2, but on iWOW's DSK it is the same green as
the always-on VBAT power LED.

* The 30 s timer and the keypress swallowing logic are currently
implemented; the 10 s in-call timer logic is partially implemented,
but not properly activated yet.

So the bizarre behaviour which you will see if you build current FC
Tourmaline and run it on a Luna platform is that the physical LCD is
always on, never goes out, but when the PWL LED on the Caramel
motherboard is off, any button you press has no action other than
turning that PWL LED on - and when you press that button again while
the PWL LED is on, then it will take its expected action.

It would be trivial to change the code and start actually turning the
LCD backlight on and off when the upper layers say it is time to turn
the display on and off.  But I hesitate to make this change right now
because the 10 s in-call timer is not properly hooked up yet, thus
right now when you are in a call, the regular 30 s timer runs, and
the display would fully go out (in the middle of an active call) if we
were to make the backlight control real.  My preference is to first
properly implement backlight logic transitions between idle and
in-call states, and *then* change Luna backlight control from fake to
real.  But it could be another few months before I go back to active
Tourmaline fw development, so it is currently in limbo...

Hasta la Victoria, Siempre,
Mychaela aka The Mother