LCDproc development and user support list

Text archives Help

[Lcdproc] Non-Latin characters in LCDd.conf

Chronological Thread 
  • From: ethan.dicks at (Ethan Dicks)
  • Subject: [Lcdproc] Non-Latin characters in LCDd.conf
  • Date: Thu, 27 Nov 2008 15:32:11 +1300

On Wed, Nov 26, 2008 at 6:20 PM, <aeriksson2 at> wrote:
> kokolist at said:
>> Is there anything I am missing?
>> I am not a code expert but if someone feels like giving me a hint, maybe I
>> could take it one step further.
> IIRC, the protocol LCDd exposes is ascii based and there is no provision for
> indicating charset used from a client. I'd assume that the daemon
> interpreses
> whatever you send (UTF8 I guess) as plain ascii, and asks the driver to
> render
> ascii glyphs.
> Coming from Sweden, I'd like to have a solution for this too. It would be
> cool
> to be able to load fonts to the LCD just like you can for the regular
> console!

The overall problem with that is that LCDproc is firmly rooted in its
roots as an HD44780-based abstraction tool, and those sorts of
displays tend to have a small number (1-8) of user-definable
characters, with the rest of the characters and glyphs in onboard ROM.

I know the original poster is using a display which is effectively
bit-mapped, and I have a few displays that can do that (jw002, and
several true graphical LCDs), but most of what I have is stuck with
whatever the ROM character set is. The jw002 is kinda nice in that it
presents itself to the server as a textual display, but internally
it's a graphical chip with an LCD layout that's character oriented
(there are voids between the 5x8 LCD cells). What this means is that
there is a ROM character set (4 by default, actually) with many
glyphs, but once you write a glyph, you can change sets without
changing glyphs you've already written since they are in the bitmapped
memory. It's the only display I know like it, so most are going to be
HD44780 or pure-graphical, I'd say.

One major issue with "font" support is that different models and
brands of HD44780-type displays have vastly different glyphs outside
of standard alphanumerics. I have at least three types myself - LCD
w/Japanese Katakana, LCD w/European, and VFD w/Katakana, and I think
there are one or two more major types out there.

I have been able to use non-Roman ASCII glyphs by sending the "right"
8-bit code from the client (most notably for handling "degrees" from a
weather client), but since there is no character-set mapping, if I run
that same client on different displays, I get different results (the
VFD has a single-position glyph for 'degrees F' and 'degrees C', but
the other displays have a degree-looking mark that's either a
plosive-modifier for Kana or some sort of dot in the European set).
What I've done there is to have some internal options to select one of
four different ways of expressing "degrees", some 1-char-wide, some
2-chars wide). It's messy, but given the way that LCDproc was
designed in the first place, I don't know of a way to do it across all
or most supported displays.

I've written another client to display Japanese vocabulary words using
the Katakana set that's on many HD44780s, but if you run the same
client on a display with European accented characters up at the top of
the character set, it's gibberish, and the client has no way to know

Perhaps what's called for is a mechanism where at least the client can
query the server (and indirectly LCDd.conf) if a particular character
set is present. That way, my Japanese vocabulary builder client could
know that you don't have a Japanese-friendly display up, or my weather
client could know which methods of indicating 'degrees' will display

You'd still have to manually map your Greek or Swedish or Japanese
chars in your client from your native set to what an HD44780 supports
in ROM, but at least you'd be able to verify first that the mapping
you are doing will produce legible output.

If what I'm saying isn't clear, please speak up and I can share one of
these clients (written in Perl) to illustrate how I'm sending these
chars from the client.


Archive powered by MHonArc 2.6.18.

Top of page