LCDproc development and user support list

Text archives Help

[Lcdproc] Improvements to imon driver: special characters and smoother hbar

Chronological Thread 
  • From: ethan.dicks AT (Ethan Dicks)
  • Subject: [Lcdproc] Improvements to imon driver: special characters and smoother hbar
  • Date: Tue Jun 5 20:31:02 2007

On 6/5/07, Dave Liquorice
<allsorts AT>
> On Mon, 4 Jun 2007 08:47:45 -0400, Ethan Dicks wrote:
> > One thing to consider doing with this part of the proposed lib is to
> > allow the drivers for certain displays to "register" hbar chars that
> > are already part of the module's ROM character set (common with
> > various flavors of VFD).
> Agreed but not limited to just hbar characters. If the character set of a
> given display has characters suitable for our "specials" there just needs to
> be a simple mapping mechanisium to allow their use.

Sure, but I wanted to draw attention to hbar chars because it's a
common feature with VFDs; vbars not so much. I'm entirely in favor of
being able to, at the driver level, have the code "know" what custom
glyphs are already in the device to avoid the overhead of custom
chars. It doesn't hurt that I know I can test this with hbars on
displays that I already own.

This brings to mind another feature I'd like to find a way to
implement, which is glyphs that are larger than one char cell... it
doesn't make much sense with a traditional LCD, unless you are
rendering a 2x2 char glyph, but for glcdlib-managed displays, one
could imagine a 32x32 pixel (4x4 char) attention-grabbing icon that
the application could request as a single token rather than having to
know intimate display and driver details. I'd say that the client
should _request_ these glyphs and be able to tell if the display could
handle them or not, rather than assume all is well, but I think some
form of this feature would be handy for those of us who use LCDproc
for "across the room" status monitoring - "oh, look! There's a large
exclaimation point or a Mr. Yuk on the display - something is not
right," then wander over for a closer look.

With most textual displays supporting a max of 8 soft chars, even a
3x3 is a reach (unless there happens to be at least one full cell with
all-on or all-off). 4x4 is right out, except for careful mixes of
soft and ROM chars, but, as I said, with a glcdlib-based graphic
display, if one were to, say, at the client level, declare that it
would never render text in a certain spot on the display, it wouldn't
take much more than adding a mechanism to associate some pre-done
bitmaps with these icon "tokens" and adding a way for the graphic
stuff to just blast the bitmap to the display (I have some
4:1-aspect-ratio displays, like 32x256 that would look great with some
32x32 icons on one end or the other, with text alongside).

I can certainly do the coding - what I don't want to do is to break
the protocol or do a bunch of work that nobody wants to add to the
codebase. I suppose I should paste up some bitmap examples and see
how they look before getting too much further into designing this in
my head ;-)

So... for now... just a thought to keep in mind adding a way to have a
single message from a client result in some predefined "shape" being
rendered to the screen. There's no need (that I can see now) to
enforce the sanctity of an "icon zone", so if someone's client runs
amok, the icon gets stomped. As long as nobody draws over the icon
intentionally or accidentally, it'll remain displayed.

Thoughts? Reactions? Gasps of horror?


Archive powered by MHonArc 2.6.18.

Top of page