lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] Question regarding evaluator and reuse of return values

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

Hi Dan,

> Ok, i got this plugin that communicates with a remote process, lets say
> eMule as an example.
> It is threaded and it returns a set of values every other minute.
> 
> How do i make use of these values in multiple widgets, i.e how to i use
> them i one text only widget e.g "Upload 6KB, Download 10KB" and two bar
> widgets at the same time without having to duplicate the "information 
> retrieval" thread?

Well, good point, I just didn't think of this until now :-)

> The only solution i can find is to let the widget that actually runs the
> thread to be "named" and that other widgets can refer its data by that
> name (or hash if you prefer) as a reference.
This would be a possible solution, especially when the python expression
returns a lot of values.

Another solution for the simpler issue "use a single value for text and
bar" would be the use of variables. This is possibel because all plugins
share a common namespace in the evaluator:

Widget Text {
   Expression my_var=python::exec('something')
}

Widget Bar {
   Expression my_var
}

Keep in mind that every widget can have its own update interval, which
won't make things easier... in the above example, if the text widget
will update every second, but the bar every 50 msec, the bar value will
change only every second, too.

Another drawback would be that if for any reason the text widget is not
displayed (because it's not visible at the moment, which may happen
sometime when scrolling is implemented), the variable will not be
updated :-(

Another solution may be a "data collection handler", which can be
implemented as a timer event (not implemented now). It will run every
second or so, and update one or more variables, which can be used in a
set of widgets.


bye, Michael

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

[Lcd4linux-devel] Question regarding evaluator and reuse of return values

[Dan F. <tem...@ya...>]

I've been pondering on this for a while now, maybe I'm daft and can't
see the obvious solution...

Ok, i got this plugin that communicates with a remote process, lets say
eMule as an example.
It is threaded and it returns a set of values every other minute.

How do i make use of these values in multiple widgets, i.e how to i use
them i one text only widget e.g "Upload 6KB, Download 10KB" and two bar
widgets at the same time without having to duplicate the "information 
retrieval" thread?

The only solution i can find is to let the widget that actually runs the
thread to be "named" and that other widgets can refer its data by that
name (or hash if you prefer) as a reference.

This is something i can easily implement since I've implemented the 
threading of python plugins in python :) 
This was much easier for me to implement and it makes the python plugin
development process much more convenient because python plugins can now
be developed, debugged and tested in pure python - threading and all.

Anyhow, this is how a config file could look like:

Widget EMULE {
    # This widget does not have to be visible
    class 'Text'
    # module = 'emule'
    # function = 'getStats'
    # hash/keyword/identifier/whatever = 'emule_hash'
    # periodicity = 1 minute (60000)
    expression  python::threaded_exec('emule', 'getStats', 'emule_hash',
60000)
    prefix 'eMule '
    width 22
    align 'M'
    update 30000
}

Widget EMULE_TXT {
    class 'Txt'
    expression  python::get_value('emule_hash', 'most_popular_upload')
    length 10
    direction 'E'
    update 30000
}

Widget EMULE_BAR {
    class 'Bar'
    expression  python::get_value('emule_hash',
'download_as_percentage')
    expression2 python::get_value('emule_hash', 'upload_as_percentage')
    length 10
    direction 'E'
    update 30000
}

i.e Widget EMULE_BAR and EMULE_TXT displays data retrieved by widget
EMULE.

Is this something you guys could live with (at least for the python
section of lcd4linux, since does not affect anything else than
plugin_python.c)? Or am i missing something?
Maybe something like this is already exists?

/dan 

Re: [Lcd4linux-devel] I2C again

[Paul K. <pau...@xs...>]

Hi Michael,

>I don't think that I'm compiling for kernel space, especially because of
>one of the errors i get:
>
>/usr/include/linux/list.h:705:2: warning: #warning "don't include kernel
>headers in userspace
>
I still think that somehow you're building for kernel space. The reason 
for this is the following items in your output:

>------------------------------------------------------------------------
>
>In file included from /usr/include/linux/sched.h:12,
>                 from /usr/include/linux/module.h:10,
>                 from /usr/include/linux/i2c.h:31,
>                 from test-i2c.c:6:
>/usr/include/linux/jiffies.h:385:41: division by zero in #if
>  
>
This module.h is only included (on my system) when __KERNEL__ is defined 
when compiling i2c.h
Which version of the kernel headers are you using? That warning message 
in list.h is on line 713 on my system.

