LCDproc development and user support list

Text archives Help

[lcdproc] Current developpement question...

Chronological Thread 
  • From: wwf AT (William W. Ferrell)
  • Subject: [lcdproc] Current developpement question...
  • Date: Sun, 17 Sep 2000 21:18:04 -0600

* Nathan Yawn
(natey AT's
mailer blew these chunks:
> Lemme take a stab at this here...
> OK, hardware setup: you have a Linux/UNIX PC that you wish to monitor
> (or at least, on which to run the LCDd server). You also have a piece
> of Cisco hardware, which has an RS-232 serial port and also a network
> interface (I'll assume ethernet). There is a particular address, port,
> and protocol which can be access via the ethernet interface which will
> send data out the Cisco's serial port, and this same protocol can read
> data back in.
> You want to attach a serial LCD to the serial port of the Cisco, then
> run the LCDproc server on the Linux PC, and have it display to the LCD
> attached to the Cisco's serial port.
> This strikes me as a reasonable thing to do. It also strikes me as
> something best done solely at the driver level. The server through
> client levels shouldn't be affected at all. I think you're also
> suggesting that perhaps all the drivers should be written with a modular
> layer at the very bottom, so that it would be easy to make the output of
> the MtxOrb driver go to the Cisco, instead of to the serial port. This
> isn't unreasonable, seeing as one never knows what sort of display you
> may want to plug into the Cisco. However, it would be a lot of work and
> complexity for a very specific case. I realize that this case could be
> abstracted to something rather more general, but again, it's a fair
> amount of work and another layer of complexity, and KISS seems to be the
> theme lately...
> Is this pretty much what you've been trying to say?

Seems to be what *I've* gathered from this discussion. I like the idea,
and think it's worth implementing (or at the very least, planning). It
might end up being a wishlist thing instead of a todo.

So long as we design things right, adding this feature shouldn't be too
difficult later when we've got the time.

> Two more things I'd like to add...first, the telnet server is a pretty
> interesting idea, that could likewise be implemented entirely as a
> driver. When initiallized, the driver could open up a TCP port and wait
> for TELNET connections (it might have to fork a seperate process so it
> could run continuously), then display framebuffer data via curses, as
> David suggests. The only caveat is that a client would specifically
> need to ask to display to use the TELNET "display".

An alternative to this is to combine multiple displays onto a curses
terminal. Usually a VT100 (or whatever) is 80x24. You can fit quite a
few 20x4 alphanumeric displays on that, 3x5 at least.

It would definitely be a specialized driver.

Maybe we're going about this wrong. Perhaps we should just let clients
connect to the server, get a list of screens, then request the current
framebuffer (or ask that the server send every framebuffer change to the
client). Of course this introduces its own problems (how does a client
get its information to a real display?).

I'm beginning to think this is a *very* specialized use of LCDproc that
won't be mainstream; maybe we should just let those who want to do it
like this write their own stuff to shunt data from LCDd to a display on
a Cisco router.

*shrug* I think I'm floundering here so I'll let someone else run with
this idea for a bit now :)

> The other thing I'd like to suggest is that LCDproc is most useful
> when
> used locally, both client and server on the same system, to monitor a
> headless box. There must be far better tools available to monitor a
> machine via network, right? I'm all for doing "Cool stuff," and using
> netowrk sockets between client and server is just a good idea, but I
> kinda think that doing any fancier networking stuff sorta falls under
> "feature creep." Am I way off base here?

No, feature creep is a bit of a danger here. We've got a perfect chance
to rebuild LCDproc *exactly* how everybody wants it (users and
developers), so we're naturally gonna throw every idea into the melting
pot and sift out the ones that don't make sense later.

In *this* instance, though, I think it's a good idea. This is still the
design phase (although there's already a bit of coding going on :), so
there's lots of room for change. There's plenty of ways to achieve the
same effects; sorting out which one is the right approach for our
purposes is what's important.

William W. Ferrell, System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202 1.303.223.0564

Public key available:
gpg --keyserver --recv-key 7478FC7A

Beggars should be no choosers.
-- John Heywood

Attachment: pgp5t2WlnhZEj.pgp
Description: PGP signature

To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT

Archive powered by MHonArc 2.6.18.

Top of page