LCDproc development and user support list

Text archives Help


[lcdproc] Current developpement question...


Chronological Thread 
  • From: dglaude AT netbrain.be (David Glaude)
  • Subject: [lcdproc] Current developpement question...
  • Date: Fri, 15 Sep 2000 17:04:51 +0200

>-----Original Message-----
>From: William W. Ferrell
>[mailto:wwf AT frontierdev.com]
>Sent: Friday, September 15, 2000 4:09 PM
>To: David Glaude
>Cc: LCDproc mailing list
>Subject: Re: [lcdproc] Current developpement question...
>
>This brings up another question -- should *drivers* handle virtual
>screens or should the server?

Well, considering I may want to create a virtual screen out of a Matrix on
to of a Crystal...
It must be the server, the driver does deal with one (or multiple) device of
one (and only one) kind (or family).

>We're toying with this idea -- the solution so far is to make a driver
>that "pretends" it's a display, but in fact sets up its own socket and
>listens for connections. If you wanted to make a driver that speaks
>telnet and sends VT100/ANSI/whatever, you could do so.

Now, if I telnet (and ask for a copy of LCD with CURSUS driver),
I want to have the ouput of the CURSUS send to the TCP connection.
If I have a Matrix Orbital screen, then I can write a small program
that will connect to LCDd, ask for a copy of the LCD screen with
MATRIXORBITAL.
LCDd will send a copy of everything send to the serial to the TCP
connection,
and I will copy that to my serial port.

This mean that the computation of caracter to send
and actually sending those caracters should be separate (AND common)
for each driver (I wonder for timing issue).
That way we can send the computed screen to anywhere:
* Serial
* Parallel
* I2C
* TCP connection to an access server where the serial LCD is connected
(like the AUX of a cisco or an access server)
* Dynamicaly network connection screen (via a small a client that connect,
read from TCP and send to LCD)

Now, someone need to check for Parallel and timing issue... as this need to
be transmit somehow inside the TCP connection. We might need an escape
caracter to send timing information before a caracter we transmit. And if
there is no timing issue at all with the device, then we could 'negotiate' a
clear channel.

So opening the serial device, configuring the speed, reading and writing
byte to it is COMMON to all serial based LCD screen, what is different
between vendor X an Y is the protocol, and that's what need to be in the
driver.

Client describe what they want to display
Protocol give high level hardware independent view of an LCD
Server manadge the Client and translate high level request to low level
API (like custom car for hbar)
Driver generate the proper byte stream for that specific vendor protocol
(Matrix, ...)
LowLevel transport the stream to the physical screen

IS IT CREAZY or just a big good idea on the way to do things.

>I wonder about the wisdom of dynamically resizing screens though -- how
>do you tell a client, that's just spend a lot of effort sorting out
>which display it should use, that its chosen display just doubled in
>size? That's certainly not a case *I'd* want to code a client for :)

Most screen don't change size (physical screen don't).
Most peaple will only have one LCD (except developper and collector).
Now, most client only expect one screen and will display on that default
screen.
In O.4pre all the screen where displaying the same thing... that should be
the default.
If you make a screen selection stuff in protocol, then that's gonna be the
problem of the client...

David GLAUDE


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