lcd4linux-users — lcd4linux users

[lcd4linux] Is this Controller working with LCD4Linux? S1D13305F

[Thomas S. <se...@gm...>]

Hi Folks,
 
can somebody tell me if it is possible to work with lcd4linux
and this components:
 
LCD 320*240
S1D13305F Controller (newest rev. of SED 1330)
 
 
Thank you fpr our help and comments.
 
Greetings from Germany
Thomas Seliger

Re: [lcd4linux] Re: need help with autmake, libtool and

[Michael R. <re...@eu...>]

Hi Ronald,


>> - is the .$OBJEXT (instead of .$(OBJEXT) correct?
> 
> No: $(OBJEXT) is a Makefile variable, whereas $OBJEXT (or ${OBJEXT}
> is a shell variable. As OBJEXT is canonically defined in the
> Makefile, you should use the makefile variant.

Now I understand!

>> - should the local 'libtool' script be included - in CVS
> 
> IMHO, no: there should be no generated files in CVS - so configure
> and Makefile.in shouldn't be there either, IMHO. Opinions may differ
> rather widely on this, though, but I've found it's often more trouble
> than it's worth to have generated files in CVS if you have the 
> sources as well.

I would agree with you, if every user who wants to try to use the CVS 
version would not be forced to have the complete automake and libtool 
toolchain installed.

I know there are some troubles, especially if different versions of the 
toolchain are around. I think we can live with this. It's better if 5% 
of CVS users have version problems than 50% have no chance to use CVS 
because of their missing toolchain.

bye, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] missing .conf file

[Michael R. <re...@eu...>]

Hi Thomas,


Thomas Heinrich wrote:
> After install I opened the prog with -h and it runs: shows me the
> versionsinfo and some more.
> 
> But when I try to start with -q the prog is missing the file
> lcd4linux.conf
> 
> I searched manually, but this file does't exist. Is this normal
> or what can I do?

Yes, this is normal. 'make install' does not install a config file, but 
you will find a lcd4linux.conf.sample in your source directory. Just 
copy this file to /etc/lcd4linux.conf, and edit it to fit your needs (at 
least specify your display and connection)


bye, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

[lcd4linux] missing .conf file

[Thomas H. <t_h...@gm...>]

Hi
I just wanted to test this wonderful prog.
After install I opened the prog with -h and it runs: shows me the
versionsinfo and some more.

But when I try to start with -q the prog is missing the file
lcd4linux.conf

I searched manually, but this file does't exist. Is this normal
or what can I do?

Thank you for your help.

-- 
Ciao
Thomas  Heinrich                          mailto:t_h...@gm...

Re: [lcd4linux] Re: need help with autmake, libtool and

[Ronald Landheer-C. <bly...@us...>]

On Sat, Oct 04, 2003 at 09:57:26AM +0200, Michael Reinelt wrote:
> first I want to thank you for your support!
You're welcome :)

> Ronald Landheer-Cieslak wrote:
> >The attached patch will partly fix that. What still needs fixing after this
> >patch is using Libtool to build the object files needed by DRIVERS, but 
> >that means changing configure.in to set up drivers correctly (i.e. using
> >$(OBJEXT) in stead of .o)
> >
> >The patch also re-enables Libtool in configure.in, but doesn't fix DRIVERS
> >(yet).
> 
> Ok, I applied your patch, and changed all .o to .$OBJECT in configure.in 
> (without parens!) It works, at least for me. I checked all the cnages 
> into CVS!
> 
> But there are several questions:
> - is the .$OBJEXT (instead of .$(OBJEXT) correct?
No: $(OBJEXT) is a Makefile variable, whereas $OBJEXT (or ${OBJEXT} is a shell
variable. As OBJEXT is canonically defined in the Makefile, you should use the
makefile variant.
> >I've also attached a bootstrap script for lcd4linux.
> - what the ehck is a bootstrap script?
It's the script used to launch the Autotools, to create the configure and
Makefile.in files (and libtool)
> - should it be included
>   - in CVS
Yes
>   - in the distribution tarball?
No.

> - is AM_PROG_LIBTOOL necessary in configure.in? (it's deactivated at the 
> moment)
No: it's the deprecated form of AC_PROG_LIBTOOL

> - should the local 'libtool' script be included
>   - in CVS
IMHO, no: there should be no generated files in CVS - so configure and 
Makefile.in shouldn't be there either, IMHO.
Opinions may differ rather widely on this, though, but I've found it's often
more trouble than it's worth to have generated files in CVS if you have the
sources as well.

>   - in the distribution tarball?
Yes.

> - lcd4linux (the main program) is linked against the shared 
> liblcd4linux. Is it possible to build liblcd4linux as it is now, but 
> lcd4linux as a real standalone application (without liblcd4linux?) Would 
> this make sense?
Personally, I'd go for using a shared lib, but if you don't want to, the 
easiest way to force static linking is to use the proper configure option
(--disable-shared). You can do that by default by checking for it in
configure.in and setting it to disabled of not explicitly set to enabled.
That way, the final choice is with the end user - the one that compiles his
own version - or with the packager, if there is one.

rlc

Re: [lcd4linux] Re: need help with autmake, libtool and

[Michael R. <re...@eu...>]

Ronald,

I think I finally got it to work. I thought it worked already two days
before, but this seemed do be a mistake.

Ronald Landheer-Cieslak schrieb:
> The attached patch will partly fix that. What still needs fixing
> after this
> patch is using Libtool to build the object files needed by DRIVERS,
> but that means changing configure.in to set up drivers correctly
> (i.e. using $(OBJEXT) in stead of .o)

My main fault was that the DRIVERS list built by configure (depending on
the --with-driver=...) had originally '.o' as an extension. I changed
this to '.$(OBJEXT)' as you suggested. But an object file for a libtool
library has to have the extension '.lo'.

So I changed everything from '.$OBJEXT' to '.lo' in configure.in It 
seems to work now.


Last Question: is there a variable holding th 'lo' string, similar to
OBJEXT for the 'o'? I think it would be cleaner to use such a variable...


Thanks, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

[lcd4linux] lcd4linux design ideas

[Michael R. <re...@eu...>]

Hi lcd4linux-users,

I want to give you some feedback about what has happened in my brain the 
past days...


As some of you might know, I got two really cool displays from 
MatrixOrbital. They have features that lcd4linux does not support at the 
moment, so I tried to implement them:

- Keypad support
- temperature sensors
- Fan RPM measurement
- Fan PWM control

You could dividethem into two parts: input functions (keypad, sensors) 
and output functions. I decided to work on the output first.

The Fan PWM control acts like a normal GPO (which would be supported by 
lcd4linux), but it's not a 'digital' one (which could be switched on or 
of), but an analog one, which can have values from 0 (switched off) to 
255 (full power). There's no support for such an analog GPO in 
lcd4linux. I started to modify this.

Then I realized that building a value for such a GPO isn't that easy. 
Think of a combination of one or more temperature sensors, and the fan 
RPM control. How would you configure this?

The best way would be the possibility to specify an algebraic 
expression, like

fan1 = 1000+150*log(30+0.25*temp2) + 250*(25+0.18*temp3)

such expressions would be cool with 'normal' GPO's, too. Now you can 
configure a GPO to be sensitive to any token, e.g. 'disk write:

GPO1 %dw

It would be activated whenever one single bit would go to the disk

better would be

GPO1 %dw>1000
or
GPO1 %dw>%dr

or anything you could think of...


Then I found a little piece of code, called the "Expression Evaluator" 
by Mark Morley, and found this a very small and simple solution for my 
issues. The code supports 'normal' algebraic expressions (2+3), variable 
assignments (a=3; b=5; c=2*a+b), functions (sin(25*b), and can be easily 
extended or new functions added.

To those concerned about size: It's really small, believe me! I cannot 
tell you exactly at the moment (as it does not compile), but I got an 
earlier version compiled and linked as a simple example, which has 10k.


I already extended the code to support 'logical' expressions (a>5,
b>10 & (c | d<100), and at the moment I'm implementing 'string' functions.


As the code is that simple, and new functions can be easily registered, 
I thought this could be the basis for a redesign of some lcd4linux 
internals:

Clients: Every client registers one or more new functions, and handles 
these functions with parameters:

e.g. net(interface, direction) could be: net('*', 'r') or net('eth1', 'rw')

So the long-wished 'statistices for each lan interface' could be solved 
this way


One could do calculations with these functions:

If you prefer PPP throughput in bytes/sec, you use ppp(0, r)
If you prefer kB/sec, use ppp(0,r)/1024
If you prefer MB/h, use ppp(0,r)/1024/1024*3600

other advantage: the 'temp1.factor' and 'temp1.offset' would be obsolete...

There would be a 'transform' function, where you could specify the field 
width and number of decimals, which is fixed now. Maybe like C printf(), 
maybe like dBase ('####.##')


The layout config scheme would stay as it is, but would support such 
expressions, too.


Code is not in the CVS by now, because it doesn't even compile. But this 
will change really quick...


What do you think about this? Have you got any other ideas what we could 
solve with this method? Do you think this is a good idea?


All comments are welcome!


bye, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] Re: need help with autmake, libtool and

[Michael R. <re...@eu...>]

Hi Martin,

you forgot to CC your answer to the list!


>> Martin, you like small applications very much :-) Would you prefer 
>> lcd4linux depending on the shared lib, or as a independent application?
> 
> Well, since usually, the (stripped) statically linked executable is 
> significantly (ok, 1k is already significant, in the embedded 
> environment I'm looking at) smaller than the (stripped) binary linked 
> against the (stripped) shared lib, plus the shared lib. So, unless there 
> is at least another app that uses that lib, I prefer the statically 
> linked version. Having said that, I think it would be the "cleaner" 
> approach to have lcd4linux link dynamically against liblcd4linux.

I think so, too. I just feared that the shared lib would have some bad 
influences on lcd4linux, and therefore preferred not to touch lcd4linux. 
But if it works clean and fine, I would also use the link against shared 
liblcd4linux.

> Just so I understand this correctly - the way it is now, _all_ I'm 
> supposed to do is to run configure and make, right? Ppreviously, I also 
> ran aclocal and autoconf, since without it, it didn't even configure 
> (let alone compile) on my system.

Hmmm... that's what I've never been shure of, too. Whenever something 
strange happened while compiling, I keyed in 'auto' and pressed Tab 
twice, so my bash completion showed me all executables starting with 
'auto'. I started them all several timne, and after a while, everything 
worked again :-)

I think it depends wheter you're using the CVS version or the 
distribution tarball, because different files are included in each.

I also have never been shure which files to include in either archive.

Ronald?


bye, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] Re: need help with autmake, libtool and

[Michael R. <re...@eu...>]

Hi Ronald,

first I want to thank you for your support!


Ronald Landheer-Cieslak wrote:
> The attached patch will partly fix that. What still needs fixing after this
> patch is using Libtool to build the object files needed by DRIVERS, but 
> that means changing configure.in to set up drivers correctly (i.e. using
> $(OBJEXT) in stead of .o)
> 
> The patch also re-enables Libtool in configure.in, but doesn't fix DRIVERS
> (yet).

Ok, I applied your patch, and changed all .o to .$OBJECT in configure.in 
(without parens!) It works, at least for me. I checked all the cnages 
into CVS!

But there are several questions:

- is the .$OBJEXT (instead of .$(OBJEXT) correct?

> I've also attached a bootstrap script for lcd4linux.

- what the ehck is a bootstrap script?
- should it be included
   - in CVS
   - in the distribution tarball?

- is AM_PROG_LIBTOOL necessary in configure.in? (it's deactivated at the 
moment)

- should the local 'libtool' script be included
   - in CVS
   - in the distribution tarball?


- lcd4linux (the main program) is linked against the shared 
liblcd4linux. Is it possible to build liblcd4linux as it is now, but 
lcd4linux as a real standalone application (without liblcd4linux?) Would 
this make sense?

Martin, you like small applications very much :-) Would you prefer 
lcd4linux depending on the shared lib, or as a independent application?

Martin, Patrick: does the new version work for you?


bye, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] rows and columns on my m50530 baseed lcd

