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

[Ethan Dicks]

On 5/13/07, Peter Marschall <peter@adpm.de> wrote:
> 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
> http://www.matrixorbital.ca/manuals/LK_series/LK202-25/LK202-25_rev_30.pdf
> 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
manual).

http://www.lcdforums.com/forums/viewtopic.php?p=18346&highlight=vfd+brightness#18346

> 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.

Sure.

> 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).

-ethan