Future Button and LED software spec

Shawn Rutledge shawn.t.rutledge at gmail.com
Wed Apr 16 22:08:45 CEST 2008


On Wed, Apr 16, 2008 at 12:04 PM, Michael 'Mickey' Lauer
<mickey at vanille-media.de> wrote:
> I recently was informed about some criticism that Openmoko did not specify the
>  button and LED usage, so I went forward and specified it.
>
>  My RFC is @ http://wiki.openmoko.org/wiki/FreeRunner/Buttons_and_LEDs

The button usage looks great to me: seems to be very unsurprising,
what users would expect the buttons to do based on previous
experience.

The LED blink patterns look like a good start, but I suspect they will
tend to evolve over time.  Maybe it ought to be themeable?  We could
just pick a suitable existing language or file format like MIDI or
DJ/club/stage light-control language or whatever, which has some
concept of sections or stanzas that can be triggered by an outside
event.  (I'm not an expert on that.)  DBus events (which signal the
mode change) would trigger different parts of the theme.  The daemon
which listens to the events and switches modes should have the concept
of a baseline phone state and foreground application state.  That way
power management will be mostly in charge (it will send events which
affect the baseline mode), but applications can override some of the
modes by sending their own dbus events.  (An app could set the current
app-level LED mode every time it is brought into the foreground by the
wm, and "pop the stack" by sending a message when it loses focus or
goes into the background.  Or maybe better, the wm could do it by
reading some sort of LED mode property that an application can
optionally export.)

Is there any possibility of PWM on any of the LEDs?  (e.g. to get the
Apple-style "breathing" effect)  Then we need a theme language which
has some concept of intensity or volume, and can express changes in
intensity either piecewise or as functions (sine etc).  If not, for
future phones IMO there ought to be a PWM capability, if the
power-management micro has PWM built-in.



More information about the openmoko-devel mailing list