[Michael R. <re...@eu...>]

Stefan Krister schrieb:
> I have a 8x20 LCD based on a M50530 chip.
> 
> I'm only able to get all the LCD positions when I configure it as a 4x40
> LCD. And then, the 1st defined row goes into the 1st LCD row _and_ 5th
> LCD row. Same with the other rows.
> 
> Not a great thing - I only want to mention it.
> 
> In 8x20 mode, the first 4 positions of the rows 5 to 8 are always empty.
> Don't know, whats the matter.

My M50530 is a 24x8, and works fine. So there may be different display 
RAM layouts out there, which may not be implemented in lcd4linux.

Have you got a datasheet for your display? If you send it to me, I will 
implement at least your layout.

bye, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

[lcd4linux] Re: need help with autmake, libtool and

[Ronald Landheer-C. <bly...@us...>]

The attached patch will partly fix that. What still needs fixing after this
patch is using Libtool to build the object files needed by DRIVERS, but 
that means changing configure.in to set up drivers correctly (i.e. using
$(OBJEXT) in stead of .o)

The patch also re-enables Libtool in configure.in, but doesn't fix DRIVERS
(yet).

I've also attached a bootstrap script for lcd4linux.

HTH

rlc

On Thu, Oct 02, 2003 at 08:28:30PM +0200, Patrick Schemitz wrote:
> > > I also had to remove @DRIVERS@ from liblcd4linux_la_SOURCES, automake
> > > complained:
> > > 
> > >    Makefile.am:75: `liblcd4linux_la_SOURCES' includes configure
> > >    substitution `@DRIVERS@', and is referred to from
> > >    `liblcd4linux_la_SOURCES': configure substitutions not allowed in
> > >    _SOURCES variables
> > Try adding this at the top:
> > DRIVERS=@DRIVERS@
> > 
> > and this at the place where you removed @DRIVERS@:
> > 
> > $(DRIVERS)
> 
> $ automake
> configure.in:259: `DRIVERS' includes configure substitution `@DRIVERS@', and is referred to from `liblcd4linux_la_SOURCES': configure substitutions not allowed in _SOURCES variables
> 
> Ciao, patrick
> -- 
> Patrick Schemitz <http://www-ekp.physik.uni-karlsruhe.de/~schemitz>

-- 
One FISHWICH coming up!!

[lcd4linux] rows and columns on my m50530 baseed lcd

[Stefan K. <ste...@cr...>]

Hi,

I have a 8x20 LCD based on a M50530 chip.

I'm only able to get all the LCD positions when I configure it as a 4x40
LCD. And then, the 1st defined row goes into the 1st LCD row _and_ 5th
LCD row. Same with the other rows.

Not a great thing - I only want to mention it.

In 8x20 mode, the first 4 positions of the rows 5 to 8 are always empty.
Don't know, whats the matter.

Regards,

Stefan

Re: [lcd4linux] Bug report...

[Michael R. <re...@eu...>]

Hi Andrew,

Film-Can Web Support wrote:
> Not sure if you're using the "sourceforge" bug tracking tool, but
> I just submitted a bug report there. Nothing major, just a compile
> error in the parport driver and what I believe is the solution.

Yes, I'm using the bug tracker (otherwise I would deactivate it).

Thnaks for your report. This has been fixed in CVS and will go into 0.9.12


bye, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

[lcd4linux] Re: need help with autmake, libtool and

[Patrick S. <sch...@ek...>]

> > I also had to remove @DRIVERS@ from liblcd4linux_la_SOURCES, automake
> > complained:
> > 
> >    Makefile.am:75: `liblcd4linux_la_SOURCES' includes configure
> >    substitution `@DRIVERS@', and is referred to from
> >    `liblcd4linux_la_SOURCES': configure substitutions not allowed in
> >    _SOURCES variables
> Try adding this at the top:
> DRIVERS=@DRIVERS@
> 
> and this at the place where you removed @DRIVERS@:
> 
> $(DRIVERS)

