LCDproc development and user support list

Text archives Help

[lcdproc] Protocol changes / cursor control feature

Chronological Thread 
  • From: andre.breiler AT (Andre Breiler)
  • Subject: [lcdproc] Protocol changes / cursor control feature
  • Date: Sat, 16 Jun 2001 19:19:30 +0100 (BST)

On Sat, 16 Jun 2001, William W. Ferrell wrote:

> ---
> andre.breiler AT
> wrote ---
> > On Fri, 15 Jun 2001, William W. Ferrell wrote:
> >
> > > ERROR: screen_add: Too few arguments (expected 2, got 1)
> > > WARNING: screen_add: Too many arguments (expected 2, got 3)
> >
> > Last time I digged through the code your warning would be the same as
> > error becoause the command dien't succeed but I will look again.
> Well, it would most likely be fatal, but isn't necessarily. I figured
> changing "too many arguments" into a warning since there's enough
> arguments to at least *try* to complete the command (just ignore the
> rest). It's probably stupid to do this now, as there's next to no sanity
> checking on the arguments sent by the client.

Ok, I see you point. You are defining a few params as optional.
Yes this makes sense and someone should remember this for v0.5 .

> > Ok if here are any operation which have the abability to produce only a
> > warning then this makes sense.
> > A client knows his last command and knows if an error (huh?) is fatal or
> > not and as long the WARNING,INFO msgs are not standardized (e.g. like
> > SMTP) the client gets not a better position than before.
> >
> > If you change the protocol so fundamentally then you should also add an
> > id for every command so that I can send a load of commands to the server
> > and check the responses afterwards.
> So similar to HTTP, etc:
> 100 OK screen_add succeeded
> 500 ERROR screen_add failed
> Stuff like that?

Yes right. With a small addition as ID for the command. So that I can
send a bulk of commands to the server and have not to wait for the
response after every command. The advantage would be that I can get ride
off of the network latency.
e.g. I can send:
screen_add cmdid=1 name=main
screen_add cmdid=2 name=options
screen_add cmdid=3 name=misc

and then collect the responses
100 1 OK screen main successful created.
100 2 OK screen options successful created.
302 3 DELAYED Screen queue locked. creation of screen misc delayed.
100 3 OK screen misc created.

> > > Ideally, clients should parse the server response to make sure what they
> > > asked for actually happened, but since the server previously just said
> > > "success" to most things or "huh? you have to ..." to most errors, it
> > > wasn't too easy to implement this (and impossible to verify that a
> > > success
> >
> > Sure it isn't optimal but here are only this to choices (you got what you
> > asked for or it failed) at the moment unless someone changed the most
> > parts of the server (but I didn't see anything like this on the
> > maillinglist) so that you can track an command until it's completed by the
> > last thing in the chain (e.g. the driver changed the backlight).
> > Here also the problem that you don't know that the display does itself so
> > that you can't be sure that you see what you expect on the display.
> Nah, nobody's changed anything lately to keep state like that.
> Not knowing that the display has actually done what we ask it to is a
> problem we've faced from the start. In many cases, you can't find out what
> the display's doing except by looking at it with your eyeballs. A few
> displays support sending back their memory contents, but making use of
> that functionality might be more trouble than it's worth.

Yes I agree with you on this.

> I think it's best to keep the sanity checking between the client and
> server, and not bother trying to sort out if the display really did what
> we asked. The server just needs to acknowledge it's done what it was asked
> to (or that it failed).

Yes, I think we should track it down to the driver (the driver accepted
what we asked for).
I think this makes sense in the case of distributed displays so that the
get informed that his command is fine but the driver didn't respond so far
(e.g. not reachable at the moment because of network prob).
So that the client can be sure that it's command is finished.

The other thing is that we can tell the client that something is not
supported by the driver/display.

But this are all thing to be decided for v0.5 IMHO.

> > > really succeeded at doing what was intended). This change makes that
> > > workable.
> >
> > Maybe I oversee something but I think you solution does the same as it was
> > implemented before but will break most clients.
> Well this was trying to move to the next version of the protocol. The
> folks on the list are right, though, this should be implemented in v0.5,
> not in v0.4.x.

Hmm someone should collect all the ideas from the maillinglist into an
document (I stopped to do this half way because the lack of time).

> > > * servers/client_functions.c needs to implement new protocol calls:
> > >
> > > - Ideally, screen_set (which for now just sets the screen's name)
> > > should handle the new features, since this is definitely related
> > > to a specific screen. New arguments to screen_set would be:
> > >
> > > - show_cursor <[on|true|yes]|[off|false|no]>
> > > - blink_cursor <[on|true|yes]|[off|false|no]>
> > > - cursor_pos <x> <y>
> >
> > I agree with you. But please implement these params as optional things.
> Okay, but what should the defaults be? show_cursor & blink_cursor false?
> cursor_pos "wherever the server leaves it"? :)

Yes I think these would be the best because this is what the current
server version does.

> > Yes I think you got all the pieces. You have to decide if the server or
> > the driver should do the (cursor on/off on display refresh).
> > I'd do it in the serever because the refresh is initiated by the server.
> It has to stay in the server; we have to keep cursor state for each screen
> now, even if it's just to say "this screen doesn't want the cursor turned
> on and doesn't care where the cursor is."
> For screens that do, we have to turn on the cursor right as we send the
> first frame, then make sure for every frame afterwards we send the cursor
> position command *after* everything else.

You are right but I guess you mean turn the cursor off until we finished
writing to the screen then set the position and turn the cursor on.
Otherwise we will get a flickering cursor.

Bye Andre'
Andre' Breiler | Tel: +44 1737 839532
BBC Internet Services | Email:
andre.breiler AT
Kingswood Warren,Tadworth,Surrey,UK | URL:
Mail me. Don't phone if possible. And use a Subject line.

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

Archive powered by MHonArc 2.6.18.

Top of page