[lcdproc] TCP or .so
Tue, 27 Mar 2001 15:01:57 +0100 (BST)
On Mon, 26 Mar 2001, William W. Ferrell wrote:
> --- firstname.lastname@example.org's mailer spewed these beefy chunks ---
> > Serial communication accross TCP, named pipe, and all special trick or nice
> > to have,
> > can be implemented as an alternate driver.
Yes, but we should have this in mind (blocking call via slow line is not
the best thing ;)
> > One of the NICE TO HAVE feature is to make sure our driver
> > (Matrix Orbital, Cristalz, HD47..., other) can be reuse by other project.
> > This could be either reusing the .so or using some of our code (widget) +
> > .so.
This should be easy because we (should) use the KISS approch for the
> > This does not answer the question about where should the framebuffer be,
> > where should the widget be implemented. In my mind, the driver code
> > should be minimum in size to reduce the price to pay (time to develop)
> > when someone wants to write a new driver. Basicaly, I know my hardware,
> > I know the protocol, I know how to talk to my hardware so it should be
> > easy to write a driver for LCDd. Once I have a driver for LCDd I know
> > a lot of project will be able to support/use my hardware.
> Yes, but since you know your hardware best, you'd be the best person to
> optimize how LCDproc's framebuffers are transmitted and displayed on
> your display. I'm torn on putting widgets in the driver or not:
I would define a view primitives (like hbar, vbar, bignum,) and let the
LCDd transform his idea of the screen in these supported by the driver.
So the driver has no layering etc. and can decide what to do.
Yes this is only a trade of.
> * The driver can better optimize output to a display than LCDd could
> (unless I'm missing something)
> * LCDd is less complex
I think we should move the complexity more to the lcdd than to the driver.
> * We're dependent on each driver to *correctly* implement each widget.
Yes, but only the driver knows if it's possible to mix bignums and hbars.
> I tried to write a scroller once a few years ago. It was truly a
> pain in the ass (granted, I was a newbie), but client developers
> will expect widgets to behave the same no matter what display
> they're on.
So the driver tells the lcdd on init that he don't support scrolling of
areas. (note this is not equal to the widget scroller)
> * A driver could still optimize the display very well if it has a copy
> of the previous framebuffer (and its custom characters) and the
> current one (with its custom characters). For example, say all the
> custom characters change between one framebuffer and another, but
> 7 of the 8 characters just changed "slots" and only one really "new"
> character is defined. The driver could then just change the one
> character in the physical display, "rewrite" the framebuffer to
> remap the characters, then transmit only the characters that
Cool, this reminds me on the mpeg (video) standards. I think it's not easy
to guess from the diff the best primitives to use.
The scroller in lcdd knows that the diplay part should scroll, but to
guess this from the changes in a framebuffer is not so easy.
> This stuff is and always will be completely trivial and not worth much
> of our time, *except* when it comes to graphic displays.
It's also not easy for text only if here are enough primitives available.
> In fact, I'm beginning to think LCDd should just handle text displays
> itself (with the driver just providing basic primitives like "print text
> here" and "define this custom character"), and making drivers more
> advanced for the graphical displays (more primitives, like "line from
> a,b to x,y" or "draw this graphic at x,y" or "write this string in a
> proportional font starting at x,y").
Do you realy plan to use gfx on gfx displays ? I would treat the gfx
displays as text displays where the driver translates the text primitives
> > Also, what about dynamic (TCP) connection of "watcher" or "driver"?
> > Someone connect (telnet?) and say, "gimme a copy of the screen (TXT or VT100
> > or cursus)".
> > That would be a nice way to be able to remotely "see" the LCD.
> > Also it could be use for a web screen shot of "currently on my LCD".
> Another good feature to add. Actually this would be a perfect way to
> implement the remote display stuff -- a "driver" that doesn't have any
> screens but is allowed to peek at the various framebuffers.
So the lcdd converts his idea of the display screen to an framebuffer and
sends this to the asking client.
Andre' Breiler | Tel: +44 1737 839532
BBC Internet Services | Email: email@example.com
Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
Mail me. Don't phone if possible. And use a Subject line.
To unsubscribe from this list send a blank message to