[lcdproc] Protocol changes / cursor control feature
William W. Ferrell
Sat, 16 Jun 2001 10:29:17 -0600
--- firstname.lastname@example.org wrote ---
> On Fri, 15 Jun 2001, William W. Ferrell wrote:
> > I was mostly digging through server/client_functions.c to make sure I had
> > a firm grasp on how I wanted to implement the recently requested ability
> > to control the on/off state, blinking on/off state, and position of the
> > hardware cursor available in some of the displays we support.
> > It occured to me that now's as good a time as any to try to actually
> > standardize the protocol a little bit. Of course this means breaking
> This is planed for v0.5 (the protocol will be replaced with a complete
> different proto as long as I can see).
> This was the reason I only changed the proto in a way which doesn't break
> the clients.
Yeah. That's two votes for leaving v0.4 alone. I guess these changes will
need to wait for the next protocol revision :)
> > 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.
> > Standardizing on this messaging scheme will make a number of things
> > easier. For one thing clients don't have to check as hard for problems; a
> > "dumb" client can just see if it got "ERROR:" back when it tries to add a
> > new screen (then exits), or if it got "INFO:" (or "WARNING:" followed by
> > "INFO:") back instead (it continues).
> 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?
> > 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.
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).
> > 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.
> > Now, as for the cursor control feature, I think the following changes are
> > required (given my digging through the code; feel free to correct me and
> > save me hours of banging my head into a wall if I'm wrong ;):
> > * Each driver needs the following new functions (whether they're actual
> > functions or just stubs doesn't particularly matter):
> Hmm, each driver which likes to support this.
Yes. The driver init function in (drivers/lcd.c) will provide stubs for
these functions if a driver can't/won't support them.
> > - lcd_cursor_on
> > - lcd_cursor_off
> > - lcd_cursor_blink_on
> > - lcd_cursor_blink_off
> > - lcd_cursor_positition (int * x, int * y)
> I think the last one is allready here for the case that you would like
> to write an char on a specific position on the screen.
Yup. You're right. And I should have spelled it "position", not
> > * 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"? :)
> > * The "base" LCD driver (that provides the stubs for drivers that don't want
> > to (or can't) implement a specific call, and calls each driver's init())
> > needs to be changed so it knows about the five new calls, and to provide
> > basic stubs for those functions.
> > I don't quite know yet if I've got everything sorted; is there more that
> > needs to be done to implement these features? Obviously the drivers have
> > to be updated to support the calls when their hardware allows, but
> > otherwise, have we got everything?
> 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.
> > Wednesday's bus ride home changing the server's response messages and
> > haven't gotten through that yet (they're *everywhere*!). I've been
> Yes they are in three files I know.
> And yes a definition for result responses would be fine.
> As I stated while ago I think the best is to have a numeric response like
> HTTP or SMTP which specifies the type of error/success followed by the id
> of the command and followed by a text description of the response code.
> In this case the client knows based on the value how critical and which
> type of result he got and can decide what to do.
> Main adavntage over text that you have not to parse the text (which is not
> as easy as to parse a number).
See above. I agree; this makes more sense than ERROR/WARNING/INFO. I
should just read the relevant HTTP RFCs for inspiration :)
> > thinking we should figure out a way to get those specific strings out of
> > the actual client_functions.c codespace (and other bits here and there).
> > I'm not all that experienced in C, so what's the best way to put those
> > messages all in one place? I don't necessarily want to do the
> > internationalization thing (it's a protocol, not a means of user
> > interaction), but it'd be nice to have all those messages in one file
> > where I could screw it all up with fewer edits >:).
> > Input welcome.
> We can do an error.[ch] which defines a set of error codes sorted by type
> and level. To every code is a string defined.
> And here will be an faunction which spits out the error, like.
> print_stat(int s, int cmd_id, int status, char *info, ...)
> s - socket to write
> cmd_id - id for the command to which this status belongs (supplied
> by the client whith the command)
> status - error code itself
> info - additional text which gets printed after the text defined
> by the error code.
> I think the best is if this is an printf style format
Cool, this fits nicely with what you've described above.
Thanks for the feedback. I'll just stick with hacking in the cursor
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
To unsubscribe from this list send a blank message to