LCDproc development and user support list

Text archives Help

[Lcdproc] Source of strange chars with Matrix Orbital VKD204 and LCDproc 0.5.2 located!

Chronological Thread 
  • From: ethan.dicks AT (Ethan Dicks)
  • Subject: [Lcdproc] Source of strange chars with Matrix Orbital VKD204 and LCDproc 0.5.2 located!
  • Date: Mon May 14 20:18:02 2007

> On 5/13/07, Peter Marschall
> <peter AT>
> wrote:
> > The MO manuals are quite a mess with regard to the commands
> > understood by a certain display.

Peter (et al.),

I have finally dug through over 40 manuals to find some interesting
things about various MO modules and documented command sets. I see at
least 3 ROM character sets, one of which (a newer one) does not have a
solid block at 0xFF. I also see that the older LCDs support backlight
on/off plus contrast, the newer LCDs support backlight intensity,
*display* on/off plus contrast, while VFDs support display on/off plus
display intensity. I see VFD display intensity incorrectly documented
with some modules to support 0-255, some where 0x01 is both 25% and
50%, some where 0x00 is 25%, and a few where it's correctly documented
that 0x00 is 100% and 0x03 is 25%. It doesn't help that you have to
read multiple versions of the MO docs for a given display to see the
range. It's not like one model is all correct and another is all

I have a spreadsheet with the display types, manual file names,
contrast commands, brightness commands, font, etc., all lined up for
easy examination. For the record, only vk204-25_123.pdf,
VFD2041_110.pdf, and VFD2041_150.pdf have VFD brightness correctly
documented; the rest I examined do not (and LCD2041_rev_20.pdf,
LCD0821_rev_20.pdf, LK204-25.pdf, LK402-25.pdf, and
LK404-25_rev_20.pdf document modules without a solid block at 0xFF).

It seems that relying on the returned module type and recently-added
firmware version codes to scope out a modules features would result in
a madhouse of criscrossing attributes. I am now firmly convinced that
if we are to support MO displays in a way that doesn't cause each new
user to say "I have garbage on my screen" every time there's a new
module released or a change to the MO driver code, I think we have to
permit (but not require) the user to tell the driver what attributes
matter for their particular display.

In my case, it seems reasonable to key the MO brightness command byte
off of VKD/VFD vs LCD/LKD. Where it gets sticky is what to do about
older LCDs that use backlight on/off vs newer LCDs that use display
on/off with a backlight brighness command.

We can certainly flip the sense of the VFD brightness so that 0-1000
means darkest to lightest, but there should be some additional
comments in LCDd.conf to explain that (and by "additional comments", I
mean I'm happy to write them).

Unfortunately, I don't have any sort of Matrix Orbital LCD to test
except PalmORB. I haven't inspected its souce, but since a) it's old,
and b) the Palm backlight is on/off, it should behave like an older
Matrix Orbital LCD. What I can't test is how newer ones behave.

I think there are probably only about 3 Matrix Orbital users who post
regularly here, so if you have an MO display and have an opinion about
this, speak up. I'm not asking users to write the code, but I would
like some feedback on any proposed changes to be able to support all
Matrix Orbital users.



Archive powered by MHonArc 2.6.18.

Top of page