$ automake
configure.in:259: `DRIVERS' includes configure substitution `@DRIVERS@', and is referred to from `liblcd4linux_la_SOURCES': configure substitutions not allowed in _SOURCES variables

Ciao, patrick
-- 
Patrick Schemitz <http://www-ekp.physik.uni-karlsruhe.de/~schemitz>

[lcd4linux] Re: need help with autmake, libtool and

[Martin H. <ma...@he...>]

Hi Michael.

Michael Reinelt wrote:
>>> one of the problems have been:
>>>
>>> /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.
>>> -I/usr/X11R6/include -D_GNU_SOURCE -Wall -g -O2 -c display.c
>>> ./libtool: line 1: s%^.*/%%: No such file or directory
>>> ./libtool: line 1: -e: command not found
> 
> 
> Martin, this was the error you encountered, right?
Correct. The full error I got was:

/bin/sh ./libtool --mode=link 
/nfs/ghlx02/stuff/sourceforge/src/bering-uclibc/buildtool/staging/usr/bin/gcc 
  -D_GNU_SOURCE -Wall -Os -s 
-I/nfs/ghlx02/stuff/sourceforge/src/bering-uclibc/buildtool/staging/include:/nfs/ghlx02/stuff/sourceforge/src/bering-uclibc/buildtool/staging/include/include 
  -o lcd4linux  lcd4linux.o debug.o cfg.o lock.o pid.o parser.o 