On more thing to check is
 gcc -v -E -dM test-i2c.c > defines-test-i2c.lst
 gcc -v -E -dM test-i2c.c 2> defines-test-i2c2.lst

This list all the defines gcc uses when compiling test-i2c.c. Maybe we 
can find something there. Just send me the output for comparison.

I am going to update to the latest kernel version/headers, see what 
happens there.
Note: I am using linux-headers 2.6.8
       and kernel 2.6.10
Can any one explain why this is different :-\

Paul

[Lcd4linux-devel] LCD4Linux Coding-Style and indent

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

Hi Developers,

geronet suggested to follow a common coding-style with lcd4linux, to
make patches and diffs easier.

He suggested the use of GNU indent, with the following options:

indent -kr -pcs -l 150

Loks like this does reduce changes to the existing code to a minimum.

One problem exists: I like some minimalistic statements like
if (a==b) break;

indent would convert them to
if (a==b)
    break;

If anyone has a solution to this one, please stand up!

Any other comments?

If you all agree, I'd do a indent run over the whole source and check it
in. This would be a big one-time patch...


bye, Michael

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

Re: [Lcd4linux-devel] Re: lcd4linux Noritake GUI128X32-311 - I got it working !

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

Hi Julien,

>>I think it would be a good idea to support both methods: busy-line
>>checking and a fixed delay. We've encountered situations in the past,
>>where waiting caused lcd4linux to eat up too much CPU cycles (especially
>>on slower systems). 

> Funny ! It's precisely because of that reason I reverted to the fixed
> delay method : The busy-line checking was eating too much CPU....
> But it might come from my crappy MediaGX-based test box.
Strange, but may come from the ndelay(200) in the busy-checking loop.

You should anyway implement some fallback mechanisms (like, do not wait
forever, fall back to normal delay if a certain amount of busy-checks
failed, and so on). Take a look at the HD44780 driver, you'll find a
very sophisticated busy-checking there.


bye, Michael

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

Re: [Lcd4linux-devel] Re: Python bindings for lcd4linux?

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

Hi Dan,

