LCDproc development and user support list

Text archives Help

[lcdproc] Current developpement question...

Chronological Thread 
  • From: wwf AT (William W. Ferrell)
  • Subject: [lcdproc] Current developpement question...
  • Date: Fri, 15 Sep 2000 08:09:25 -0600

* David Glaude
(dglaude AT's
mailer blew these chunks:
> -----Original Message-----
> >From: William W. Ferrell
> >[mailto:wwf AT]
> >Sent: Thursday, September 14, 2000 10:14 PM
> >To: Matt
> >Cc: LCDproc mailing list
> >Subject: Re: [lcdproc] Current developpement question...
> >...that can be avoided simply by insisting LCDproc be downed and brought
> >back up when hardware changes occur.
> >
> >That's just too much work for too little gain. Most people are gonna set
> >up their systems and leave them running for days/weeks/months/years.
> >Displays normally won't change that much.
> I agree, if any hardware change are done... restart the server.
> And let's try to make the client smart in reconnecting to the new server
> (same place).
> However you sometime have to wait a few minute before the server can
> reconnect to the same TCP port.

The LCDproc client will be bright enough to handle this (hopefully :),
but for other clients, it's up to the author to decide what should
happen. In fact I think the LCDproc should be configurable in that
regard -- what should it do when it receives this?

< ERROR: Disconnecting: server restarting.

A user should be able to choose whether the LCDproc client just bails
when this happens or if it should just sleep for 30 seconds and try
connecting again.

> Now in the opposite direction, we where talking about virtual screen made of
> multiple screen side by side
> or on top of each other. What if you want to change the geometry... restart
> the server?

Interesting question... I'm thinking "yes", restart the server whenever
you change around how a physically attached screen is configured. The
only alternative would be to add display creation/destruction abilities
to the protocol. That could be somewhat dangerous.

This brings up another question -- should *drivers* handle virtual
screens or should the server?

> So if you go for the "restart the server" what is left of dynamic
> screen/driver.
> I still believe that dynamic screen/driver apply for networked screen (Laser
> Jet or telnet monitoring or ...).
> I whould love to be able to telnet the server, say "Hello I am VT100 I want
> a 20*4 copy of lcd screen"
> and get the cursus driver sending a copy of the physical LCD to my remote
> session.
> That way we could build a public LCDd server with news/ticker/weather
> forcast and anyone could:
> 1) Telnet (and resize the screen).
> 2) Attach (how?) with a LCDclient and a physical LCD screen.
> Somehow make LCDd a message broker between client (lcdproc), physical LCD,
> and remote physical/virtual LCD.

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.

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

[Flex/bison mumblings]

> Just to give you my practical experience about flex/bison, here is the
> relevant files from my last small little project relative to the macro
> processing of a language. All of this is on a windows intel platform but
> using GNU tools:
> -rw-r--r-- 1 dglaude Administ 17673 Sep 15 00:13 BISON.SIMPLE
> -rw-r--r-- 1 dglaude Administ 3598 Aug 9 08:53 LType.l
> -rw-r--r-- 1 dglaude Administ 46353 Sep 15 00:30 ltype.c
> -rw-r--r-- 1 dglaude Administ 14469 Sep 15 15:06 ltype.o
> -rw-r--r-- 1 dglaude Administ 4031 Jul 27 22:51 YType.y
> -rw-r--r-- 1 dglaude Administ 26716 Sep 15 15:05 ytype.c
> -rw-r--r-- 1 dglaude Administ 541 Sep 15 15:05 ytype.h
> -rw-r--r-- 1 dglaude Administ 8214 Sep 15 15:05 ytype.o
> More likely the parser for LCDd won't be that big, but for those of you
> focussing on space, the *.o files seems big.

Those actually look rather small ... 22K for a parser isn't too
terrible. The current LCDd is 75663 bytes on my machine, though, so I'm
guessing this would increase a *little*. Then again, LCDd v0.4-pre9
doesn't dynamically load modules either. *shrug* We'll just have to see
how it grows as we move forward.

William W. Ferrell, System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202 1.303.223.0564

Public key available:
gpg --keyserver --recv-key 7478FC7A

You can't take damsel here now.

Attachment: pgpLrUphlu2Mx.pgp
Description: PGP signature

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

Archive powered by MHonArc 2.6.18.

Top of page