processor.o system.o isdn.o mail.o seti.o battery.o dvb.o filter.o 
udelay.o display.o pixmap.o bar.o icon.o fontmap.o exec.o mail2.o 
socket.o BeckmannEgle.o Crystalfontz.o Cwlinux.o HD44780.o M50530.o 
T6963.o USBLCD.o MatrixOrbital.o parport.o  -lm
./libtool: s%^.*/%%: No such file or directory
./libtool: -e: command not found
./libtool: -e: command not found
./libtool: -e: command not found
./libtool: -e: command not found
./libtool: -e: command not found
./libtool: -e: command not found
./libtool: -e: command not found
./libtool: -e: command not found
./libtool: -e: command not found

> Martin, Patrick, could you please report your versions, too? 
$autoconf --version
autoconf (GNU Autoconf) 2.57
Written by David J. MacKenzie and Akim Demaille.

$automake --version
automake (GNU automake) 1.6.3
Written by Tom Tromey <tr...@re...>.

$libtool --version
ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)

$ libtoolize --version
libtoolize (GNU libtool) 1.4.2

Looking at the versions you posted, it looks like my version of libtool 
is pretty old - I'll update that to something more current as soon as I 
have time.

Martin

[lcd4linux] Re: need help with autmake, libtool and

[Ronald Landheer-C. <bly...@us...>]

