Andy Green wrote:
Somebody in the thread at some point said:
| Somebody in the thread at some point said:
|
| | From a user perspective, I still think the aux key makes more sense.
| | It is the largest and brightest led, we need an obvious indication
| | that 'something is going on'. If the aux leds are used for any other
| | indications, we should synchronize this, as in, 'aux leds are for
| | indications' whether that be charging, new message, missed calls,
| | etc. That's the idea.
|
| OK, but presumably we want the other indications to still work if we are
| charging (and the LED is then fixed on).
|
| I think we can make everyone happy by folding this into the /sys thing,
| so you echo a bitfield in to get the various indications, but we need to
| straighten out what "indications" are and how they behave if we are
| charging or not, or if there are more than one active (ie, missed a call
| but there is a new message also). Can you define this for us?
Here's one way... the LED cycles through 6 x 1-second "slots". The
following patterns can appear in a slot:
~ ------------ (no indication, when on battery)
~ ++++++++++++ (no indication, when charging)
~ ++++++------ (eg, SMS came)
~ -++--++--++- (eg, missed calls)
~ +-+-+-+-+-+- (whatever userspace says it means)
~ -----++----- (whatever userspace says it means)
If no indications are enabled, we just see the charging status in all 6
slots like this patch already does it.
~ ++++++++++++
~ ++++++++++++
~ ++++++++++++
~ ++++++++++++
~ ++++++++++++
~ ++++++++++++
The first two slots always show no indication anyway so we can see
charging status at all times. But depending on what we enabled down the
/sys thing, the other 4 slots can be "no indication" or one of the
enabled patterns. When we just have an SMS come on battery, it repeats
this:
~ ------------
~ ------------
~ ++++++------
~ ------------
~ ------------
~ ------------
When it's maxxed out with indications and on charge, it would repeat this:
~ ++++++++++++
~ ++++++++++++
~ ++++++------
~ -++--++--++-
~ +-+-+-+-+-+-
~ -----++-----
How does something like that sound?
-Andy
I would have to say this is not a good idea to have the LEDs being
controlled by the kernel. They should be left to the application layer.