> And that it needs to be executed in a thread so that it does not slow
> down the other timing events of the lcd, it is after all a remote call
> (http) to another host and that may take an undefined amount of time.
> ( i don't think python itself would make us miss a 'tack' )

okay, got you. You're right. So a threaded version of the python plugin
would make much sense.


bye, Michael

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

Re: [Lcd4linux-devel] Re: Python bindings for lcd4linux?

[Dan F. <tem...@ya...>]

On Wed, 2005-05-04 at 07:32 +0200, Michael Reinelt wrote:
> Hi Dan again,
> 
> > I'm currently trying to steal some threading code from the plugin_exec
> > to put into the plugin_python. I have this idea of creating a 
> > really slow version of the python::exec function, because then i could 
> > easily create plugins for upload and download status of eMule and
> > mldonkey (with a polling period of 5 minutes or so).
> 
> Why sould it be very slow? I think that python gets initialized only
> once, further calls to python::exec() should be quite fast?
True

> 
> If you define an update interval of 5 minutes to the widget calling
> python::exec, I see no problem here....

You are correct, i was not very clear. What i was trying to say is that
it needs a slow update interval so that it does not bug the eMule client
too much. 
 
> Or is the problem that the python script itself may take some time? Then
> it would be a good idea to call it in a seperate thread...
> 

And that it needs to be executed in a thread so that it does not slow
down the other timing events of the lcd, it is after all a remote call
(http) to another host and that may take an undefined amount of time.
( i don't think python itself would make us miss a 'tack' )

So what i'm trying to do is simply a threaded version of the current 
plugin_python, then i wouldn't have to login and logout of the 
eMule process every few minutes as the exec version does.

/dan

Re: [Lcd4linux-devel] Re: lcd4linux Noritake GUI128X32-311 - I got it working !

[OB <ja...@ni...>]

> 
> I think it would be a good idea to support both methods: busy-line
> checking and a fixed delay. We've encountered situations in the past,
> where waiting caused lcd4linux to eat up too much CPU cycles (especially
> on slower systems). 

Funny ! It's precisely because of that reason I reverted to the fixed
delay method : The busy-line checking was eating too much CPU....
But it might come from my crappy MediaGX-based test box.


> Maybe you want to detect it by checking if there's a
> "Wire.Busyline" entry in the config, and/or by using a config entry
> "UseBusy" (as in the HD44780 driver).

Ok, I'll do that on my next commit.
(I've just commited the changes you asked me previously, and btw the
driver now compile without warnings).



Julien

Re: [Lcd4linux-devel] Re: lcd4linux Noritake GUI128X32-311 - I got it working !

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

Hi Julien,

>>- includeing linux/parport.h sould be removed. All parport stuff should
>>be handled by the generic parport driver. I saw that you need some
>>status lines. I will add some wire_status() calls to the parport driver.

> Cool. Actually it's not needed anymore since I've changed my mind, and I
> use a timed wait rather than a busy line polling method.
> It's still a good idea to add some function to get the status lines of
> the parallel port.
I just wrote the wire_status() stuff and commited.

I think it would be a good idea to support both methods: busy-line
checking and a fixed delay. We've encountered situations in the past,
where waiting caused lcd4linux to eat up too much CPU cycles (especially
on slower systems). Maybe you want to detect it by checking if there's a
"Wire.Busyline" entry in the config, and/or by using a config entry
"UseBusy" (as in the HD44780 driver).

bye, Michael

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

[Lcd4linux-devel] New driver : Noritake GU128X32-311

[OB <ja...@ni...>]

Hello, 

I have made a driver for a Noritake GU128x32-311. 
These display can be found currently on ebay/us for about $25, and are
nice-looking VFD display that can do either text mode (21x4) or graphic
mode (128x32), using a parallel interface.

The current driver works only in text mode for now, I plan to add the
graphic mode shortly.

The datasheet can be found here :
http://www.sbrsales.com/Specifications/gu128x32-311.pdf

And the parallel port wiring is here (liquid-mp3 style) :
http://liquid-mp3.schijf.org/schematics/noritake_gu128x32-311.gif

I plan to add these documents to the wiki, along with the appropriate
information in the driver section.

As always, I would be glad to get any feedback on it. Don't hesitate to
tell me if something doesn't work for you ! 


Julien

Re: [Lcd4linux-devel] Re: lcd4linux Noritake GUI128X32-311 - I got it working !

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

Hi Julien,

are you subscribed to lcd4linux-devel?

>>Do you think it would make sense to call the driver "Noritake" and give
>>it a "Model" called "GU311"? So other models could follow, and the file
>>would be called "drv_Noritake.c

> Okay ! Lets'go for that solution. 
> I will send you a drv_Noritake.c file shorlty.
> (I'm glad I did not make the commit !)
Got it, looks fine, checkd it into CVS.

Just a few comments on the driver:

- includeing linux/parport.h sould be removed. All parport stuff should
be handled by the generic parport driver. I saw that you need some
status lines. I will add some wire_status() calls to the parport driver.

- you should not use hardwire_*. This is for displays which will
*always* be wired the same way (i.e. internal devices which are
connected directly to the motherboard).

- you should store your "Models" in a array. Have a look at
drv_Cwlinux.c for an example (but you can modify the struct MODEL to
fulfill your needs)

> Thing is, the Noritake company have a lot of displays, and not all of
> them uses this protocol. Actually, this display is the only one I know
> from Noritake to use that protocol (hitachi microcontroler)
> So, If we add another display later, the protocol will likely be
> completely different, and so we will need to add other functions to this
> file, not at all related to this display. 
Thats no problem, this is the case with other displays, too (Cwlinux,
MatrixOrbital, CrystalFontz)


bye, Michael

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

Re: [Lcd4linux-devel] Re: Python bindings for lcd4linux?

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

Hi Dan again,

> I'm currently trying to steal some threading code from the plugin_exec
> to put into the plugin_python. I have this idea of creating a 
> really slow version of the python::exec function, because then i could 
> easily create plugins for upload and download status of eMule and
> mldonkey (with a polling period of 5 minutes or so).

Why sould it be very slow? I think that python gets initialized only
once, further calls to python::exec() should be quite fast?

If you define an update interval of 5 minutes to the widget calling
python::exec, I see no problem here....

Or is the problem that the python script itself may take some time? Then
it would be a good idea to call it in a seperate thread...


bye, Michael

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

Re: [Lcd4linux-devel] Contrib section + emule plugin

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

Hi Dan,

> What's your thoughts on adding a 'contrib' section to the cvs?
Good point. I just added a (empty) contrib dir to the CVS.

> Since the plugin_python won't accept any arguments you will have to 
> modify the emule.py script to set the correct password, host and port.
Why does it accept no arguments?

> P.S. There seems to be some problem with process termination when using
> plugin_exec. The thread just won't die from a Ctrl-C...
Hmmm... maybe... Should we remember all threads forked off lcd4linux,
and send them a signal on abort, too?

bye, Michael

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

Re: [Lcd4linux-devel] plugin_python.c

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

Hi Dan,

> Update of plugin_python.c:
Checked in, thanks!

> P.S - Michael: let me know when you start getting tired of my updates
> and you want me to check them in directly ;)

consider me being tired :-)

As we're trying to release 0.10 (without RC) as soon as we fixed this
#$&! i2c problem, please be *very* careful when modifying the main parts
of lcd4linux!

bye, Michael

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

[Lcd4linux-devel] Contrib section + emule plugin

[Dan F. <tem...@ya...>]

What's your thoughts on adding a 'contrib' section to the cvs?
I feel i need some place to store the python scripts the plugin_python
is invoking (the same thing with the plugin_exec)

Anyhow, i just cleaned up an old piece of code i use to poll the 
eMule client i got running in my DMZ. 

It is now being run by the plugin_exec, but someday i will invoke it 
from plugin_python. 

Since the plugin_python won't accept any arguments you will have to 
modify the emule.py script to set the correct password, host and port.
 
The script communicates with the web interface of eMule with http
compression disabled.
  
Config sample:

Widget EMULE {
    class 'Text'
    expression  exec('emule.py', 60000)
    prefix 'eMule '
    width 22
    align 'M'
    update tick
}

/Dan 

P.S. There seems to be some problem with process termination when using
plugin_exec. The thread just won't die from a Ctrl-C...

[Lcd4linux-devel] plugin_python.c

[Dan F. <tem...@ya...>]

Update of plugin_python.c:

* replaced fprintf(stderr,...  with error()
* corrected a "dangling reference" memory problem
* removed some PyErr_Print() spam 
* fixed a segmentation fault that occured when python module was not
found
* improved error messages


/Dan

P.S - Michael: let me know when you start getting tired of my updates
and you want me to check them in directly ;)

Re: [Lcd4linux-devel] Re: Python bindings for lcd4linux?

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

Hi Dan and others,

> As for the first step of the python integration....
> 
> I've updated your plugin_python.c file in such a way that it:
> - has a small footprint (nothing else is changed in the source code)
> - is independent of the lcd4linux_wrapper*
> - can operate even when main() is in C
> - (probably) can co-exist with lcd4linux_wrapper (not tested)*  
> - can execute any global python function that takes a string in and
> returns a string

Fine. I just checked it in.

btw, the pyt_exec_str() function takes a variable number of arguments,
so can a plugin do. Maybe you should change that...

> To make python_plugin.c compile and link i had to add:
> DEFS+=$(PYTHON_CPPFLAGS)
> LIBS+=$(PYTHON_EXTRA_LIBS)
> to the Makefile 
> 
> I also had to:
> 
> export PYTHONPATH=.

Everything should be detected by autoconf now. If you did a 'cvs
update', you should run ./bootstrap to ensure everything is updated
correctly.

Thanks for your contribution!

oh, onelast thing: please do not send complete files to the mailing list...

I prefer patches against CVS ('cvs -z9 diff -u' is your friend :-)

bye, Michael

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

Re: [Lcd4linux-devel] I2C again

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

Hi all,

> This could be a solution. But it still is strange that there is 
> difference in the preprocessor stage. Different version of gcc maybe?
>  I have to think on what would be needed for this.
I tried with gcc-3.3 and gcc-4.0. Same result.

> Actually I was thinking that Michael and I already solved this 
> problem. We recently made changes to the configure.in file to solve 
> this correct include file detection. It should work properly for 
> nearly everyone
I think the changes to autoconf solved the problem of detecting the
presence of i2c header files only. The errors I get are still the same.

> (only exception is Michael)
No, I'm not. I know at least of one person having the same problems
(gipsy, are you listening? :-)

> Michael could you send me a tar of your linux header directory. See 
> if we can figure out if there is a difference in any of the files.
Which one do you want? I've got two of'em: one is /usr/include/linux,
which comes with glibc, the other one is from vanilla kernel-2.6.11

> Are you sure you have only one copy of i2c.h on your machine?

That's what 'find / -name "i2c.h"' gives on my notebook:

/usr/include/sound/i2c.h
/usr/include/linux.orig/i2c.h
/usr/src/linux-2.6/arch/cris/arch-v10/drivers/i2c.h
/usr/src/linux-2.6/include/linux/i2c.h
/usr/src/linux-2.6/include/sound/i2c.h
/usr/src/linux-2.6/include/config/fb/riva/i2c.h
/usr/src/linux-2.6/include/config/fb/radeon/i2c.h

the /usr/include/linux.orig is the one from glibc, I renamed it and
placed a symlink to the original kernel headers there:
/usr/include/linux -> /usr/src/linux/include/linux/


bye, Michael

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

Re: [Lcd4linux-devel] I2C again

[Paul K. <pau...@xs...>]

Hi All,

Luis Correia wrote:

>
> Maybe we could provide our own i2c.h helper files, as we do not really 
> need that much info from the I2C subsystem.

This could be a solution. But it still is strange that there is 
difference in the preprocessor stage. Different version of gcc maybe? I 
have to think on what would be needed for this.

> The main problem would be wether we can accurately detect the presence 
> of the real files...
>
> Paul, i'm waiting for your comments on this.
>
Actually I was thinking that Michael and I already solved this problem. 
We recently made changes to the configure.in file to solve this correct 
include file detection. It should work properly for nearly everyone 
(only exception is Michael)

Michael could you send me a tar of your linux header directory. See if 
we can figure out if there is a difference in any of the files. Are you 
sure you have only one copy of i2c.h on your machine?

good night,

Paul

Re: [Lcd4linux-devel] I2C again

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

paul kamphuis wrote:

> Hi Michael,
>
> I haven't tested your test program, but I think it is similar to the 
> test program I started with.
> I know that you are at least missing the following include.
>
> #include <linux/compiler.h>
>
> This include is required for i2c.h to compile correctly. It should 
> however be noted that this compiler.h creates different defines based 
> on the fact if it compiling for kernel space or user space. We need to 
> compile for user space. My guess is, that on your system you are 
> somehow by default compiling for kernel space. The problem is I don't 
> know to switch between kernel and user space compilation.
>
> Can you send your compile errors?
>
> regards,
>
> Paul
>

Maybe we could provide our own i2c.h helper files, as we do not really 
need that much info from the I2C subsystem.
The main problem would be wether we can accurately detect the presence 
of the real files...

Paul, i'm waiting for your comments on this.


Luis

[Lcd4linux-devel] Re: Python bindings for lcd4linux?

[Dan F. <tem...@ya...>]

Hi lcd4linux team!

I've been talking to Michael regarding a python plugin to
your cool application. 
I already got a dynamic layout manager written in python but 
it is a bit intrusive to the rest of the C-code, so we will 
be starting off with a simpler python plugin.


On Mon, 2005-05-02 at 16:33 +0200, Michael Reinelt wrote: 
> Hi Dan,
> 
> I've added you to the developer list. Please set up your CVS. If you
> need any assistance, please let me know.
>
Thanx, i got cvs up and running now. 

As for the first step of the python integration....

I've updated your plugin_python.c file in such a way that it:
- has a small footprint (nothing else is changed in the source code)
- is independent of the lcd4linux_wrapper*
- can operate even when main() is in C
- (probably) can co-exist with lcd4linux_wrapper (not tested)*  
- can execute any global python function that takes a string in and
returns a string

*lcd4linux_wrapper.c=whatever_name_we_decide.c

I also cleaned up the example python code a bit.

To make python_plugin.c compile and link i had to add:
DEFS+=$(PYTHON_CPPFLAGS)
LIBS+=$(PYTHON_EXTRA_LIBS)
to the Makefile 

I also had to:

export PYTHONPATH=.

in order to make the lcd4linux executable find the python code.
When things stabilises a bit i will write a install script 
that will put that piece of code under /usr/lib/pythonX.X/site-packages
where python searches by default.

I have not checked in anything of this, I'm just sending you the bits of
code you need to do a peer-review of the code.
 
I think that's it. 
Oh, one more thing. This is an example of what you can put in
your lcd4linux.conf to make it all work..

Widget PythonNetDev {
    class 'Text'
    expression python::exec('lcd4linuxplugins', 'getNetDev', 'eth0')
    prefix 'eth0: '
    width 23
    align 'R'
    update tick
}

don't forget the "export PYTHONPATH=." when testing directly from build
directory :)

