LCDproc development and user support list

Text archives Help

[Lcdproc] OSX + MtxOrb Driver

Chronological Thread 
  • From: peter at (Peter Marschall)
  • Subject: [Lcdproc] OSX + MtxOrb Driver
  • Date: Wed, 17 Sep 2008 19:19:41 +0200

Hi Kevin,

On Thursday, 4. September 2008, Kevin Ogden wrote:
> AWESOME! OK, it's working now, I've attached a diff with all the
> mangling of MtxOrb.c I've done along with my LCDd.conf.
> It's now working flawlessly under OSX with my old Matrix Orbital
> LK202-25 display with no extra 'V' characters or anything. Looking
> at the manual, it said the backlight command was 254 66 0, which in
> hex is FE 42 0. Along with the GPO patch and a slight addition
> relating to DCD using '/dev/tty.serial1' on my generic P4 running OSX
> it's working fine.

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

I consider the patch a mix that tries to tackle multiple issues at once:
- backlight command
- new option GPOs

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.
What exact revision do you own ?
What are the symptoms you experience when you change
the value back to its original value ?

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)

Now to the GPOs option:
If possible, I'd like to avoid creating new options that
may break the behaviour of existing implementations.
Is it really necessary ?
Can't int be inferred from the display type?

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
so that other users can profit from your work ?

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

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.


Peter Marschall
peter at

Archive powered by MHonArc 2.6.18.

Top of page