LCDproc development and user support list

Text archives Help


[Lcdproc] Non-Latin characters in LCDd.conf


Chronological Thread 
  • From: ethan.dicks at gmail.com (Ethan Dicks)
  • Subject: [Lcdproc] Non-Latin characters in LCDd.conf
  • Date: Sat, 29 Nov 2008 04:35:51 +1300

On Sat, Nov 29, 2008 at 3:44 AM, <hansfong at zonnet.nl> wrote:
> Citeren Ethan Dicks <ethan.dicks at gmail.com>:
>
>> 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.
>
> Thank you Ethan for this excellent explanation.

You are welcome. I'm glad it all made sense.

> Now my question is: how do
> you know what characters are in the ROM and how to address them?

Ultimately, you have to know what version of HD44780 display is in
there. The two most common character sets (European and Japanese
above 0x80) are documented in datasheets for the HD44780 and various
modern chip clones. It shouldn't be too hard to find a PDF for a real
HD44780.

You could always write a client to display 16 chars on each line, and
rotate through the character set. It's documented in the datasheets
for the HD44780, but typically, 0x00-0x07 are the user-definable
characters, with 0x08-0x0F sometimes being echoes of them. Printable
glyphs can start at 0x10 or sometimes 0x20. There are a couple
versions of the HD44780, and a few knockoffs (clones), so different
displays can have subtle differences.

One thing that's com

> I have a
> picoLCD 20x4 and I can't find any info on how to set user definable
> characters. It's not (yet) in the LCDproc documentation, probably because
> the display is rather new.

I have a picoLCD 20x4 at home, but I'm on the road. I've dug into the
code for the 20x2 picoLCD driver, and I think it was pretty
straightforward as to how it's done. Have a look for the routine that
sets the heartbeat character - that's never in any ROM character set.
You could also look at the routines that set up the bargraph glyphs -
sometimes those are in ROM, sometimes they are in user-definable chars
- it depends on what the display can do (most HD44780 drivers do it
with soft-settable chars, but my jw002 driver uses bars from the ROM
fonts).

> P.S. The character I'd like to use is the degree sign: U+00B0 ? (c2 b0)

That one, or one close to it, is probably findable in the ROM
character set, but it will depend if you have a European or Japanese
font in your display's ROM.

One example of problems caused by different ROMs is with Matrix
Orbital displays. 10 years ago LCDproc got its start with an MO 20x4
product, which is why so many clients, etc., still assume 20x4 and 8
user-settable chars, etc., even if the real display isn't like that
anymore. So for a certain MO USB display (I don't have one, but the
details are in the list archives over the past couple of years), older
versions have, IIRC, a Japanese font in ROM, but newer ones have a
European font in ROM, and there's no way for the software to tell them
apart. What's worse is that I think that font change also changed
what glyph is at 0xFF from the checkerboard character that most
displays use, and for bargraphs, etc., there aren't enough spare
user-definable characters to hide that change in the driver.

But as for how to find that degree symbol, if you have a Japanese ROM,
you'll probably find that there's a small "block o" character that is
close enough - it's used in Japanese to turn a H-sound into a P-sound
(HA->PA, HE->PE...) If you have a European ROM, I don't recall if
there is a handy char or not, but it won't be at the same address as
with the Japanese ROM. This is where writing a client to try 16
chars/line to display the internal font could come in handy.

Sorry this is so difficult, but LCDproc is trying to abstract client
requests from display limitations, and sometimes, choices made a
decade ago based on how one particular (but very common) type of
display works. In particular, things that perhaps should have been
abstracted weren't because at the time, there wasn't the variety of
displays we have now. Since I've written a few drivers over the
years, I've had to deal with a large number of things that just don't
work for every single type of display, so I put a lot of flexibility
into my clients to compensate. Some things, like "degrees", I think
should be handled by the driver, not by the clients, but that would
take some deep changes that I doubt will happen with 0.5.

-ethan




Archive powered by MHonArc 2.6.18.

Top of page