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 _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community