lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] Memory usage grows when using images

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

Hi Magne,

> When there are image widgets enabled in the layout, the memory usage of
> lcd4linux grows steadily until there is nothing left and the process is
> killed. Consumption grows faster when image update times are low. Could
> it be that memory is not freed after rereading the image file?

uh-oh :-)

Thnaks for pointing this out, should be fixed in CVS (a gdImageDestroy()
was missing)

> Additionally, setting the update delay to 0 does not make the image
> static, but makes updates go as fast as possible.
Fixed in CVS, too. Thanks again!

Please test and give some feedback!


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Memory usage grows when using images

[Magne <tor...@st...>]

Hi,
When there are image widgets enabled in the layout, the memory usage of
lcd4linux grows steadily until there is nothing left and the process is
killed. Consumption grows faster when image update times are low. Could
it be that memory is not freed after rereading the image file?
Additionally, setting the update delay to 0 does not make the image
static, but makes updates go as fast as possible.

I'm using the current cvs-version and a T6963 240x128 display.

Thanks in advance

Magne T=F8rresen

Re: [Lcd4linux-devel] FW: Compile error

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

Hi There,

> I can confirm the problem discussed in this thread. With Mandriva 2006.0
> I get the same compiler error when using the sources from tarball. If I
> use CVS sources, everything compiles just fine.

Got it: there was a change back in July 2005, which should solve the
problem:

Change this line:

extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
int num);

to:

extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,
int num);


the only difference is msg[] => *msg

which explains the compiler warning for incomplete array stuff....



HTH, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] FW: Compile error

[Luis.F.Correia <Lui...@se...>]

fwd to the list

  _____  

From: Udo Neumann [mailto:bet...@qu...] 
Sent: Friday, September 22, 2006 7:21 PM
To: Luis.F.Correia
Subject: Re: [Lcd4linux-devel] Compile error


Luis,

I can confirm the problem discussed in this thread. With Mandriva 2006.0 I
get the same compiler error when using the sources from tarball. If I use
CVS sources, everything compiles just fine.

This is just for your information.

Regards,
Udo

Luis.F.Correia schrieb: 

 

Hi again,





  

-----Original Message-----

From: dusted [mailto:du...@du... <mailto:du...@du...> ] 

Sent: Tuesday, September 12, 2006 6:09 PM

To: lcd...@li...
<mailto:lcd...@li...> 

Subject: [Lcd4linux-devel] Compile error



Hi, i dont know if this is relevant, but i downloaded the 

source off the site.

    



>From where exactly, the lcd4linux-0.10.0 tarball or CVS code?



  

$ ./configure

$ make

ends in error:



In file included from drv_generic_i2c.c:76:

lcd4linux_i2c.h:81: error: array type has incomplete element type

make: *** [drv_generic_i2c.o] Error 1

    



As of yesterday around 19:00 WEST, the CVS code was working correctly.





Luis Correia   

Bering uClibc Team Member



  

Re: [Lcd4linux-devel] Compile error

[Luis.F.Correia <Lui...@se...>]

Hi Michael,

> -----Original Message-----
> From: Michael Reinelt [mailto:re...@eu...] 
> Sent: Sunday, September 24, 2006 12:27 PM
> To: Luis.F.Correia
> Cc: lcd...@li...; 'dusted'
> Subject: Re: [Lcd4linux-devel] Compile error
> 
> Hi there,
> 
> >> In file included from drv_generic_i2c.c:76:
> >> lcd4linux_i2c.h:81: error: array type has incomplete element type
> >> make: *** [drv_generic_i2c.o] Error 1
> > 
> > As of yesterday around 19:00 WEST, the CVS code was working 
> correctly.
> 
> I suppose the error comes from the fact that the 
> "lcd4linux_i2c.h" file is a "copy" of some kernel header 
> file, which is ugly, but we didn't find a way to include the 
> original kernel headers into a userland program like lcd4linux.

Yes, but according to another email i received in my inbox,
this only happens in the released 0.10.0 version, CVS code is
fine.

My suggestion is for us to make an interim release, just fixing whatever
is lacking, like fixing compiler errors.


> 
> Maybe the lcd4linux_i2c.h makes some assumptions on working 
> kernel headers which may fail under some circumstances...
> 
> on the other hand, line 81 in my lcd4linux_i2c.h is the end 
> of a comment block ( a '*/'), which should not raise any 
> compiler error....
> 
> 
> bye, michael

Luis Correia

Re: [Lcd4linux-devel] Compile error

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

Hi there,

>> In file included from drv_generic_i2c.c:76:
>> lcd4linux_i2c.h:81: error: array type has incomplete element type
>> make: *** [drv_generic_i2c.o] Error 1
> 
> As of yesterday around 19:00 WEST, the CVS code was working correctly.

I suppose the error comes from the fact that the "lcd4linux_i2c.h" file
is a "copy" of some kernel header file, which is ugly, but we didn't
find a way to include the original kernel headers into a userland
program like lcd4linux.

Maybe the lcd4linux_i2c.h makes some assumptions on working kernel
headers which may fail under some circumstances...

on the other hand, line 81 in my lcd4linux_i2c.h is the end of a comment
block ( a '*/'), which should not raise any compiler error....


bye, michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] Compile error

[Luis.F.Correia <Lui...@se...>]

 
Hi again,


> -----Original Message-----
> From: dusted [mailto:du...@du...] 
> Sent: Tuesday, September 12, 2006 6:09 PM
> To: lcd...@li...
> Subject: [Lcd4linux-devel] Compile error
> 
> Hi, i dont know if this is relevant, but i downloaded the 
> source off the site.

>From where exactly, the lcd4linux-0.10.0 tarball or CVS code?

> $ ./configure
> $ make
> ends in error:
> 
> In file included from drv_generic_i2c.c:76:
> lcd4linux_i2c.h:81: error: array type has incomplete element type
> make: *** [drv_generic_i2c.o] Error 1

As of yesterday around 19:00 WEST, the CVS code was working correctly.


Luis Correia   
Bering uClibc Team Member

PGP Fingerprint: BC44 D7DA 5A17 F92A CA21 9ABE DFF0 3540 2322 21F6 
Key Server: http://pgp.mit.edu

Re: [Lcd4linux-devel] Compile error

[Luis C. <lfc...@lf...>]

Martin Hejl wrote:
> Hi Luis,
> 
>>>> In file included from drv_generic_i2c.c:76:
>>>> lcd4linux_i2c.h:81: error: array type has incomplete element type
>>>> make: *** [drv_generic_i2c.o] Error 1
>>> This is a known bug. I'm still waiting for the I2C guys to fix this.....
>>>
>>>
>>> bye, Michael
>>>
>>   Hi all,
>>
>>   i've just grabbed the latest CVS code into my CentOS 4.4 devel box, and
>>   after the usual ./bootstrap, ./configure and make, all went according to
>>   plan, making a working lcd4linux executable.
>>
>>   Soooo, i can't imagine how it would be failing in other systems.
> Oh, come on - it doesn't take that great a leap of imagination. Take 
> something that isn't a rip off of an enterprise distro (read, take 
> something that's actually bleeding edge, rather than something that's a 
> copy of a system that puts a lot of effort into making sure that things 
> "just work" for their paying customers) and I'm sure it's not too hard 
> to make things break. Be that the latest Ubuntu, Fedora Core (preferably 
> some sort of testing branch) or whatever. If course, without knowing 
> what exact distro/kernel was being used, it's hard to reproduce.
> 
> Don't get me wrong (I use RHEL myself) - but to me, things working on 
> Centos (or WBEL, RHEL, SLES or whatever other Enterprise Distro one can 
> think of) surely doesn't seem to be some sort of guarantee that it 
> should work for everybody else too.

Well, let me put this this way :) RedHat with those Fedoras and all the 
bleeding egde stuff is known to be the Windows of Linux world.

My simple assumption is if it works in this 'crap' it will work almost 
everywhere...

So, dusted, can you provide with more details on your system that is 
currently failing to compile lcd4linux?

> 
> Martin



Luis

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Lcd4linux-devel] Compile error

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

Hi Luis,

>>> In file included from drv_generic_i2c.c:76:
>>> lcd4linux_i2c.h:81: error: array type has incomplete element type
>>> make: *** [drv_generic_i2c.o] Error 1
>> This is a known bug. I'm still waiting for the I2C guys to fix this.....
>>
>>
>> bye, Michael
>>
> 
>   Hi all,
> 
>   i've just grabbed the latest CVS code into my CentOS 4.4 devel box, and
>   after the usual ./bootstrap, ./configure and make, all went according to
>   plan, making a working lcd4linux executable.
> 
>   Soooo, i can't imagine how it would be failing in other systems.
Oh, come on - it doesn't take that great a leap of imagination. Take 
something that isn't a rip off of an enterprise distro (read, take 
something that's actually bleeding edge, rather than something that's a 
copy of a system that puts a lot of effort into making sure that things 
"just work" for their paying customers) and I'm sure it's not too hard 
to make things break. Be that the latest Ubuntu, Fedora Core (preferably 
some sort of testing branch) or whatever. If course, without knowing 
what exact distro/kernel was being used, it's hard to reproduce.

Don't get me wrong (I use RHEL myself) - but to me, things working on 
Centos (or WBEL, RHEL, SLES or whatever other Enterprise Distro one can 
think of) surely doesn't seem to be some sort of guarantee that it 
should work for everybody else too.

Martin

Re: [Lcd4linux-devel] Compile error

[Luis C. <lfc...@lf...>]

Michael Reinelt wrote:
> Hi there,
>
>> In file included from drv_generic_i2c.c:76:
>> lcd4linux_i2c.h:81: error: array type has incomplete element type
>> make: *** [drv_generic_i2c.o] Error 1
>
> This is a known bug. I'm still waiting for the I2C guys to fix this.....
>
>
> bye, Michael
>

  Hi all,

  i've just grabbed the latest CVS code into my CentOS 4.4 devel box, and
  after the usual ./bootstrap, ./configure and make, all went according to
  plan, making a working lcd4linux executable.

  Soooo, i can't imagine how it would be failing in other systems.

  Luis Correia


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Lcd4linux-devel] iconv charset converter plugin

[Reinhard T. <sir...@ta...>]

Ernst Bachmann <e.b...@xe...> writes:


> I just commited a charset converter plugin, usefull e.g. when reading utf8 
> data to display on a iso8859-1 display etc.
>
> I only committed files I directly changed, not those generated by 
> autoconf/make, since my versions seem to generate something quite different 
> here.
>
> Maybe one of you with the "correct" versions installed could bootstrap and 
> then commit "Makefile.in", "aclocal.m4" and "configure".

I rerun bootstrap and committed these files: Makefile.in aclocal.m4
configure

I didn't review your changes, but I was able to compile lcd4linux

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Lcd4linux-devel] iconv charset converter plugin

[Ernst B. <e.b...@xe...>]

Hi,

I just commited a charset converter plugin, usefull e.g. when reading utf8=
=20
data to display on a iso8859-1 display etc.

the function is called with=20
iconv(<from charset>, <to charset>, <text to convert>);

like:
 iconv('latin1','utf8',iconv('utf8','latin1','=E4=F6=FC'))

It simply wraps the iconv function from glibc, so a list of supported chars=
ets=20
can be seen by running "iconv --list"


I only committed files I directly changed, not those generated by=20
autoconf/make, since my versions seem to generate something quite different=
=20
here.

Maybe one of you with the "correct" versions installed could bootstrap and=
=20
then commit "Makefile.in", "aclocal.m4" and "configure".

Bye,
/Ernst

Re: [Lcd4linux-devel] patch for "named threads"

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

Hi Ernst,

>> Did I miss something?
> 
> Well, usually that would be correct, but in this case, I'm overwriting an 
> already NUL-terminated string with new data. strlen will return the length 
> excluding the NUL char at the end of the original string, so, even in worst 
> case, that NUL will stay where it is unmodified.
Ah, right - I obviously missed the essential part. Thanks for clarifying 
what should have been obvious (I missed the part that the destination 
buffer is strlen(thread_argv[0])+1 bytes long, and is already \0 terminated)

Martin

Re: [Lcd4linux-devel] patch for "named threads"

[Ernst B. <e.b...@xe...>]

On Wednesday 13 September 2006 21:18, Martin Hejl wrote:

> >>>> +  	    strncpy(thread_argv[0],name,strlen(thread_argv[0]));
> >>
> >> Thats why I used "strNcpy" with the original argv[0] length as limit.
> >> It won't overwrite data it shouldn't, but will truncate the threads name
> >> if its longer than the original binary name.
> >
> > silly me... I always mix up src and dst with strcpy :-)
>
> I didn't look at the context - but the thing that always bothered me
> with (and kept me from using strncpy) is that if src is longer than
> dest, the result is that dest is not terminated by \0 - unless I read
> the manpage incorrectly:
>
> char *strncpy(char *restrict s1, const char *restrict s2, size_t n);
> The  strncpy()  function  shall copy not more than n bytes (bytes that
>         follow a null byte are not copied) from the array pointed to by
>
>         s2  to the  array  pointed  to by s1.
> (...)
>   If there is no null byte in the first n bytes of the array pointed  to
>         by s2, the result is not null-terminated
>
> Did I miss something?

Well, usually that would be correct, but in this case, I'm overwriting an 
already NUL-terminated string with new data. strlen will return the length 
excluding the NUL char at the end of the original string, so, even in worst 
case, that NUL will stay where it is unmodified.

/Ernst

Re: [Lcd4linux-devel] patch for "named threads"

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

Hi everybody,

Michael Reinelt wrote:
>>> Did you already commit? Did I give you CVS write access?
>> Nope, doesn't seem like I have CVS write access. (I'm also not listed on the 
>> SF.net developer list for lcd4linux)
> Oh.. did you ever tell me your SF account name? I'll add you to the
> devel group.
> 
>>>> +  	    strncpy(thread_argv[0],name,strlen(thread_argv[0]));
> 
>> Thats why I used "strNcpy" with the original argv[0] length as limit.
>> It won't overwrite data it shouldn't, but will truncate the threads name if 
>> its longer than the original binary name.
> 
> silly me... I always mix up src and dst with strcpy :-)
I didn't look at the context - but the thing that always bothered me 
with (and kept me from using strncpy) is that if src is longer than 
dest, the result is that dest is not terminated by \0 - unless I read 
the manpage incorrectly:

char *strncpy(char *restrict s1, const char *restrict s2, size_t n);
The  strncpy()  function  shall copy not more than n bytes (bytes that
        follow a null byte are not copied) from the array pointed to by 

        s2  to the  array  pointed  to by s1.
(...)
  If there is no null byte in the first n bytes of the array pointed  to
        by s2, the result is not null-terminated

Did I miss something?

Martin

Re: [Lcd4linux-devel] patch for "named threads"

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

>> Did you already commit? Did I give you CVS write access?
> 
> Nope, doesn't seem like I have CVS write access. (I'm also not listed on the 
> SF.net developer list for lcd4linux)
Oh.. did you ever tell me your SF account name? I'll add you to the
devel group.

>>> +  	    strncpy(thread_argv[0],name,strlen(thread_argv[0]));

> Thats why I used "strNcpy" with the original argv[0] length as limit.
> It won't overwrite data it shouldn't, but will truncate the threads name if 
> its longer than the original binary name.

silly me... I always mix up src and dst with strcpy :-)


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] patch for "named threads"

[Ernst B. <e.b...@xe...>]

On Wednesday 13 September 2006 17:04, Michael Reinelt wrote:
> Hi Ernst,
>
> > Here a little patch that changes the argv[0] of threads started with
> > lcd4linux's thread.c to the thread name.
>
> Fine, good idea!
>
> Did you already commit? Did I give you CVS write access?

Nope, doesn't seem like I have CVS write access. (I'm also not listed on the 
SF.net developer list for lcd4linux)

> > a few more patches to the thread functions will follow shortly, I'm
> > implementing some stuff for my "VFD4Linux" driver and will send patches
> > for the generic parts I need during the progress.
>
> Patches are always welcome!
>
> >  	info("thread %s starting...", name);
> > +	if (thread_argc > 0) {
> > +  	    strncpy(thread_argv[0],name,strlen(thread_argv[0]));
> > +        }
>
> just curious: isn't there a problem if the new (thread) name is longer
> than the "original" name, so your strncpy would overwrite things that
> are better not overwritten? I thing I read something like this sometime
> somewhere.....

Thats why I used "strNcpy" with the original argv[0] length as limit.
It won't overwrite data it shouldn't, but will truncate the threads name if 
its longer than the original binary name.

To get longer names, one would have to do lots strange stuff, like 
reorganizing the layout of the entire argv array and possible the environment 
variables...  too much work for a little cosmetic trick.

Simply malloc'ing a new string and linking it into argv[0] unfortunately 
doesn't work.

>
> bye, Michael

Greetings,
/Ernst

Re: [Lcd4linux-devel] patch for "named threads"

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

Hi Ernst,

> Here a little patch that changes the argv[0] of threads started with 
> lcd4linux's thread.c to the thread name.

Fine, good idea!

Did you already commit? Did I give you CVS write access?

> a few more patches to the thread functions will follow shortly, I'm 
> implementing some stuff for my "VFD4Linux" driver and will send patches for 
> the generic parts I need during the progress.

Patches are always welcome!


>  	info("thread %s starting...", name);
> +	if (thread_argc > 0) {
> +  	    strncpy(thread_argv[0],name,strlen(thread_argv[0]));
> +        }

just curious: isn't there a problem if the new (thread) name is longer
than the "original" name, so your strncpy would overwrite things that
are better not overwritten? I thing I read something like this sometime
somewhere.....


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] patch for "named threads"

[Ernst B. <e.b...@xe...>]

Hi, 

Here a little patch that changes the argv[0] of threads started with 
lcd4linux's thread.c to the thread name.

The new name will then show up on "ps" et al.

a few more patches to the thread functions will follow shortly, I'm 
implementing some stuff for my "VFD4Linux" driver and will send patches for 
the generic parts I need during the progress.


/Ernst

Re: [Lcd4linux-devel] Compile error

[Luis C. <lfc...@lf...>]

> Hi there,
>
>> In file included from drv_generic_i2c.c:76:
>> lcd4linux_i2c.h:81: error: array type has incomplete element type
>> make: *** [drv_generic_i2c.o] Error 1
>
> This is a known bug. I'm still waiting for the I2C guys to fix this.....
>

Hi there, i'm currently on vacations for a week with no access to my devel
system.

But AFAIK, there was nothing changed recently that would explain that
problem...

>
> bye, Michael
>

Luis Correia

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Lcd4linux-devel] Compile error

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

Hi there,

> In file included from drv_generic_i2c.c:76:
> lcd4linux_i2c.h:81: error: array type has incomplete element type
> make: *** [drv_generic_i2c.o] Error 1

This is a known bug. I'm still waiting for the I2C guys to fix this.....


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Compile error

[dusted <du...@du...>]

Hi, i dont know if this is relevant, but i downloaded the source off the=20
site.
$ ./configure
$ make
ends in error:

In file included from drv_generic_i2c.c:76:
lcd4linux_i2c.h:81: error: array type has incomplete element type
make: *** [drv_generic_i2c.o] Error 1

I just commented out the line, and it compiles (but i figure i2c stuff=20
wont work).

Best Regards
Jimmy Christensen

Just in case you want the output its here:
make gives:
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c lcd4linu=
x.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c cfg.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c debug.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c drv.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c evaluato=
r.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c hash.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c layout.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c pid.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c timer.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c thread.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c udelay.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c qprintf.=
c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c widget.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
widget_text.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
widget_bar.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
widget_icon.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c plugin.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
plugin_cfg.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
plugin_math.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
plugin_string.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
plugin_test.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
plugin_time.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_BeckmannEgle.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_Crystalfontz.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_Curses.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_Cwlinux.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_HD44780.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_LCDLinux.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_LCDTerm.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_M50530.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_MatrixOrbital.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_MilfordInstruments.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_Noritake.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c drv_NULL=
.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c drv_Imag=
e.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_RouterBoard.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_SimpleLCD.c
drv_SimpleLCD.c: In function =91drv_SL_start=92:
drv_SimpleLCD.c:212: warning: pointer targets in passing argument 6 of=20
=91cfg_number=92 differ in signedness
drv_SimpleLCD.c:214: warning: pointer targets in passing argument 6 of=20
=91cfg_number=92 differ in signedness
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c drv_T696=
3.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_USBLCD.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_generic_text.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_generic_graphic.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_generic_parport.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_generic_serial.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -Wall -W -g -O2 -c=20
drv_generic_i2c.c
In file included from drv_generic_i2c.c:76:
lcd4linux_i2c.h:81: error: array type has incomplete element type
make: *** [drv_generic_i2c.o] Error 1


and ./configure gives:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal-1.4... found
checking for working autoconf... found
checking for working automake-1.4... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking if malloc debugging is wanted... no
checking for log in -lm... yes
checking for egrep... grep -E
configure: checking location of ncurses.h file...
Found ncurses on /usr/include/ncurses.h
checking for ncurses version... 5.5
checking for X... no
checking gd/gd.h usability... no
checking gd/gd.h presence... no
checking for gd/gd.h... no
checking gd.h usability... no
checking gd.h presence... no
checking for gd.h... no
checking usb.h usability... no
checking usb.h presence... no
checking for usb.h... no
checking serdisplib/serdisp.h usability... no
checking serdisplib/serdisp.h presence... no
checking for serdisplib/serdisp.h... no
checking if python support is wanted... no
checking which drivers to compile... done
configure: WARNING: usb.h not found: BWCT driver disabled
configure: WARNING: gd.h not found: PNG driver disabled
configure: WARNING: serdisp.h not found: serdisplib driver disabled
configure: WARNING: usb.h not found: Trefon driver disabled
configure: WARNING: X11 headers or libraries not available: X11 driver=20
disabled
checking which plugins to compile... done
checking linux/dvb/frontend.h usability... yes
checking linux/dvb/frontend.h presence... yes
checking for linux/dvb/frontend.h... yes
checking linux/isdn.h usability... yes
checking linux/isdn.h presence... yes
checking for linux/isdn.h... yes
checking mysql/mysql.h usability... no
checking mysql/mysql.h presence... no
checking for mysql/mysql.h... no
configure: WARNING: mysql/mysql.h header not found: mysql plugin disabled
checking net/if_ppp.h usability... yes
checking net/if_ppp.h presence... yes
checking for net/if_ppp.h... yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for ANSI C header files... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking stdlib.h usability... yes
checking stdlib.h presence... yes
checking for stdlib.h... yes
checking string.h usability... yes
checking string.h presence... yes
checking for string.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/statfs.h usability... yes
checking sys/statfs.h presence... yes
checking for sys/statfs.h... yes
checking sys/vfs.h usability... yes
checking sys/vfs.h presence... yes
checking for sys/vfs.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking unistd.h usability... yes
checking unistd.h presence... yes
checking for unistd.h... yes
checking sys/io.h usability... yes
checking sys/io.h presence... yes
checking for sys/io.h... yes
checking asm/io.h usability... yes
checking asm/io.h presence... yes
checking for asm/io.h... yes
checking linux/parport.h usability... yes
checking linux/parport.h presence... yes
checking for linux/parport.h... yes
checking linux/ppdev.h usability... yes
checking linux/ppdev.h presence... yes
checking for linux/ppdev.h... yes
checking asm/msr.h usability... yes
checking asm/msr.h presence... yes
checking for asm/msr.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for uid_t in sys/types.h... yes
checking whether closedir returns void... no
checking for error_at_line... yes
checking for unistd.h... (cached) yes
checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
checking whether gcc needs -traditional... no
checking return type of signal handlers... void
checking whether lstat dereferences a symlink specified with a trailing=20
slash... no
checking whether stat accepts an empty string... no
checking for strftime... yes
checking for working strtod... yes
checking for dup2... yes
checking for floor... yes
checking for gethostbyname... yes
checking for gettimeofday... yes
checking for memset... yes
checking for pow... yes
checking for putenv... yes
checking for regcomp... yes
checking for socket... yes
checking for sqrt... yes
checking for strcasecmp... yes
checking for strchr... yes
checking for strdup... yes
checking for strerror... yes
checking for strncasecmp... yes
checking for strndup... yes
checking for strpbrk... yes
checking for strrchr... yes
checking for strstr... yes
checking for strtol... yes
checking for uname... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing default-1 commands

[Lcd4linux-devel] Complile error in Kubuntu 5.1 / make not possible

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

Someone opened this ticket in the wiki:

"gcc -DHAVE_CONFIG_H -I. -I. -I.    -D_GNU_SOURCE -Wall -W -g -O2 -c
drv_generic_i2c.c
In file included from drv_generic_i2c.c:76:
lcd4linux_i2c.h:81: error: array type has incomplete element type
make: *** [drv_generic_i2c.o] Error 1"


Could someone from you i2c guys have a look at this?


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] KVV Plugin

[Ernst B. <e.b...@xe...>]

On Monday 11 September 2006 12:32, Ernst Bachmann wrote:
> It seems like the KVV Plugin is compiled by default and always starts its
> polling thread, even if most of the users don't need it.
>
> Wouldn't it make sense to have the plugin only start its polling thread if
> it is actually configured and in use?
>
> Maybe set the default for "StationID" to -1, and only fork if its
> configured to something different?

Upsie, posted to quick.

Seems like the plugin only forks on the first invocation of one of the plugin 
functions, it just always outputs its log messages.

[KVV] Using station 89
[KVV] Using default port 80
[KVV] Using default refresh interval of 60 seconds
[KVV] Default abbreviation setting: off

So, ignore my post,
/Ernst

[Lcd4linux-devel] KVV Plugin

[Ernst B. <e.b...@xe...>]

Hi,

It seems like the KVV Plugin is compiled by default and always starts its 
polling thread, even if most of the users don't need it.

Wouldn't it make sense to have the plugin only start its polling thread if it 
is actually configured and in use?

Maybe set the default for "StationID" to -1, and only fork if its configured 
to something different?

/Ernst