First login?
Lost password?
 
 
lcdproc AT lists.lcdproc.org 
LCDproc development and user support list

Text archives Help


[Lcdproc] OSX + MtxOrb Driver


Chronological Thread 
  • From: kdogden at gmail.com (Kevin Ogden)
  • Subject: [Lcdproc] OSX + MtxOrb Driver
  • Date: Wed, 17 Sep 2008 14:21:14 -0400

>
> I'd rather not apply the patch you virtually attached to this mail
> in its current form.

I wouldn't either, it's disgusting. I was just trying to show what I
ended up changing to get it to work on my odd machine with my poorly
documented LCD hardware. I'm a far from elegant C coder. I do more
in LISP and TCL than anything else. I wasn't really trying to submit
an "official" patch ;-)

> I consider the patch a mix that tries to tackle multiple issues at
> once:
> - backlight command
> - new option GPOs
> - ONDELAY
>
> Let's start with the backlight command:
> Although the command in LCDproc is called MtxOrb_backlight,
> it does not switch the backlight on & off, but simulates this
> only by changing the brightness of the display: When set
> to on, the value of the config setting "Brightness" is used,
> while when set to off, "OffBrightness" is used.
> This allows more flexibility, and makes newer revisions of
> LK202-25 (and others) displays work where the x42 command
> is called "display off" (and does that).
> Unfortunately this command is not documented (maby not even
> implemented) in some older revisions of LK202-25.

It seems that this product line received several nearly-compatible
revisions. Changing the MtxOrb_backlight command to x42 seemed to
work for me though.

> What exact revision do you own ?

It's pretty damn old. I think I bought it in 2001 or 2002. Not sure
of the rev number but I could probably find out for you tonight.

> What are the symptoms you experience when you change
> the value back to its original value ?

A "V" replacing the character at the beginning and end of most
screens and occasionally a couple scattered throughout the display.
Sometimes the "V" was followed by an underscore or vertical line
character. If I just sent some text to the display via screen
(screen /dev/tty.serial1 19200) there was no garbage characters.

> Do I need to tell that I hate the various different revisions
> of manuals for each of the zillions of MatrixOrbital display
> types. If thy only had a consistent notation for the commands:
> sometimes hex, sometimes decimal, sometimes ASCII, ...
> I literally spent weeks finding the compromise that is currently in
> LCDproc.
> (Not even MatroxOrbital was able to provide me with a concise
> set of commands available in what revison of what display type)

I feel your pain. I was getting really frustrated with this myself.
I was getting ready to just say screw it and write a simple uptime/
cpu graph toy in TCL and just throw in a couple of LCD commands I
really needed (for clearing the screen, contrast, etc.).

It's a real pretty little red display with GPOs and keypad input BUT
was really expensive and poorly documented.

> If it is necessary, can you define it in a way that keeps
> the default values to those hat are currently used as the
> values for the different display types (for compatibility's sake) ?
>
> And can you pleas add the necessary documentation to
> docs/lcdproc-user/drivers/mtxorb.docbook
> so that other users can profit from your work ?

The GPO patch was someone else's work that was dug up on the
archives. Ethan pointed it out to me and it didn't quite solve the
problem I was having but I left it in because to me it seemed to make
sense. Anything that gives me options I can tweak without
recompiling is a good thing IMHO.

>> I think you said that O_NDELAY flag to the open call may not be
>> necessary if you use /dev/cu.serial1 though. I really don't want to
>> mess with it at the moment now that it's working though.
>
> Would you mind testing this ?

I can probably test it sometime tonight or tomorrow.

> I'd rather not apply the patch blindly because it helps you
> but may hurt other users with different operating systems.
> Especially as Ethan wrote that it works for /dev/cu.serial1
> without the patch.

I can test it. Hopefully it works fine without that change and I
suspect it will. I was just trying everything I could to make this
go and this probably wasn't necessary but that's where I started when
trying to get this display going. I didn't know the cu.serial1
device even existed until I went looking for it after it was
mentioned. It kinda makes sense, under FreeBSD, my serial port is /
dev/cuad0.

> So,with respect to the GPOs I am open fr a patch that keeps
> compatibility and contains documentation,
> with respect to O_NDELAY I am very dubious,
> and with respect to the backlights, I need more information.

I don't think O_NDELAY is quite necessary but the backlight command
hack DID solve my problem with this display under both FreeBSD and
MacOS X.

Thanks,
Kevin D. Ogden


Archive powered by MHonArc 2.6.18.

Top of page