[Lcdproc] MtxOrb problem

Thu Oct 5 01:16:01 2006

Ok - we're making progress!  (I know I'm slow - I only recently saw the
light and switched to Linux.  My brain is still numb from Windows)...

The old drivers from /usr/lib/lcdproc were indeed being loaded.  I deleted
that directory and pointed LCDd.conf to /usr/local/lib/lcdproc.  Now I have
graphics!  Sort of....

The display shows some graphics blocks (eg: big digit clock) but the screen
flickers rapidly.  As well, other graphics characters which should be bar
graphs look like clover leaves and strange squiggles.

My model is an MX212 - which perhaps is incompatible with Ethan's model
(though I doubt it).  As a next step I can answer every question below - or
investigate in a new direction (let me know).  Ethan: anything I can test?

As for contributing - that sounds great.  I would like to improve the
init-XXX.rpm scripts so I will do so.  Having never contributed before, do I
email you new versions?  Do I need to use the diff tool?  (Should I RTFM
which may be somewhere you're going to point me?)

Thanks,
MD

-----Original Message-----
From: lcdproc-admin@lists.omnipotent.net
[mailto:lcdproc-admin@lists.omnipotent.net] On Behalf Of Peter Marschall
Sent: Wednesday, October 04, 2006 3:34 PM
To: lcdproc@lists.omnipotent.net
Subject: Re: [Lcdproc] MtxOrb problem

Hi Michelle,

On Wednesday, 4. October 2006 18:56, Michelle Dupuis wrote:
> I downloaded the Oct 4 CVS build, and have the same results.  No graphics
>
> I did a make clean, make, make install.  The LCDd daemon and lcdproc both
> start perfectly - but still now graphics.
>
> I confirmed the file running is LCDd in my /usr/local/sbin directory, and
> it's dated today (time of my make). Any ideas?

If you read my post again, you may notice that I spoke of MtxOrb.so,
the MtxOrb driver.

There is a high probability that your LCDd.conf points all to an old version

of this MtxOrb.so driver.
(That's why it is a always a good idea to reply to exactly tht post that one

refers to)

Since the driver getsy dynamically loaded at run time by the server, and
I haven't made changes to the internal structures recently there is a very 
high probability that a new LCDd can work with the old driver.

Please provide a detailed (i.e. command by command !!!) description
what to did to test the new LCDproc:
- starting with the download - how was the .tgz file named
- over to the extraction - how was the directory named
- ... the configuration - what parameters did you give to configure
- ... the compilation - how did you do iz
- ... the installation - where to, what did you do exactl
- till the start of the LCDd daemon - how did you start it

I tend to think of this as a local configuration problem since I got
repeated confirmations that the driver works by Ethan dicks who
also helped in ironing out a few bugs by sending patches.
He also confirmend that the keypad works.

And without a detailed step-by-step list of what you did to get the
new version running there is no chance in finding out what went wrong.

> Oh yeah - just to add to your todo list :)
LCDproc is open-source & community driven software.
I am only the maintainer. I.e. I try to coordinate, to make people
test new versions, commit to CVS, try to help on the ML, ...
Please send patches.

> the init-lcdproc.rpm script has an error: it still tries to load lcdproc
> with invalid parameters.  
Please do not make me guess. Either send a patch or at least tell where.
I do not have an RPM based distribution so some of the commands and
paths don't tell me anything. And without knowledge fixing bugs is
a rather error-prone task (hardly ideal for bug-fixing)

> As well, if you change the init- scripts to have 
> X permission, then users can just symlink from /etc/init.d/

The init scripts predate my connection with LCDproc.
I do not know whether the commands and paths in them are
still legal/useful in a modern LSB based system.
Neither do I know for exactly wht RPM based distribution they
were written.
Since LCdproc is a source-only distribution these files should be
considered as hints for the users / packagers only.

Of course, if somebody volunteers to maintain these scripts and associated 
.spec files (that need to be writen) so that they are known to work
on modern RPM-based LSB distributions, then the situation changes
drastically.

> And finally, how about adding a -V command to both programs?  It would be
a
> great way to confirm the build number etc.

If you want to have it done, please send patches.
But i doubt it helps with your problem since the drivers - as described 
above - get loaded dynamically and they currently do not have a version 
number.

Hope it helps
Peter
-- 
Peter Marschall
peter@adpm.de
_______________________________________________
LCDproc mailing list
LCDproc@lists.omnipotent.net
http://lists.omnipotent.net/mailman/listinfo/lcdproc