LCDproc development and user support list

Text archives Help


[lcdproc] Remote (network) displpays


Chronological Thread 
  • From: wwf AT frontierdev.com (William W. Ferrell)
  • Subject: [lcdproc] Remote (network) displpays
  • Date: Sun, 17 Sep 2000 21:08:08 -0600

* Nathan Yawn
(natey AT hcis.net)'s
mailer blew these chunks:
> I'm a bit lost...can you list an example of where this
> functionality is
> necessary? Doesn't functionality already exist for remote display? It
> was my understanding that the clients already connected with the server
> via TCP sockets. (If they're actually UNIX sockets, it would be trivial
> to make them TCP sockets). As such, can't we simply run the server on
> the "remote" machine with the display, and run the client on the "local"
> machine whose data we wish to monitor? I'm not sure I see why there
> needs to be a second "mini-server"...?

Yes, a perfect example (I think) -- an embedded system where there might
be room for a stripped-down LCDd that only speaks one LCD's language and
only listens on a socket for framebuffer data, whereas it *doesn't* have
room for a full-blown LCDd listening to clients, drawing screens, and
talking to multiple drivers.

Also, what if you want to see your LCD's contents and you're not at the
box where you can look at it? Depending on how we do this, you might
just be able to connect to the LCDd process from a machine you *do* have
access to and get things displayed there as well.

--
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 certserver.pgp.com --recv-key 7478FC7A

Beggars should be no choosers.
-- John Heywood

Attachment: pgphpO5x2AG1N.pgp
Description: PGP signature


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT lists.omnipotent.net


Archive powered by MHonArc 2.6.18.

Top of page