LCDproc development and user support list

Text archives Help

[lcdproc] Current developpement question...

Chronological Thread 
  • From: dglaude AT (David Glaude)
  • Subject: [lcdproc] Current developpement question...
  • Date: Sun, 17 Sep 2000 12:29:26 +0200

>-----Original Message-----
>From: Matt
>[mailto:madmatt AT]
>Sent: Saturday, September 16, 2000 7:38 PM
>To: LCDproc mailing list
>Subject: RE: [lcdproc] Current developpement question...
>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.

It is NOT another protocol.
It's another way to OPEN, INITIALISE and to WRITE byte to the same device.

>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.

Serial is two-way, TCP is two-way, Serial over TCP is two-way.

>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!

Once again it is NOT related to cisco.
Access server, shared fax-modem, program for linux/windows do that.

>| 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.

It was agree that communication between lcdproc and LCDd are not encrypted,
just authenticate.
So that communication channel can be sniffed and changed also! Who care.
If someone change any of those flow of information, the screen will display
something different.
Is this a security issue??? Not for the server running LCDd!

>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

What I say is that both Matrix and Cristal have to:
* open the serial port
* setup the baud rate
* write bytes
* close the serial port

This mean that piece of code could be isolated into a low-level driver.
For Matrix driver, there are two option for the low-level driver:
* serial
* I2C

Now if this happend, I will write another low-level driver for Serial over
This low-level driver will work for both Matrix and Cristal.

>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.

The way I explain it, it is not a big rewrite at all,
It is just recognise that driver take care of the PROTOCOL (the stream of
byte we want to send)
and low-level driver take care on the way to transmit that stream to the
physical LCD.

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

Now by reusing code between all the driver that write to serial, it actually
reduce the size of LCDd.
By make conditional compilation of low-level driver that you do not require,
you reduce the size again.
If I only need serial, I don't compile I2C, over TCP, parallel, ...

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

No because it is not only for Matrix but for ALL serial based LCD, and it is
not cisco specific at all.

>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...

That's the way the virtual Xwindow MatrixOrbital driver is working,
with a named pipe, it is nice and easy (except for another process running).
But please recognise that there is a concept of low-level driver.
And this is where it fit best.

Why *securely*? there is no more no less security in this.

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

This was just because some are using parallel.
For those your master-slave LCDd will do the trick.
But that is a lot of code writing, new(?) protocol...

Could someone else (not Matt or me) have a look and try to understand what I
am talking about.
Do you see the point or not?

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

Archive powered by MHonArc 2.6.18.

Top of page