OK..

On Tue, Sep 30, 2003 at 10:39:05PM +0200, Patrick Schemitz wrote:
> I also had to remove @DRIVERS@ from liblcd4linux_la_SOURCES, automake
> complained:
> 
>    Makefile.am:75: `liblcd4linux_la_SOURCES' includes configure
>    substitution `@DRIVERS@', and is referred to from
>    `liblcd4linux_la_SOURCES': configure substitutions not allowed in
>    _SOURCES variables
Try adding this at the top:
DRIVERS=@DRIVERS@

and this at the place where you removed @DRIVERS@:

$(DRIVERS)

note: use ( and ); not { and }

Let me know what the results are - I think it should help :)

rlc

[lcd4linux] Re: need help with autmake, libtool and

[Ronald Landheer-C. <bly...@us...>]

On Tue, Sep 30, 2003 at 07:45:40PM +0200, Michael Reinelt wrote:
> I'm CCing this to the lcd4linux mailing list, to Martin Hejl (he has 
> encountered some problems while cross-compiling for uClibc) and to 
> Patrick Schemitz (he and me tried to build a shared library)
OK.

> >>>What exactly is the problem? Perhaps I can help..
> >>lcd4linux is a quite small and straightforward project, its main purpose
> >>is to collect some data and display it on an LCD. It's just a simple
> >>(single) application, no libraries are built.
> >>
> >>Now a guy wants to extract the hardware- and display-specific stuff into
> >>a (shared) library, and create python bindings for it.
> >>
> >>lcd4linux uses autoconf and automake, which worked fine without
> >>libraries. Now I tried to integrate a library target into automake. The
> >>first try was a static library, which was quite easy, but for python
> >>bindings you need a shared library.
> >>
> >>I tried to figure out how shared library targets are handled by
> >>automake, and found this libtool stuff. My first try succeded, but other
> >>people were having massive problems from this point on (I had to remove
> >>the target again).
> >>
> >>one of the problems have been:
> >>
> >>/bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.
> >>-I/usr/X11R6/include -D_GNU_SOURCE -Wall -g -O2 -c display.c
> >>./libtool: line 1: s%^.*/%%: No such file or directory
> >>./libtool: line 1: -e: command not found
> Martin, this was the error you encountered, right?
Looks like a buggy Libtool..

> >>other people had problems with cross-compiling for uClibc...
> >>Maybe I did the whole autoconf/automake stuff wrong (I've no experience
> >>with it).
> >Possibly, but I'd have to see what you did with your Makefile.am files, 
> >your configure.{ac|in} file and what the errors were.
> As you wrote later, the files look ok to you, you did already get the 
> package or the CVS version?
I've browsed them with ViewCVS on SourceForge.

> >Your Makefile.am file looks OK (if you re-enable Libtool).
> >Your configure.in file needs only one of AC_PROG_LIBTOOL and 
> >AM_PROG_LIBTOOL -
> >i.e. the AC_* version.
> 
> It always worked for me. But I have all the automake/autoconf/libtool 
> toolchain installed.
> 
> >What versions of the autotools were you using?
> 
> merlin:~ $ autoconf --version
> autoconf (GNU Autoconf) 2.57
> 
> merlin:~ $ automake --version
> automake (GNU automake) 1.4-p6
> 
> merlin:~ $ libtool --version
> ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.25 2003/08/01 19:08:35) Debian: 
> 49 $
> 
> merlin:~ $ libtoolize --version
> libtoolize (GNU libtool) 1.5.0a
> 
> 
> >What were the problems you 
> >encountered?
> 
> Martin, Patrick, could you please report your versions, too? And could 
> you please try to re-enable the currently commented lines in Makefile.am 
> and configure.in:
note: if their versions and your versions are not the same, it might work for 
you but not for them, as the package will be re-bootstrapped. Generally, only
developers should re-bootstrap packages: end-users shouldn't touch the 
Makefile.am or configure.in files as the changes they make will have impacts
other than just their changes on the generated scripts if their versions 
differ from yours.

I'll subscribe to the list :)

rlc

-- 
I just need enough to tide me over until I need more.
		-- Bill Hoest

[lcd4linux] Bug report...

[Film-Can W. S. <su...@fi...>]

Not sure if you're using the "sourceforge" bug tracking tool, but
I just submitted a bug report there. Nothing major, just a compile
error in the parport driver and what I believe is the solution.

Thanks for the work so far.

Andrew


-- 
+------------------------------------------------+
| _\^/_              FilmCan                     |
| >_ _<  The One-Stop Source for Movie Showtimes |
|  '|`         http://www.film-can.com           |
| Phone: 599-5041                  Fax: 599-4013 |
+------------------------------------------------+

