[PATCH 0/5] Power supply and resume ordering meddling

[Michael 'Mickey' Lauer]

On Thursday 01 January 1970 01:08:21 William Lai wrote:

1970???

> Andy Green wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 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?
> >
> > I promise I won't call it a 'spec'.
>
> We don't really have a spec for any indications other than charging.
> If possible, I would do this:
>
> RED non-flashing - battery charging
> GREEN flashing - new message or missed call
>
> So while receiving a new message while charging, the LED gives a
> continuous red, while flashing green (this is off the top of my head).
> Can we do this?

Not with a single color LED which is behind the AUX button.

With the multicolor LED behind the power button, yes... (hint hint...)

:M: