Subject: Re: LEDs, LCDs and so on (was Re: More SPARCbook insanity )
To: Sean Davis <>
From: Michael <>
List: tech-kern
Date: 04/16/2005 21:54:15
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable


> > > What I'd like to see it do is show a spinning / in the LCD when
> > > loading NetBSD like Solaris does :-)
> > When /loading/ NetBSD - then you'd have to hack the 2nd stage boot load=
> Ah, true. Perhaps that could be some sort of luxury ofwboot for tadpole
> people maintained in pkgsrc.
Yeah, only someone would have to write it :p
I don't know how much bigger the loader would become ( after all we'd have =
to feed the microcontroller interface ) - definitely very far down on the t=
odo list.

> > > (I have yet to figure out why I like those spinning bars so much,
> > > but... oh well :)
> > It's useful :)
> > Hmm, we'd have to come up with a generic interface to CPU-controlled LC=
> > LEDs and do on found on various hardware - we don't want anything
> > Tadpole-specific in - say - sd...
> True. I can think of one other system I would have liked it on, the
> AlphaStation 600 5/266 I used to have, but it died long ago (PSU blew and
> toasted almost everything in the system).
What a pity :/

> However, I suspect there are a
> bunch of systems out there with LCDs and LEDs and such that can be tinker=
> with.
Some IBM boxes have LCDs, lots of laptops have LCDs or LEDs.

> We could have an MI interface to control LCDs and LEDs, and MI hooks
> where they need to be to do the real work.
Exactly. Hmm, there would be at least 4 types of indicators - simple on/off=
 switches ( like PCMCIA card present or not ), 'tickles' ( things that turn=
 themselves off after a while, like network- or disk activity because here =
we can only indicate activity, not inactivity. This would need a kernel thr=
ead to turn off everything that wasn't tickled for a specified amount of ti=
me, could sleep most of the time and only wake up once a second or so ), me=
ters ( number displays, LED rows and so on ) and plain text displays. The d=
river would need to export a bunch of functions - one where a driver can re=
quest an indicator ( we'll need a bunch of standard definitions ) which ret=
urns a cookie or zero ( no such indicator ), and then one for each type of =
indicator that gets the cookie and a parameter ( or just the cookie for tic=
kles )
It would be desirable that this thing works well with envsys, apm and frien=
ds - think CPU temperature and such, especially on the SPARCbook it would b=
e interesting to display the case temperature.

> This reminds me of the BLINK option to blink the power LED according to l=
> average, so there is precedent, after all.
HP300 has a heartbeat LED, it stops beating when the kernel exits or panics=
. Inherited from HP/UX I guess. Then there are the LED-columns on the BeBox=
 which indicate CPU load. So we'd have to support both cases - more than on=
e instance of each type of indicator ( like those two LED columns ) and a s=
ingle indicator handles multiple clients ( more than one disk but only one =
activity indicator. Only one 'card present' indicator but two PCMCIA slots )

have fun

Content-Type: application/pgp-signature

Version: GnuPG v1.4.0 (NetBSD)