Future Button and LED software spec
thomas at gstaedtner.net
Thu Apr 17 16:29:33 CEST 2008
I support mickeys RFC, because I think, that this usage makes sense and it
especially is what everybody that ever used a smartphone would expect.
Blue for bluetooth (standard on many many devices with BT) and wifi - I'd
suggest slowly blinking for bluetooth (as this might be used heavy for
headset users and so on - slow saves power), fast(er) blinking for wifi
(maybe in combination with displaying activity by flashing slower or
faster), constant on for both.
Same for power - only reasonable position - glowing while charging, blinking
on low-battery (somehow ironic to suck it down even more, but will be a
I also like the idea of the d-bus-events for the aux-led. So this led can be
used for indicating every thing we want, might it be messages (mail, sms,
im) in default mode, or other things by an running application that
overrides it (cellmonitor on cell change e.g.).
Of course we're talking about default settings here, there surely will be a
gui to control it all.
@Werner: do you know - or can you figure out - how many GTA02v5 will leave
the factory and reach the customers?
And how will it be possible to find out what revision it is without powering
On Thu, Apr 17, 2008 at 10:00 AM, Andy Powell <openmoko at automated.it> wrote:
> On Thursday 17 April 2008 02:02, Shawn Rutledge wrote:
> > On Wed, Apr 16, 2008 at 4:42 PM, Werner Almesberger <werner at openmoko.org
> > > Right now, we could only leave them permanently on, which comes with
> > > hefty electricity bill, particularly on GTA02v5 (each LED burns about
> > > 150mW). In GTA02v6, this should come down to about 25mW, maybe less.
> > But GTA02v5 is not going to ship is it?
> > > If all we're really interested in is whether some wireless is active,
> > > perhaps it should just be blink = wlan || bt; People can get the
> > > details from the LCM.
> > Or just use it to indicate that an actual data transfer is occurring
> > (like some ethernet LEDs).
> > If security is implemented correctly, and power drain is also within
> > typical specs, it's normal for Bluetooth to be left turned on and
> > discoverable all the time. (The BT SIG encourages this, but some
> > phone mfgs have overreacted because of past security problems, so they
> > have the default short timeouts for being discoverable, and in some
> > cases BT is actually off by default when the phone powers up, etc. Of
> My preference is that BT is off by default, but what I prefer doesn't
> What should be happening is the device should be restoring the state it
> last in when powered up. So bt/wifi etc will just to what they were doing
> Andy / ScaredyCat
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openmoko-devel