/Dan

Re: [Lcd4linux-devel] I2C again

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

Hi Paul,

thanks for your quick response.

paul kamphuis schrieb:
> I haven't tested your test program, but I think it is similar to the
> test program I started with.
> I know that you are at least missing the following include.
> 
> #include <linux/compiler.h>
ok, I've added this one. But it doesn't help.

> This include is required for i2c.h to compile correctly. It should
> however be noted that this compiler.h creates different defines based on
> the fact if it compiling for kernel space or user space. We need to
> compile for user space. My guess is, that on your system you are somehow
> by default compiling for kernel space. The problem is I don't know to
> switch between kernel and user space compilation.
I don't think that I'm compiling for kernel space, especially because of
one of the errors i get:

/usr/include/linux/list.h:705:2: warning: #warning "don't include kernel
headers in userspace"


> Can you send your compile errors?

Here you are... created only from the preprocessor stage, i.e.

gcc -E -o test-i2c.e test-i2c.c 2>test-i2c.error


bye, Michael

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

RE: [Lcd4linux-devel] I2C again

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

Hi Michael,

> -----Original Message-----
> From: Michael Reinelt [mailto:re...@eu...] 
> Sent: Monday, May 02, 2005 11:41 AM
> To: lcd4linux-devel
> Subject: [Lcd4linux-devel] I2C again
> 
> Hi there,
> 
> I prepared a superb fully-featured massively complext i2c test program
> to verify wether I cannot compile it or not. Well, the 
> latter: I can not.
> 
> I tried on another notebook (debian sarge, too), and I get 
> the same errors.
> 
> Here's the test program:
> 
> #include <stdlib.h>
> #include <stdio.h>
> 
> #include <linux/i2c.h>
> 
> 
> int main (int argc, char *argv[])
> {
>   printf ("Hello, world\n");
> }
> 
> 
> If any (or all) of you are able to compile this beast, I really wonder
> what's wrong here. Maybe we should start with comparing the result of
> the preporocessor stage....
> 
> 
> bye, Michael
> 

