Menu
▾
▴
lcd4linux-devel — lcd4linux development team
You can subscribe to this list here.
| 2004 |
Jan
(57) |
Feb
(71) |
Mar
(80) |
Apr
(40) |
May
(49) |
Jun
(20) |
Jul
(3) |
Aug
(9) |
Sep
(8) |
Oct
(2) |
Nov
|
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(10) |
Feb
(25) |
Mar
(24) |
Apr
(26) |
May
(71) |
Jun
(35) |
Jul
(5) |
Aug
(3) |
Sep
(18) |
Oct
(4) |
Nov
(5) |
Dec
(2) |
| 2006 |
Jan
(50) |
Feb
(12) |
Mar
(7) |
Apr
(24) |
May
(1) |
Jun
(17) |
Jul
(51) |
Aug
(38) |
Sep
(38) |
Oct
(33) |
Nov
(8) |
Dec
(13) |
| 2007 |
Jan
(44) |
Feb
(25) |
Mar
(21) |
Apr
(68) |
May
(52) |
Jun
(24) |
Jul
(17) |
Aug
(12) |
Sep
(4) |
Oct
(14) |
Nov
(1) |
Dec
(3) |
| 2008 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(5) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(21) |
Jun
(5) |
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
(15) |
Feb
(36) |
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(3) |
| 2011 |
Jan
(22) |
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
(2) |
Jun
|
Jul
(25) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2012 |
Jan
(14) |
Feb
(6) |
Mar
(20) |
Apr
(12) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(9) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(11) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: paul k. <pau...@xs...> - 2005-05-13 09:24:34
|
Hi Michael, >>- clean get from cvs >>- ./configure >>tux lcd4linux # make >>cd . && aclocal-1.4 >>aclocal: macro `AM_PATH_PYTHON' required but not defined >>make: *** [aclocal.m4] Error 1 >> >> > >Well, this is *really* strange. Works here like a charm. > > > I am not that good with CVS, are there any changes since last night and today? I did this about 30 minutes ago and it builds correctly. However the problem is not solved, yet. Once I change configure.in to remove the i2c detection. (I modified this file a couple of weeks ago without any problems) And then do make. I still get the same error as above. So for some reason regenerating files like configure (from configure.in) and probably Makefile (from Makefile.am) produces incorrect results. >>This definition is cached in aclocal.m4 and is in >> >> >HereI get no definitions about python in aclocal.m4 (neither from >plugins.m4 and drivers.m4) > > Sorry, you are richt. it is not really cached in this file.but there is in a situation a autom4te.cache directory created that, possibly cashes stuff. >Did you try to rename the python.m4 in the lcd4linux directory and to >change the sinclude(python.m4) line in configure.in? > > I did this and that is how I found out that there is some sort of caching somewhere. There are files used when processing configure.in, that are recreated by that same process. There is some sort of circular dependency in there. >>But no object files are created and the linking stage fails >>See the attached files for the make output. >> >> >Well, this is even more strange. > > > >>make all-am >> >> >why not simply 'make'? >make[1]: Entering directory `/root/lcd4linux' > > >>source='lcd4linux.c' object='lcd4linux.o' libtool=no \ >>DEPDIR=.deps depmode=none /bin/sh ./depcomp \ >>gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/python2.3 -D_GNU_SOURCE -Wall -W -g -O2 -c lcd4linux.c >> >> >looks strange... > >what's this depcomp? It's in CVS, but with zero size. Maybe something >from libtool? > > > > All this is probably related to an incorrectly recreated Makefile om my system. All this is really strange. When I take out the AC_PYTHON_DEVEL line in configure.in followed by make, then everything goes well. Inserting AC_PYTHON_DEVEL again, breaks it again. bye, Paul |
|
From: Michael R. <re...@eu...> - 2005-05-13 07:03:17
|
Hi Paul, > - clean get from cvs > - ./configure > tux lcd4linux # make > cd . && aclocal-1.4 > aclocal: macro `AM_PATH_PYTHON' required but not defined > make: *** [aclocal.m4] Error 1 Well, this is *really* strange. Works here like a charm. > This definition is cached in aclocal.m4 and is in HereI get no definitions about python in aclocal.m4 (neither from plugins.m4 and drivers.m4). Did you try to rename the python.m4 in the lcd4linux directory and to change the sinclude(python.m4) line in configure.in? > But no object files are created and the linking stage fails > See the attached files for the make output. Well, this is even more strange. > make all-am why not simply 'make'? > make[1]: Entering directory `/root/lcd4linux' > source='lcd4linux.c' object='lcd4linux.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/sh ./depcomp \ > gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/python2.3 -D_GNU_SOURCE -Wall -W -g -O2 -c lcd4linux.c looks strange... what's this depcomp? It's in CVS, but with zero size. Maybe something from libtool? bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Paul K. <pau...@xs...> - 2005-05-12 21:06:26
|
Hi Michael, I still think there is something wrong with the configuration files. Here is what I do: - clean get from cvs - ./configure tux lcd4linux # make cd . && aclocal-1.4 aclocal: macro `AM_PATH_PYTHON' required but not defined make: *** [aclocal.m4] Error 1 This definition is cached in aclocal.m4 and is in I have to throw away Makefile, Makefile.in and aclocal.m4 and do ./bootstrap ./configure To recreate the previous files. The do make to start the build process. make But no object files are created and the linking stage fails See the attached files for the make output. I have no idea what goes wrong here :'( bye, Paul Michael Reinelt wrote: >Hi Paul, > > > >>Ok, I think I know what the problems is. But I am not sure on how to >>solve it. >>For some reason the python.m4 in the local directory is not found by >>aclocal. >>If I run >> >>aclocal -I . >> >>to specify the local directory as an include directory, followed by >>make, it works fine. >> >>So there are several possible causes of this different behaviour. >> >>1) >>you run a different version of aclocal. I use aclocal 1.4 but I noticed >>that version 1.9 has the python.m4 in its standard macro set. (I still >>can't figure out how gentoo selects different version of aclocal to use) >> >>2) >>for some reason you have the local directory included in the aclocal >>include path by default. >> >> > >I don't think that you have to include . in the search path. If this >would be necessary, aclocal would not find drivers.m4, curses.m4 neither. > >But I've another strong suspicion: aclocal loads the global python.m4 >before the local one (as you said, aclocal-1.9 provides a python.m4). > >You could try to rename the python.m4 and change the reference in.. in.. >wherever it's referenced. > > >bye, Michael > > > |
|
From: Michael R. <re...@eu...> - 2005-05-11 19:28:53
|
Hi Paul, > Ok, I think I know what the problems is. But I am not sure on how to > solve it. > For some reason the python.m4 in the local directory is not found by > aclocal. > If I run > > aclocal -I . > > to specify the local directory as an include directory, followed by > make, it works fine. > > So there are several possible causes of this different behaviour. > > 1) > you run a different version of aclocal. I use aclocal 1.4 but I noticed > that version 1.9 has the python.m4 in its standard macro set. (I still > can't figure out how gentoo selects different version of aclocal to use) > > 2) > for some reason you have the local directory included in the aclocal > include path by default. I don't think that you have to include . in the search path. If this would be necessary, aclocal would not find drivers.m4, curses.m4 neither. But I've another strong suspicion: aclocal loads the global python.m4 before the local one (as you said, aclocal-1.9 provides a python.m4). You could try to rename the python.m4 and change the reference in.. in.. wherever it's referenced. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: paul k. <pau...@xs...> - 2005-05-11 06:46:40
|
Hi Michael, Ok, I think I know what the problems is. But I am not sure on how to solve it. For some reason the python.m4 in the local directory is not found by aclocal. If I run aclocal -I . to specify the local directory as an include directory, followed by make, it works fine. So there are several possible causes of this different behaviour. 1) you run a different version of aclocal. I use aclocal 1.4 but I noticed that version 1.9 has the python.m4 in its standard macro set. (I still can't figure out how gentoo selects different version of aclocal to use) 2) for some reason you have the local directory included in the aclocal include path by default. Only explaination I found so far is at: http://sources.redhat.com/automake/automake.html#Extending-aclocal Any suggestions? Paul |
|
From: paul k. <pau...@xs...> - 2005-05-11 06:05:44
|
Hi Michael, >Hi Paul, > > > >>Not sure if this is related to your autoconf stuff but I just got the >>latest version from cvs and now have a problem. >>This is the output of the make command: >>cd . && aclocal-1.4 >>aclocal: macro `AM_PATH_PYTHON' required but not defined >>make: *** [aclocal.m4] Error 1 >> >> > >Strange. AM_PATH_PYTHON is defined in python.m4. Could you have alook there? > >Did you try a ./bootstrap? > > > I think it is python.m4. ./bootstrap gives the same error. I also tried the export PYTHONPATH=. that Dan suggested. No luck! Paul |
|
From: Michael R. <re...@eu...> - 2005-05-11 04:29:07
|
Hi Paul, > Not sure if this is related to your autoconf stuff but I just got the > latest version from cvs and now have a problem. > This is the output of the make command: > cd . && aclocal-1.4 > aclocal: macro `AM_PATH_PYTHON' required but not defined > make: *** [aclocal.m4] Error 1 Strange. AM_PATH_PYTHON is defined in python.m4. Could you have alook there? Did you try a ./bootstrap? bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Paul K. <pau...@xs...> - 2005-05-10 21:01:09
|
Hi Michael, Michael Reinelt wrote: >Hi Dan, > >I just checked in a first try with python: I tried to manage the >autoconf stuff for python (dear god, it's not that easy...), and >prepared an (empty) python plugin. > > Not sure if this is related to your autoconf stuff but I just got the latest version from cvs and now have a problem. This is the output of the make command: cd . && aclocal-1.4 aclocal: macro `AM_PATH_PYTHON' required but not defined make: *** [aclocal.m4] Error 1 Any ideas? |
|
From: OB <ja...@ni...> - 2005-05-10 17:06:10
|
On Tue, 2005-05-10 at 15:26 +0200, Michael Reinelt wrote: > Hi there, > > ever heard of serdisplib? Its a library that drives several graphic > displays, most of them using a special serial protocol. It allows you to > use displays from old mobile phones! > > http://serdisplib.sourceforge.net > > I just added a driver to lcd4linux! This way more than 10 new displays > are supported by lcd4linux! > > At the moment I don't own a display supported by serdisplib, but if > someone of you got one, I'd appreciate some testing very much! > > If somebody plans to add a new display driver to lcd4linux (SED-xyz), > please check the serdisplib page first, maybe it's already supported! Thanks a lot Michaels ! I have a 320x240 display based on a SED1335, so it should work with serdisplib ! (I did not made the interface cable, though) I also have the c-pad, wich is a SED1335 plugged on a USB device on a touchpad (on its own endpoint). The display-access layer is different but the instructions are the same. I will definitively try this one ! (I want to finish the graphical noritake driver first) Julien |
|
From: Michael R. <re...@eu...> - 2005-05-10 14:16:38
|
Hi there, ever heard of serdisplib? Its a library that drives several graphic displays, most of them using a special serial protocol. It allows you to use displays from old mobile phones! http://serdisplib.sourceforge.net I just added a driver to lcd4linux! This way more than 10 new displays are supported by lcd4linux! At the moment I don't own a display supported by serdisplib, but if someone of you got one, I'd appreciate some testing very much! If somebody plans to add a new display driver to lcd4linux (SED-xyz), please check the serdisplib page first, maybe it's already supported! Have Fun! Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Luis.F.Correia <Lui...@se...> - 2005-05-09 13:32:19
|
Hi! > -----Original Message----- > From: paul kamphuis [mailto:pau...@xs...] > >I think paul is already working on it. The only solutions > seems to be to > >have our own i2c.h > > > > > > > Correct. What I did at this stage, is simply combining the stuff from > linux/i2c.h and linux/i2c-dev.h into a header file called > lcd4linux_i2c.h and add some required typedefs. Currently I > am not sure, > if I want to clean up the whole stuff. I am planning on doing > some more > stuff with the i2c so I might need it later. It builds fine now. But > actually haven't tested it running yet. Hope to get a change on that > tonight. Ok, feel free to send me whatever you have ready at this point. I plan to restart development on my WRAP1C platform very soon, so it will be good to have something ready :) > > bye, > > Paul > Luis Correia |
|
From: paul k. <pau...@xs...> - 2005-05-09 13:09:31
|
Hi Luis and Michael >>p.s. still thinking abou how to solve the I2C thing... >> >> >I think paul is already working on it. The only solutions seems to be to >have our own i2c.h > > > Correct. What I did at this stage, is simply combining the stuff from linux/i2c.h and linux/i2c-dev.h into a header file called lcd4linux_i2c.h and add some required typedefs. Currently I am not sure, if I want to clean up the whole stuff. I am planning on doing some more stuff with the i2c so I might need it later. It builds fine now. But actually haven't tested it running yet. Hope to get a change on that tonight. bye, Paul |
|
From: Michael R. <re...@eu...> - 2005-05-09 12:44:09
|
Hi Luis, > I think that you (or someone) needs to create write access to the wiki, > right? No, the Wiki is open for anonymous users, too. Although I'd prefer that you either overwrite the name "anonymous" with your name, or log in into the wiki. > If so, please add me as 'lfcorreia'. Provide a password and i'll change it > later. I'll send this to Sam, he's able to create accounts. > p.s. still thinking abou how to solve the I2C thing... I think paul is already working on it. The only solutions seems to be to have our own i2c.h bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-05-08 05:07:42
|
Hi there, I just added a "Cool Stuff" section to the lcd4linux wiki. You all are invited to add some sexy photos of lcd4linux there! @geronet: please add the image you sent me lately in ICQ! Thanks, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-05-08 04:38:13
|
Hi alltogether, I just applied and checked in an 'indented' version of the lcd4linux source. See the Files 'CodingStyle' and 'indent.sh' for details. @geronet: I removed the -pcs option! Have fun! -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-05-07 16:22:31
|
Hi there, >> I am afraid it is not. It is graphics only and no 4 bit mode. Great! Another graphical display! Times are coming when we're in the need for more cool & sexy graphical widgets :-) >> But it doesn't look to complicated. Most complicated is my >> connection scheme. I wan't to connect it to my i2c bus. (Stupid >> me!) I have two options for this, one is using a slightly exotic 16 >> bit IO expander. Or using 2 'standard' PCF8574 devices, one for 8 >> data lines and one for the control lines. Personally I favor the >> second option, since ironing is less complicated. I have absolutely no idea what you're talking about, so I vote for the second one. Is it possible to connect it to the parallel port, too? bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Luis C. <lfc...@lf...> - 2005-05-07 14:42:10
|
Hi! > >> >> Isn't the KS0108 somehow compatible to the HD44780? Or am I mixing >> things up here? >> > I am afraid it is not. It is graphics only and no 4 bit mode. But it > doesn't look to complicated. Most complicated is my connection scheme. I > wan't to connect it to my i2c bus. (Stupid me!) I have two options for > this, one is using a slightly exotic 16 bit IO expander. Or using 2 > 'standard' PCF8574 devices, one for 8 data lines and one for the control > lines. Personally I favor the second option, since ironing is less > complicated. I would go for a two PCF8574 devices. Easier to maintain, I would guess... And also more simple integration with current code. -- Luis Correia |
|
From: Paul K. <pau...@xs...> - 2005-05-07 14:29:16
|
> > Isn't the KS0108 somehow compatible to the HD44780? Or am I mixing > things up here? > I am afraid it is not. It is graphics only and no 4 bit mode. But it doesn't look to complicated. Most complicated is my connection scheme. I wan't to connect it to my i2c bus. (Stupid me!) I have two options for this, one is using a slightly exotic 16 bit IO expander. Or using 2 'standard' PCF8574 devices, one for 8 data lines and one for the control lines. Personally I favor the second option, since ironing is less complicated. Any comments? Paul |
|
From: Michael R. <re...@eu...> - 2005-05-07 08:34:22
|
Hi Paul, > The question is simple. Is there current support for displays with a > KS0108 controller? Not to my knowledge. Isn't the KS0108 somehow compatible to the HD44780? Or am I mixing things up here? bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: paul k. <pau...@xs...> - 2005-05-06 13:25:03
|
Hi, The question is simple. Is there current support for displays with a KS0108 controller? regards, Paul |
|
From: Michael R. <re...@eu...> - 2005-05-06 08:20:51
|
Hi Paul, > I think on gentoo the so called linux-headers are actually the mentioned > linux-libc-headers. And on your system the headers are the true kernel > headers. I've got libc-headers, too. They differ a bit from the kernel headers (libc headers are from an older kernel), but there's neither a #ifdef __KERNEL__ with i2c.h > The best solution for us right now would be extract what we need from > the kernel headers and put it in our own header. And keep track of > changes in the kernel on this in the future. Sad but true. Right. > Give me a little time to get it done :-) You will do it? Great! We sould change the configure stuff, too. There's no need to check for a "global" i2c.h bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: paul k. <pau...@xs...> - 2005-05-06 08:06:30
|
>See attachment. > >I think the i2c.h file from the kernel ist simply not intended for >userspace programs... if this is true, we have to create our own i2c.h... > > >bye, Michael > > > You are right. This is what I found. On the gentoo forum: Hence the two separate sets of header files: 1. system headers in /usr/include, to build software, and 2. current kernel headers in /usr/src/linux, to build the kernel. Some e-mail message from Linus on this: http://www.linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html And the clearest explaination http://linuxfromscratch.org/pipermail/faq/2004-July/000159.html Note the FAQ at the end of this page: I think on gentoo the so called linux-headers are actually the mentioned linux-libc-headers. And on your system the headers are the true kernel headers. The best solution for us right now would be extract what we need from the kernel headers and put it in our own header. And keep track of changes in the kernel on this in the future. Sad but true. Give me a little time to get it done :-) bye, Paul |
|
From: Michael R. <re...@eu...> - 2005-05-06 08:00:43
|
Paul, > This is strange. Look what my first part of the i2c.h looks like. > [...] > #ifdef __KERNEL__ > # include <linux/module.h> > # include <linux/types.h> > #else > # define __KERNEL__ > # include <linux/types.h> > # undef __KERNEL__ > #endif > Same file revision, only different contents. Yes, and this contens explains why it works for you. > I am now first going to > check, if gentoo apply patches to these headers files. This is really > strange. I'm shure that there are some patches from gentoo. As I said, my headers are from Linus himself :-), and I did not modify them. I'm afraid we really have to create our own i2c.h... -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: paul k. <pau...@xs...> - 2005-05-06 07:39:46
|
This is strange. Look what my first part of the i2c.h looks like.
/*
------------------------------------------------------------------------- */
/*
*/
/* i2c.h - definitions for the i2c-bus
interface */
/*
*/
/*
------------------------------------------------------------------------- */
/* Copyright (C) 1995-2000 Simon G. Vogl
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
USA. */
/*
------------------------------------------------------------------------- */
/* With some changes from Kyösti Mälkki <km...@cc...> and
Frodo Looijaard <fr...@dd...> */
/* $Id: i2c.h,v 1.68 2003/01/21 08:08:16 kmalkki Exp $ */
#ifndef _LINUX_I2C_H
#define _LINUX_I2C_H
#ifdef __KERNEL__
# include <linux/module.h>
# include <linux/types.h>
#else
# define __KERNEL__
# include <linux/types.h>
# undef __KERNEL__
#endif
#include <linux/i2c-id.h>
#ifdef __KERNEL__
#include <linux/device.h> /* for struct device */
#include <asm/semaphore.h>
Same file revision, only different contents. I am now first going to
check, if gentoo apply patches to these headers files. This is really
strange.
Paul
Michael Reinelt wrote:
>Hi Paul,
>
>
>
>
>>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
>>
>>
>
>No, not here:
>
>merlin:~ $ more /usr/include/linux/i2c.h
>/*--------------------------------------------------------------------*/
>/* */
>/* i2c.h - definitions for the i2c-bus interface */
>/* */
>/*--------------------------------------------------------------------*/
>/* Copyright (C) 1995-2000 Simon G. Vogl
>
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 2 of the License, or
> (at your option) any later version.
>
> This program is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> GNU General Public License for more details.
>
> You should have received a copy of the GNU General Public License
> along with this program; if not, write to the Free Software
> Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> */
>/*--------------------------------------------------------------------*/
>
>/* With some changes from Kyösti Mälkki <km...@cc...> and
> Frodo Looijaard <fr...@dd...> */
>
>/* $Id: i2c.h,v 1.68 2003/01/21 08:08:16 kmalkki Exp $ */
>
>#ifndef _LINUX_I2C_H
>#define _LINUX_I2C_H
>
>#include <linux/module.h>
>#include <linux/types.h>
>#include <linux/i2c-id.h>
>#include <linux/device.h> /* for struct device */
>#include <asm/semaphore.h>
>
>There's no #ifdef __KERNEL__ around here...
>
>
>
>>Which version of the kernel headers are you using? That warning message
>>in list.h is on line 713 on my system.
>>
>>
>Line 705 or so here. Ther header files are from a vanilla 2.6.11 kernel
>
>
>
>>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
>>
>>
>
>Too big for the mailing list, I'll send them with a PM to Paul only.
>
>I think the i2c.h file from the kernel ist simply not intended for
>userspace programs... if this is true, we have to create our own i2c.h...
>
>
>bye, Michael
>
>
>
|
|
From: Michael R. <re...@eu...> - 2005-05-06 07:31:23
|
Hi Paul,
> I still think that somehow you're building for kernel space. The reason
> for this is the following items in your output:
>=20
>> ----------------------------------------------------------------------=
--
>>
>> 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
>> =20
>>
> This module.h is only included (on my system) when __KERNEL__ is define=
d
> when compiling i2c.h
No, not here:
merlin:~ $ more /usr/include/linux/i2c.h
/*--------------------------------------------------------------------*/
/* */
/* i2c.h - definitions for the i2c-bus interface */
/* */
/*--------------------------------------------------------------------*/
/* Copyright (C) 1995-2000 Simon G. Vogl
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/*--------------------------------------------------------------------*/
/* With some changes from Ky=F6sti M=E4lkki <km...@cc...> and
Frodo Looijaard <fr...@dd...> */
/* $Id: i2c.h,v 1.68 2003/01/21 08:08:16 kmalkki Exp $ */
#ifndef _LINUX_I2C_H
#define _LINUX_I2C_H
#include <linux/module.h>
#include <linux/types.h>
#include <linux/i2c-id.h>
#include <linux/device.h> /* for struct device */
#include <asm/semaphore.h>
There's no #ifdef __KERNEL__ around here...
> Which version of the kernel headers are you using? That warning message
> in list.h is on line 713 on my system.
Line 705 or so here. Ther header files are from a vanilla 2.6.11 kernel
> 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
Too big for the mailing list, I'll send them with a PM to Paul only.
I think the i2c.h file from the kernel ist simply not intended for
userspace programs... if this is true, we have to create our own i2c.h...
bye, Michael
--=20
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
|
163 messages has been excluded from this view by a project administrator.