[lcd4linux] Re: need help with autmake, libtool and

[Patrick S. <sch...@ek...>]

Hello all,

On Tue, Sep 30, 2003 at 07:45:40PM +0200, Michael Reinelt wrote:
> >What versions of the autotools were you using?
> 
> merlin:~ $ autoconf --version
> autoconf (GNU Autoconf) 2.57
> 
> merlin:~ $ automake --version
> automake (GNU automake) 1.4-p6
> 
> merlin:~ $ libtool --version
> ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.25 2003/08/01 19:08:35) Debian: 
> 49 $
> 
> merlin:~ $ libtoolize --version
> libtoolize (GNU libtool) 1.5.0a

For me, that's:

$ autoconf --version
autoconf (GNU Autoconf) 2.57
$ automake --version
automake (GNU automake) 1.6.3
$ libtool --version
ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.27 2003/08/29 14:21:22)
$ libtoolize --version
libtoolize (GNU libtool) 1.5.0a

> Martin, Patrick, could you please report your versions, too? And could 
> you please try to re-enable the currently commented lines in Makefile.am 
> and configure.in:
> 
> Makefile.am:
> # deactivateing shared lib target for the moment until
> # libtool works cleanly...
> #lib_LTLIBRARIES = liblcd4linux.la
> [...]
> # deactivated
> # liblcd4linux_la_LDFLAGS = -version-info 9:11:9
> 
> # liblcd4linux_la_SOURCES = \
> [...]

I also had to remove @DRIVERS@ from liblcd4linux_la_SOURCES, automake
complained:

   Makefile.am:75: `liblcd4linux_la_SOURCES' includes configure
   substitution `@DRIVERS@', and is referred to from
   `liblcd4linux_la_SOURCES': configure substitutions not allowed in
   _SOURCES variables

Plus I had to remove a lot of objects from the lcd4linux_SOURCES
target since automake complained:

   automake: Makefile.am: object `debug.$(OBJEXT)' created both with
   libtool and without

(Also for cfg, lock, udelay, display, pixmap, bar, icon, fontmap, and
parport.)

> configure.in:
> # Using `AC_PROG_RANLIB' is rendered
> # obsolete by `AC_PROG_LIBTOOL' :-(
> AC_PROG_RANLIB
> # Deactivating libtool for the moment until
> # we find a way this beast works cleanly...
> #AC_PROG_LIBTOOL
> #AM_PROG_LIBTOOL
> 
> and the report any problems?

Configure seems to work:

   $ ./configure --prefix=/tmp/schemitz/trash --with-drivers=X11
   [...]
   configure: creating ./config.status
   config.status: creating Makefile
   config.status: creating config.h
   config.status: executing depfiles commands
   $

But make fails with a curious problem. Each object seems to compile:

   source='display.c' object='display.lo' libtool=yes \
   depfile='.deps/display.Plo' tmpdepfile='.deps/display.TPlo' \
   depmode=none /bin/sh ./depcomp \
   /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.
   -I/usr/X11R6/include -D_GNU_SOURCE -Wall -g -O2 -c -o display.lo `test
   -f 'display.c' || echo './'`display.c

(and the same for all the other objects), but the linker complains:

   (cd . && ln -s display.lo display.o)
[ plus the same for all the shared objects ]
   gcc -shared  display.lo debug.lo cfg.lo lock.lo pixmap.lo bar.lo icon.lo
   fontmap.lo parport.lo udelay.lo  -lm  -Wl,-soname -Wl,liblcd4linux.0 -o
   .libs/liblcd4linux.0.9.11
   gcc: display.lo: No such file or directory
   gcc: debug.lo: No such file or directory
   gcc: cfg.lo: No such file or directory
   gcc: lock.lo: No such file or directory
   gcc: pixmap.lo: No such file or directory
   gcc: bar.lo: No such file or directory
   gcc: icon.lo: No such file or directory
   gcc: fontmap.lo: No such file or directory
   gcc: parport.lo: No such file or directory
   gcc: udelay.lo: No such file or directory

And the linker is right! The object files do not exist. Apparently,
libtool didn't really invoke the compiler at all! Proof: mv away
the gcc executable and run "make" again: no error on compile, no
warning.

More trouble: on the second invokation, "make" complains (again,
correctly) about already existing symlinks:

   (cd . && ln -s display.lo display.o)
   ln: `display.o': File exists

Hope this helps. I surely do need help here.

Ciao, patrick
-- 
Patrick Schemitz <http://www-ekp.physik.uni-karlsruhe.de/~schemitz>

[lcd4linux] Re: need help with autmake, libtool and

[Michael R. <re...@eu...>]

Hi Ronald,

I'm CCing this to the lcd4linux mailing list, to Martin Hejl (he has 
encountered some problems while cross-compiling for uClibc) and to 
Patrick Schemitz (he and me tried to build a shared library)


>>I'm resending this mail because I didn't get any any response. i hope 
>>you didn't loose interest... anyway, a response would be helpful! Thanks 
>>in advance!
> 
> Either I didn't get it, or it got drowned in my spam filter..

Oh... or probably mine... you never can tell with spam filters :-)

>>>What exactly is the problem? Perhaps I can help..
>>
>>lcd4linux is a quite small and straightforward project, its main purpose
>>is to collect some data and display it on an LCD. It's just a simple
>>(single) application, no libraries are built.
>>
>>Now a guy wants to extract the hardware- and display-specific stuff into
>>a (shared) library, and create python bindings for it.
>>
>>lcd4linux uses autoconf and automake, which worked fine without
>>libraries. Now I tried to integrate a library target into automake. The
>>first try was a static library, which was quite easy, but for python
>>bindings you need a shared library.
>>
>>I tried to figure out how shared library targets are handled by
>>automake, and found this libtool stuff. My first try succeded, but other
>>people were having massive problems from this point on (I had to remove
>>the target again).
>>
>>one of the problems have been:
>>
>>/bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.
>>-I/usr/X11R6/include -D_GNU_SOURCE -Wall -g -O2 -c display.c
>>./libtool: line 1: s%^.*/%%: No such file or directory
>>./libtool: line 1: -e: command not found

Martin, this was the error you encountered, right?

>>other people had problems with cross-compiling for uClibc...
>>
>>Maybe I did the whole autoconf/automake stuff wrong (I've no experience
>>with it).
> 
> Possibly, but I'd have to see what you did with your Makefile.am files, your
> configure.{ac|in} file and what the errors were.

As you wrote later, the files look ok to you, you did already get the 
package or the CVS version?

>>If I want to provide a source package, has libtool to be installed at
>>the client? autoconf/automake is not necessary, if you provide the final
>>'configure' script...
> 
> No: libtoolize generates a libtool script for your package, which you should
> send along. If you make your package using `make dist', it will be packaged
> for you.

Yes, that's what I would expect.

> Your Makefile.am file looks OK (if you re-enable Libtool).
> Your configure.in file needs only one of AC_PROG_LIBTOOL and AM_PROG_LIBTOOL -
> i.e. the AC_* version.

It always worked for me. But I have all the automake/autoconf/libtool 
toolchain installed.

> What versions of the autotools were you using?

merlin:~ $ autoconf --version
autoconf (GNU Autoconf) 2.57

merlin:~ $ automake --version
automake (GNU automake) 1.4-p6

merlin:~ $ libtool --version
ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.25 2003/08/01 19:08:35) Debian: 
49 $

merlin:~ $ libtoolize --version
libtoolize (GNU libtool) 1.5.0a


> What were the problems you 
> encountered?

Martin, Patrick, could you please report your versions, too? And could 
you please try to re-enable the currently commented lines in Makefile.am 
and configure.in:

Makefile.am:
# deactivateing shared lib target for the moment until
# libtool works cleanly...
#lib_LTLIBRARIES = liblcd4linux.la
[...]
# deactivated
# liblcd4linux_la_LDFLAGS = -version-info 9:11:9

# liblcd4linux_la_SOURCES = \
[...]

configure.in:
# Using `AC_PROG_RANLIB' is rendered
# obsolete by `AC_PROG_LIBTOOL' :-(
AC_PROG_RANLIB
# Deactivating libtool for the moment until
# we find a way this beast works cleanly...
#AC_PROG_LIBTOOL
#AM_PROG_LIBTOOL

and the report any problems?

Lets discuss this stuff on the mailing list!

Thanks in advance to all of you! I really want to get this stuff usable. 
Another guy asked for perl bindings for lcd4linux today...

bye, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

[lcd4linux] Re: LCD Prog

[Michael R. <re...@eu...>]

Hi Thomas,

to answer your last question: yes, the list is the correct place for 
such questions, because it may be interesting to other people, too. So 
I'm CCing this to the list....

Thomas Heinrich wrote:
> Hi my name is Thomas and I'm a German.
> I don't know if you are the right one for my question, but I will try.

I am :-)

> I've read read your project and I find it great.
Thanks!

