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 13:54:02 2007

On 5/13/07, Peter Marschall
<peter AT>
> Hi Ethan,
> first let me thank you for your in-depth analysis.

You are quite welcome. I've been a programmer for long enough (and
done "front-line" customer support for expensive products), so I try
to do a lot better than "it doesn't work".

> BTW my LK202-25 works without problems using type "lkd".

Good to know.

> The MO manuals are quite a mess with regard to the commands
> understood by a certain display.

Indeed - the docs span several formatting styles, some have summaries
by number, some do not, etc.

> Sometimes the list of contents mentions other codes than
> those found in the section referenced, sometimes the list
> summarizing the commands differs from the detailed
> sections, ...
> I cannot exactly tell what's correct

Completely understandable.

> And don't forget the amount of manuals: one for each product
> (about 45) and sometimes up to 4 different releases !!!

I've begun to compile a table of the backlight/brightness/display
on/off differences - I've only read through about a dozen manuals so
far - plenty left to go. One thing I have spotted already is that for
a given model of LK-type display, older revisions use 'B' and 'F' for
backlight on and off, where some newer boards use the same codes for
*display* on and off. There appears to be no requirement that
backlight on/off vs display on/off commands imply a fixed backlight
brightness or variable (254 / 153) backlight brightness.

> To cut a long story short: the patch suggested above will be in
> tonight's nightly tar ball (together with turning off autoscroll)

Nice. I'll grab that and test this week.

> I was in contact with MO whether they were able to give me
> a list to map manual revisions to firmware releases.
> Unfortunately they were not able to compile such a list.

I am compiling that map now. Should take me a little bit of time, but
be worth the effort.

> So, I thought, it is better to use the newer commands so that
> people that buy a new display have it supported.

In general, I can see how that's the safe choice, but I think there
should be some way to tell the Matrix Orbital driver exactly how ones
display should behave, even if the default is "new commands".

> Please see below for a discussion of the types.
> Maybe our understanding of the types differs.
> According to
> section 10.4 it is \x99 (dec 153).

Agreed. After your response, I went digging in the right places and
confirmed for myself. With so many modules, I just hadn't checked the
right manuals.

> > Also, somewhere, in LCDd.conf perhaps, there should be some mention
> > that for a VFD, a brightness of 0x00 is the brightest (100%) and 0x03
> > is the dimmest (25%). It is not what you might expect that putting a
> > brightness of 1000 in the LCDd.conf will give you a brighter screen
> > than using 0. The code doesn't have to change, but something should
> > be said to the user so it isn't confusing. Note that there could be
> > some developer confusion if one is merely reading manuals. I caught a
> > thread in the Matrix Orbital forums that at least one newer manual has
> > it wrong and incorrectly documents a brightness of 0x03 equaling 100%
> > and 0x00 equaling 25%.
> Hmmm, I guess you are sure of that since you got the hardware.
> But I guess it is not only a few manuals that got it wrong.
> All manuals I have looked at so far tell: 0=25%, ..3=100%.

My original paper manual (not available for download), documents it correctly.

Here's the forum comment where it's pointed out that the documentation
between versions changed incorrectly (i.e. - the module behavior
stayed the same - only the description was backwards in the newer

> I'd rather have it corrected in the code instead of documenting
> the behaviour to have consistent behaviour for all drivers.

If you mean that you want brightness to always mean a larger number, I
don't mind that - the user doesn't care what chars get sent to the
display - as long as the template LCDd.conf makes it clear what
brightness means (and that there are only 4 possibilities for a VFD,
not 256), that's fine.

> If the type of display is known, a simple patch such as
> if (IS_xxx_DISPLAY)
> promille = 100 - promille;
> when setting (or evaluating -- dunno where's the better place)
> the brightness should help.


> Would you mind to play around with it (and extend you patch ;-)?

Not at all.

> BTW I have only extended the MtxOrb driver and have only partially
> understood
> the exact meaning of the type parameter:
> Do you know the type values are supposed to map to the displays names or to
> product IDs ?

I have built a map of (most of? some of?) the model names from
reading multiple documents, but with internal revisions, one can't
"know" if a display supports backlight brightness or display on/off
unless that display also supports the "read version" (254 / 54)
command as well as "read module type" (254 / 55)...

0x01 LCD0821
0x02 LCD2021
0x03 LCD2021
0x04 LCD1641
0x05 LCD2041
0x06 LCD4021
0x07 LCD4041
0x08 LK202-25
0x09 LK204-25
0x0A LK404-55
0x0B VFD2021
0x0C VFD2041
0x0D VFD4021
0x0E VK202-25
0x0F VK204-25
0x10 GLC12232
0x11 GLC12864
0x12 GLC128128
0x13 GLC128128-25
0x14 GLK12864-25
0x15 GLK24064-25
0x21 GLK1231238-25
0x22 GLK12232-25
0x24 GLK12232-25-SM
0x31 LK404-AT
0x32 VFD1621
0x33 LK404-12
0x34 LK162-12
0x35 LK204-25PC
0x36 LK202-24-USB
0x37 VK202-24-USB
0x38 LK204-24-USB
0x39 VK204-24-USB
0x3A PK162-12
0x3B VK162-12
0x3C MOS-AP-162A
0x3D PK202-25
0x3E MOS-AL-162A
0x40 MOS-AV-202A
0x41 MOS-AP-202A
0x42 PK202-24-USB
0x43 MOS-AL-082
0x44 MOS-AL-204
0x45 MOS-AV-204
0x46 MOS-AL-402
0x47 MOS-AV-402
0x48 LK082-12
0x49 VK402-12
0x4A VK404-25
0x4B LK402-25
0x4C VK402-25
0x4D PK204-25
0x72 GLK240128-25
0x73 LK404-25
0x74 VK404-25

> Here's my idea (basically based on the first 2 characters of the product
> ID):
> ID Product ID type (my understanding)
> 1 LCD0821 lcd
> 4C VK402-25 vkd
> Do you agree with this?

Essentially, yes. I think, however, that the MO driver should be able
to understand explicit directives in LCDd.conf more precise than
vfd/vkd/lcd/lkd (though those are a good start). I'll go off and
think about it for a bit before I make any suggestions (or code
patches ;-)

> I do not know whether this list, which is from section 12.3 of the
> LK202-25 manual v3.0, is comprehensive.

As you can see from my additions, it's not a comprehensive list, nor
do I claim mine is (I know at least 2 models that are missing, from
modules that were shipped in the 1999-2000 timeframe).

It is both a blessing and a curse that MO has so many modules. I got
my VFD long ago when I was working on LCDproc 3.x, since at the time,
it was the best supported product (and I talked my former employer
into spending real money on a VFD so we could see it across the room).
There are so many more vendor and module options now that it's hard
to keep the MO driver current, but since I have a very nice display
that's worked well for 8 years, unless I want to play with some of the
PWM GPO or Dallas 1-wire features, I have no reason to "upgrade".
Fortunately, I'm happy to continue to keep testing LCDproc against
this module for as long as it continues to work (and I have a spare
bare-VFD module I picked up on eBay for $20, so unless the backpack
fries, I can keep this module working for a long time).


Archive powered by MHonArc 2.6.18.

Top of page