LCDproc development and user support list

Text archives Help

[lcdproc] Current developpement question...

Chronological Thread 
  • From: madmatt AT (Matt)
  • Subject: [lcdproc] Current developpement question...
  • Date: Sat, 16 Sep 2000 18:38:06 +0100 (BST)

David Glaude wrote:

| >That would be a complete an utter fudge! I can see all the hd447870 people
| >queuing up to complain that their hardware is foobar'd now... Transmitting
| >parallel port timings over a network connection, eurgh!
| Why eurgh?
| You just say "between this caracter and the next one you need to wait 40
| ms".
| It is up to the PC(?) connected to the parallel port to implement the right
| timing.

Eurgh because it's *another* protocol we have to develop, as well as the
Server<->Client, and the Server<->Driver, we then have Server<->"exactly
the same hardware as the driver, but over TCP instead" protocols to do as
well. And these would be different to each device type, Parallel would
have it's own, as well as the serial, I2C, etc.

And what happens when trying to report any feedback from these devices? I
can't see that it'd be one-way in every case.

| It is not related to cisco hardware,
| just they provide a way to transport serial communication transparently
| accross a TCP connection.
| The reason why "I DON'T WANT A SPECIAL DRIVER" is because it will be a
| Matrix or Cristal LCD
| attach to the AUX (assync serial) port of the cisco box or access server or
| PC running linux or windows.

OK, if Cisco boxen directly supports this in protocol, then perhaps I can
see an argument for it. However, I wouldn't be too happy having serial
data beamed directly to my Linux box, no way!

| There no security issue in what I propose.
| LCDd is not made less secure because it send it's output accross a TCP
| connection.
| Of course the information we transport could be sniff by someone on the
| network (and see what we display).

And possibly change it as well.

Another point is that this would involve a major redesign to allow the
possibility of a Cisco router being the recipient of the serial data
instead of the LCD panel.

Each driver, (serial or otherwise), would have to allow the fact that
instead of the display, they are being beamed over TCP to a Cisco box.
Once the server has dished the commands to draw to the driver, it has no
more to do with the data. The driver doesn't ever send it back to the

Even though LCDproc is being rewritten, this is too much of a hack to
perform to each driver to allow for the *slight* possibility that instead
of a serial display, we talk to the cisco hardware.

It's also extra functionality that won't be needed by everyone, and
needlessly increases the size of each driver.

However, you *could* write a specific MtxOrb driver that talks to Cisco
harware only. Called, I don't know, MtxOrbCisco or something... :-)

Another way to implement this, would be to create a fake serial device
that the MtxOrb/CFontz driver opens, thinking that it's directly talking
to the display, whereby the serial data is *nicely* and *securely*
transported over to the Cisco hardware. Written this way, makes it nothing
at all to do with LCDproc development...

This seems the best way to solve the problem IMHO

| We don't understand each other because I am talking about serial and you are
| thinking about parallel.
| Isn't it?

I didn't bring up the issue of transporting parallel port timing data
inside the protocol...


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

Archive powered by MHonArc 2.6.18.

Top of page