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:
