[Lcdproc] Custom Characters
bsdfan at nurfuerspam.de
Thu Mar 26 17:50:54 UTC 2009
> Thanks for the response! ;-) My replies are below:
> The current API, v0.5 can be found in the docs folder from
> lcdproc's CVS.
> The API gives the provision for each driver specifying
> driver_set_char() and driver_get_free_chars() functions.
> From what I understand these functions are not available to *clients*
> though - so unless I were to patch the lcdproc server source code,
> they could not be (re)defined from a client.
> (Note: For both the HD44780 and CrystalFontz displays, the custom
> characters are mapped to 'ascii' characters 0 thru 7)
This applies to nearly all character displays based on 'standard
controllers' like the hd44780, even if there is some other controller
attached to which you talk using a serial or USB port.
One problem with custom characters (CCs) is that they are used
internally by the driver for icons, hBars, and vBars. Even if you could
define your own CC from a client, you would need special precautions in
either the client or drivers because they would be overwritten by the
driver every time it has to display an icon or bargraph. This is
relevant, because your client might not be the only one connected and
the server will cycle through the client's screens.
Looking at the 'pyramid' driver you will find a function
'pyramid_init_custom1', which is triggered by 'output' and places some
non-standard icons as CC. This is possible because Pyramid uses their
own client with their own product, but this is nothing I would like to
integrate in a 'standard' driver just for a single client application.
> The icon() function is intended for the display to depict named
> icons (described in server/drivers/lcd.h):
> I know about the 'icons' - but I'd like to be able to define my own
> characters/icons... Which isn't currently possible from what I can
> tell. :-(
Well, in the meantime if you need a fixed set of icons which could be of
use for other's, you could define additional icons in core and the
drivers you use. And if they are not useful for other, you can roll your
own patched version.
> If the "output" function can be used with HD44780 displays to issue
> 'direct' commands to the LCD, then I have no issue whatsoever - I can
> define the custom characters that way. ;-) But if it can't, then I'm
> back to the dilemma...
The hd44780_output talks to the parallel port using the same data pins
as the display, but you can't trigger the control lines as you would
need to send commands to the display. Additionally you can only send 4
bytes (sizeof(int)) during one screen rendering, which makes it unusable
to pass longer commands like defining a custom icon to the display.
> I doubt you're offending anyone, but this might: The biggest
> problem with lcdproc right now is that the current release is two
> years old, and there appears to be little movement to formalize
> the next release. I think the main reason for this is that
> lcdproc's development community has declined, and the project
> admins have gone missing - one in recent months, but the rest for
> years. In fact, it looks like Markus is the only active developer
> Markus has been a great help, and very patient with me in getting the
> debugging info he needed to resolve my CF634 startup hang. But once I
> got it to him, he was very quick to resolve the issue and even commit
> it to CVS. ;-) (THANKS AGAIN!)
If you look at LCDproc's history you can always see people come and go.
If someone which has driven the project for more than 4 years suddenly
disappears, what's to expect? There *are* still admins and developers
around and they accomplish some work. I hear the question about a new
release getting louder every week, but please be patient.
More information about the LCDproc