LCDproc development and user support list

Text archives Help

[Lcdproc] graphs

Chronological Thread 
  • From: ethan.dicks at (Ethan Dicks)
  • Subject: [Lcdproc] graphs
  • Date: Mon, 5 Apr 2010 12:33:21 -0400

On 4/5/10, Jon Myers <myersjw at> wrote:
>> > Greetings! I've just recently gotten into lcdproc, and written a client
>> > to display some basic information, just so I know I can do it.
>> > I'm using a CrystalFontz 20x4 display (XE634BK-YFB-KU).
>> > Is it possible to display a "high definition" graph? As in, not using
>> > whole blocks in a graph, but individual pixels.


>> > I was going to cheat, and use set_char to make my own custom characters,
>> > but it seems set_char is in the driver itself, which I'd rather not
>> > touch.

It's not a matter of "not touching", the driver handles set_char()
because the driver knows what the display is and is not capable of.

>> > But I'd like to somehow bitmap a whole block of a line, then still be
>> > able
>> > to print a few text characters at the end of that line (or I can bitmap
>> > those as well I suppose, creating my own fontset if I have to).

You can mix text characters and user-defined characters because
fundamentally, all text-based LCDs use a single byte value per
character cell (there's a few dozen bytes of RAM in the display itself
to hold this), so from that view, there's no difference between
characters defined in ROM or user-accessible RAM.

The problem is that different displays permit different numbers of
user-definable characters. For displays using an HD44780-compatible
controller, that number is 8. One char is used by LCDproc for
heartbeat, the rest can be used for vbars or hbars (or menu glyphs,
etc). If you wanted to scribble directly on the user-defined
character memory to simulate a bit-mapped display, you could only do
that for 8 characters on the entire display. The API for LCDproc,
though, does not allow your client app to communicate that sort of
information. It's an entirely one-character-at-a-time scheme.

Other displays have more flexibility (and some less!), which is why
the drivers handle all that heavy lifting. I have some VFDs from cash
register "Pole Displays" that only have two custom chars. I also have
a few jw002 24x8 displays that are really graphics displays, but an
onboard MCS51 microcontroller manages the fonts and pixel updates, so
*any* char is soft-settable (which reminds me - I need to get back to
prettying up the driver and docs so it can be included in the next
release, whenever that might be).

>> > single solid line on the bottom of that character. in the docs, vbar
>> > talks
>> > about "x,y". Does it mean x,y as in character positions, or pixels?

x and y for vbar() are in character positions. It tells the widget
handler what cell to start the bar at.

>> > Also, if this can indeed be done, is there a driver for X? ...
> Thanks for the information. I have xosd working, but I'm not sure it
> will work for my testing, as it seems xosd cannot render a vbar, as
> there is no font for it maybe?

I haven't worked with xosd, but for any driver that uses character
cells vs user-definable characters, you will be limited to font-based
characters that approximate partially filled cells (like | _ . : #
etc) This is what the curses driver does because default fonts for
machines (doesn't matter for Linux, for Mac, for Windows, for Amiga,
etc) don't have character-cell graphics beyond drawing boxes and such
(unlike Commodore-64s and PETs and such, which *do* have
line-at-a-time characters in the ROM font that will handle vbars and

If you went out and grabbed a PET font for X, you could probably get
xosd to render each line in an hbar or vbar, but it might take some
hacking to associate the correct PETSCII values since they are
entirely non-standard in the modern computing world.

> I'm using:
> widget_set vbarA 1 4 2
> widget_set vbarB 2 4 5
> widget_set vbarC 3 4 7
> and I'm getting three pipe characters | (all same size) next to
> eachother. But I guess I'll test on the actual display and see what
> happens.

I wrote some vbar and hbar test scripts a while back to help me with
my driver testing. I thought I posted them, but I can't find them on
a quick google search.

The clients weren't anything magical - just a perl script to create a
vbar or hbar in the lower-left corner of the display, then cycle from
zero to full then back to zero at a bit of a delay so you can see the
bar render. I'm sure I have them on my development box at home and am
happy to share them. They are incredibly useful when hacking hbars
and vbars into new drivers - you get to see all the states.


Archive powered by MHonArc 2.6.18.

Top of page