LCDproc development and user support list

Text archives Help


[lcdproc] Protocol changes / cursor control feature


Chronological Thread 
  • From: wwf AT frontierdev.com (William W. Ferrell)
  • Subject: [lcdproc] Protocol changes / cursor control feature
  • Date: Fri, 15 Jun 2001 13:24:02 -0600

Okay everybody, I've gone and started hacking again at the LCDproc code.
Be afraid, be very afraid :)

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
compatibility (I *think* ... I'm not entirely sure the changes I'm making
right now are going to kill anything; the LCDproc client at least still
runs even with my server modifications).

Basically, it shouldn't say "huh?" ever :) It was cute, and amusing, but
it's not a very clean way to do this. The server needs to be more
informative than it is.

So far, I've decided on this scheme for messages and errors. Here's three
examples:

ERROR: screen_add: Too few arguments (expected 2, got 1)
WARNING: screen_add: Too many arguments (expected 2, got 3)
INFO: screen_add: Succeeded

I trust these are self-explanatory; errors are fatal (the operation didn't
succeed), warnings are non-fatal (the operation may or may not succeed;
the server will bark an error back if the operation subsequently fails),
info messages are just informative.

The server's response to "hello" has changed too (I appended "INFO: " to
the beginning of it.

This of course breaks any client that requires seeing "connect LCDproc"
right at the start of the server's response to "hello". Ugh. I haven't
committed these changes to CVS yet since I wanted to bounce them off the
people here first.

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

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
really succeeded at doing what was intended). This change makes that
workable.

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

- lcd_cursor_on
- lcd_cursor_off
- lcd_cursor_blink_on
- lcd_cursor_blink_off
- lcd_cursor_positition (int * x, int * y)

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

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

I'll pick back up hacking away at all this tonight. I spent most of
Wednesday's bus ride home changing the server's response messages and
haven't gotten through that yet (they're *everywhere*!). I've been
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.

--
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
lcdproc-unsubscribe AT lists.omnipotent.net




Archive powered by MHonArc 2.6.18.

Top of page