I still find this very very strange.

This is what I got on my VM devel system:
(Red Hat Linux release 8.0 (Psyche)  2.4.18-14 )

[root@lc_vm test]# find / -name i2c.h -print
/usr/include/linux/i2c.h
/usr/i386-linux-uclibc/include/linux/i2c.h


What does this command tell you on your system?

Luis Correia

Re: [Lcd4linux-devel] I2C again

[paul k. <pau...@xs...>]

Hi Michael,

I haven't tested your test program, but I think it is similar to the 
test program I started with.
I know that you are at least missing the following include.

#include <linux/compiler.h>

This include is required for i2c.h to compile correctly. It should 
however be noted that this compiler.h creates different defines based on 
the fact if it compiling for kernel space or user space. We need to 
compile for user space. My guess is, that on your system you are somehow 
by default compiling for kernel space. The problem is I don't know to 
switch between kernel and user space compilation.

Can you send your compile errors?

regards,

Paul

Michael Reinelt wrote:

>Hi there,
>
>I prepared a superb fully-featured massively complext i2c test program
>to verify wether I cannot compile it or not. Well, the latter: I can not.
>
>I tried on another notebook (debian sarge, too), and I get the same errors.
>
>Here's the test program:
>
>#include <stdlib.h>
>#include <stdio.h>
>
>#include <linux/i2c.h>
>
>
>int main (int argc, char *argv[])
>{
>  printf ("Hello, world\n");
>}
>
>
>  
>

[Lcd4linux-devel] I2C again

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

Hi there,

I prepared a superb fully-featured massively complext i2c test program
to verify wether I cannot compile it or not. Well, the latter: I can not.

I tried on another notebook (debian sarge, too), and I get the same errors.

Here's the test program:

#include <stdlib.h>
#include <stdio.h>

#include <linux/i2c.h>


int main (int argc, char *argv[])
{
  printf ("Hello, world\n");
}


If any (or all) of you are able to compile this beast, I really wonder
what's wrong here. Maybe we should start with comparing the result of
the preporocessor stage....


bye, Michael

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