[lcdproc] TCP or .so
William W. Ferrell
Sat, 24 Mar 2001 10:51:51 -0700
Content-Type: text/plain; charset=us-ascii
--- email@example.com's mailer spewed these beefy chunks ---
> > Have we even firmly decided yet whether we're going to send full
> > framebuffers every frame or just deltas?
> I've been thinking. If you place the framebuffer on the side of the=20
> core of LCDd, it should know exactly what the display can display. So=20
> if you have an H-bar, LCDd should need to know how wide the userdef-
> chars of the LCD are (well that's 5x7 mostly).=20
> If you should let the driver decide how it does display widgets, LCDd=20
> should never have to know the charachter-width to use an H-bar. This=20
> can be accomplished by using the widget language to transfer data from=20
> LCDd to the driver. The framebuffer is then on the driver side. LCDd=20
> must then decide which widget-data to send to what display-drivers, and=
> when to clear the display and show an other screen. Isn't that better ?=
That works, but then the drivers have to understand and implements all
the widgets. If we decide to add new widgets to LCDd, now we have to
update all the drivers instead of just releasing a new LCDd :)
> And for the embedded systems, we can produce something that links one=20
> client directly to one driver (without LCDd) into one executable. That=20
> might be possible because the language is the same, and there is no=20
> multiplexing needed when you have only one client and one driver.
A very good idea. If we decide the above issue (drivers handling widgets
instead of LCDd) is worth dealing with, this would be a definite win.
> FYI I'm not thinking about lex/yacc for this job. The language is so=20
> simple that a more transparent method can be used. More transparent-
> >less bugs->less vurnerable. A line of the language has a start-word=20
> and then contains parameters. That can be strings or numbers. Thats the=
> whole language. I'm not fond of the large lex/yacc for simple=20
> languages. I have used lex/yacc for a small compiler once in my study.
Do 'ya know how to build such a parser, though? I sure don't :)
William W. Ferrell, Senior 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
You're dead, Jim.
-- McCoy, "Amok Time", stardate 3372.7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
Content-Type: text/plain; charset=
To unsubscribe from this list send a blank message to