> I've got an LCD Display and his product specifications. It is named
>  "PVG240602AYN". Number of dots are 240 x 64
> 
> There are three chips on it called Toshiba T6A39
> 1 x T6A40
> 1 x T6963C
> and 1 x Winbond W2465S-70LL.

I'm quite shure it's a T6963 compatible display. lcd4linux should 
support it. Take a look at the homepage, section "Displays" and "T6963", 
here you will find a wiring diagram.

> My problem is, I don't know how to get connected it, or running with
> your software. Is there any possibility to run this LCD with your
> software?

see above, it should work. The negative contrast voltage is very 
important, otherwise you won't see anything on the display.

> If you wan't I can make a pictue of the LCD and send a photo to you.
> Or is it better to post this  mesage in the mailing list?

How many pins does it have? Mine has 20 pins, the last two are not used.

You can of course send a photo...

bye, Michael.


-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] USB with HD44780

[Michael R. <re...@eu...>]

Hi Gabriel,

> I was reading some posts about people who are trying to use
> lcd4linux with USB port output and HD44780 displays. But I
> could=B4nt find concrete answers. (and I don=B4t want to re-invent
> the wheel).   I find phillips and FTDI chips, read all
> manuals, but I live at the other side of the world and
> components are ridiculously expensive to try with all of
> them.

There are some ready-made displays for the USB port:

- Matrixorbital (http://www.matrixorbital.com)
- CwLinux (http/::www.cwlinux.com)
- CrystalFontz (http://www.crystalfontz.com)

They use different displays, I know that CwLinux use sed150 compatible=20
graphics displays, MatrixOrbital and Crystalfonts ma be HD44780=20
compatible, but I'm not shure...

There is one other product, called "USBLCD" by Robin Adams. It's a=20
ready-to-use USB-to-HD44780 interface, very small, USB-Powered, and=20
works with every HD44780-compatible display (at least it worked with all=20
of my displays, ant that's a lot of :-)

You may find infos on this at http://www.usblcd.de


If you try to design your own interface or controller, I'd like to=20
support it from lcd4linux, of course!

bye, Michael


--=20
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

[lcd4linux] USB with HD44780

[Jorge G. L. <glo...@xi...>]

Dear lcd4linux-users,

          I was reading some posts about people who are trying to use
          lcd4linux with USB port output and HD44780 displays. But I
          couldŽnt find concrete answers. (and I donŽt want to re-invent
          the wheel).   I find phillips and FTDI chips, read all
          manuals, but I live at the other side of the world and
          components are ridiculously expensive to try with all of
          them.

Regards, Gabriel

Re: [lcd4linux] M50530 now working - and more ...

[Michael R. <re...@eu...>]

Stefan Krister wrote:

> good news for my M50530 display! My "soldering-iron-guy" mailed me, that
> it's working great with a uclibc compiled lcd4linux 0.9.10 - he putted
> it onto a beta fli4l [1] 2.1.4.

Fine! Thanks a lot for the success report!

> He asked me, if I want a special "magic" pcb wich is able to support the
> displays needed voltages out of the ps/2 keyboard-port.
> 
> He will solder it alltogether and send me the "pnp" display back. I'll try
> to get the scematics too and send it to you, if you want.

Yes, I'd be very interested in stuff like this. I'd publish it on the 
lcd4linxu web page.

> Are you able to visit the linuxday at nov. 15th in Dornbirn [2]? The
> eisfair [3] and fli4l team will be there, showing easy made routers and
> servers - most of them equipped with lcds.

Maybe - lets talk about this per PM.

In every case, I want lcd4linxu to be used on both eisfar and fli4l ;-)


bye, Michael

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...

[lcd4linux] lcd4linux-0.9.11 released!

[Michael R. <re...@eu...>]

Hi list,

I just decided to release 0.9.11, because I only got positive feedback 
to the beta 0.9.11-pre1 release.

What's new in 0.9.11:

- Icons! Hearbeat! Animations!
- HD44780 4-bit-mode (thanks to Martin Hejl)
- double-buffering with all drivers (should improve performance and 
lower CPU usage a lot!)
- improved HD44780 timings


What next:

- another attempt to solve the shared library and libtool issues
- internal redesign, switch from "rows" to "widgets", which will allow 
much more flexible tokens

- and, most important, improved MatrixOrbital Drivers! I received a 
parcel from them yesterday, containing a MX211 and a LK204-24-USB. These 
displays (with a lot of additional gimmicks) have been donated by Henry 
Jakl from MatrixOrbital. Thanks!


So, stay tuned and have fun!

-- 
netWorks                                          Vox: +43 316  698260
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4                                   GSM: +43 676 3079941
A-8045 Graz, Austria                          e-mail: re...@eu...