[lcdproc] TCP or .so

[William W. Ferrell]

--SFyWQ0h3ruR435lw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

--- dglaude@netbrain.be's mailer spewed these beefy chunks ---
> Hello,
>=20
> Being the one that started to talk about named pipe...
> I must officialy announce that I am convince with ".so" solution.
> Dynamic loading of driver is not a MUST HAVE for me and since we can
> staticaly link too
> (for Windows?, for embeded, for ???) it offer all the simplicity/portabil=
ity
> we require.

Hehehe cool, made that decision easy then :)

> Serial communication accross TCP, named pipe, and all special trick or ni=
ce
> to have,
> can be implemented as an alternate driver.
>=20
> 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.
>=20
> Having separate process was reducing the security issue due to priviledge
> require
> to write to the hardware... but was introducing yet place where the
> parser/protocol
> need to be strong. Now if we go for the .so solution, then I don't know h=
ow
> to deal the the security risk/fear of having suid root process.
> As far as I know root is not requiered for serial based LCD, so parallel
> port
> LCD driver introduce special requirement. I would like it possible
> to compile a LCDd that do not require suid root if I only use Matrix Orbi=
tal
> LCD.

I don't think there's much to stop someone from writing a "stub" .so
file that links into LCDd then uses whatever means (named pipe, TCP/IP,
blah) to speak to whatever little proggie needs to be root to write to
the device.

I *really* don't want LCDd to *ever* have to run as root. This might be
a way to avoid it.

> I am pretty sure many project would love to have an LCD output without
> having to take care of this part. The best would be to create a library
> of function to help peaple write LCDd client code.
> And in this library of function they can choose the
> multiclient/multiscreen/multiplex
> over TCP way or they can use the stand-alone/embeded/driver linked way.
>=20
> This does not answer the question about where should the framebuffer be,
> where should the widget be implemented. In my mind, the driver code=20
> 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:

Pros:
  * The driver can better optimize output to a display than LCDd could
    (unless I'm missing something)
  * LCDd is less complex

Cons:
  * We're dependent on each driver to *correctly* implement each widget.
    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.
  * 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
    changed.

This stuff is and always will be completely trivial and not worth much
of our time, *except* when it comes to graphic displays.

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

> About parsing, we basicaly need something for the protocol (over TCP)
> and the configuration file of LCDd. I believe in KISS concept and avoiding
> lex/yacc should be possible for simple task like that.

Agreed, and I think most everyone on the list is with us on this point.
The language *should* be fairly simple, but then again I've never done
parsing so I can't speak too authoritatively on this subject.

> Also I don't know yet either how to deal with "keys" and keypad...
> Just make sure LCDd is easy to use for stand-alone client.
> I think if client/process need to share some input, then they need
> to some how colaborate for this.

Client and drivers are two different beasts. I agree, a client should be
dead simple to write. LCDd should make clients easy. *Drivers*, though,
probably shouldn't be written by a skrippt kiddie :)

> Futur or possible new feature???
>=20
> Did anybody thinked of using message passing inside LCDd?
> Like: A driver could send a "key-pressed" message to LCDd
> and LCDd would pass the message to other client.
> This would let a client "control" another client.

Yes, I think this is in the works.

> Also, what about dynamic (TCP) connection of "watcher" or "driver"?
> Someone connect (telnet?) and say, "gimme a copy of the screen (TXT or VT=
100
> 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.

Heh. Imagine running some small tool in X (GNOME/KDE/whatever) that lets
you admin LCDproc and pops up a window for each screen that LCDd is
hosting :) That'd be cool.

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

UNIX enhancements aren't.

--SFyWQ0h3ruR435lw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjq/X5UACgkQgAeqhXR4/HpZIgCdHg5FbFRD/y/vFPzJHM6ARrey
gz0AoL+K0Lq4UiRlo/xGvytz28hrMLsv
=zlgl
-----END PGP SIGNATURE-----


--SFyWQ0h3ruR435lw
Content-Type: text/plain; charset=


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net
--SFyWQ0h3ruR435lw--