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: Michael R. <re...@eu...> - 2005-05-02 10:42:22
|
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. Could you please tell me your name so I can put it into the copyright notice? As a next step I'm going to add the python wrapper so that the plugin does something senseful. We should continue our discussions on the lcd4linux-devel list, therefore I cc'ed my answer. Could you please subscribve there? Thanks! bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-04-29 06:03:23
|
Hi Julien, > I just want to tell you that I finally got my Noritake GU128x32-311 > working ! Well, that's great news! > It is used as a text-mode display by now, even if it's a graphical > display (The display itself has 2 modes: one text and one graphic). > The problem with the graphic mode are, first, I'm worried about the > bandwidth needed on the parallel port to refresh all the display, and > also, the microcontroller uses a very very weird way to pack the > data, and I could not find (yet) an efficient way to do it in C. Could you send mo a description of the packed format? There#s no need to worry about bandwidth issues, lcd4linux uses a very sophisticated double-buffering, so the data transfers are reduced to a minimum. > Also, I did not put the "bars" widget support on this version, I will > do it quickly through. Don't care about it too much. As it's a graphical display, we should use it's graphical mode only, and the bar rendering for graphic LCD's is ready to use. > - There is no TSC inside the MediaGX processor : Linux rely on a less > accurate timer, and it is sensitive to the load of the machine. (I > measured that with an oscilloscope) That's not that good, but it should not matter: just include some reserve in your timing values. > The only think that make me hesitate is that I don't know how to > *exactly* modify these #%!$#!@ autoconf/automake files in the CVS, to > avoid messing up everything. > Michael, would it be possible for you to update the README.driver to > explain that as much as you can ? I don't want to mess up the > repository. Thanks ! Hmm... as this is quite complicated stuff, I don't see too much sense in trying to document that. Could you send me a patch (cvs -z9 diff -u) and I'll integrate it into the autojunk stuff. > Next projects in the pipeline : - A driver for a SED1335 on USB > display Great! > - A driver for a framebuffer display, because I want to map any > graphical display on a framebuffer, if the bandwidth to the display > is sufficent. Well, that's already done. drv_generic_graphic.c Take a look at the T6963 driver, it uses this interface. It's that easy... you only have to write sort of a 'blit' function, the generic graphic driver takes care of the rest. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Julien A. <ja...@ni...> - 2005-04-28 22:46:43
|
Hello, I just want to tell you that I finally got my Noritake GU128x32-311 working ! It is used as a text-mode display by now, even if it's a graphical display (The display itself has 2 modes: one text and one graphic). The problem with the graphic mode are, first, I'm worried about the bandwidth needed on the parallel port to refresh all the display, and also, the microcontroller uses a very very weird way to pack the data, and I could not find (yet) an efficient way to do it in C. Also, I did not put the "bars" widget support on this version, I will do it quickly through. There is still a few bugs on this version, because my test computer is a network appliance. It has the following problems : - The power supply is weak, so the voltage of the lines are not stable (I take the power fro the computer, and the display use ~1Amp fully lighted) - There is no TSC inside the MediaGX processor : Linux rely on a less accurate timer, and it is sensitive to the load of the machine. (I measured that with an oscilloscope) The consequences is that, sometime, some characters are wrong, misplaced or not present. I plan to correct that. Anyway, I'm ready for inclusion into the CVS, as a beta version. The only think that make me hesitate is that I don't know how to *exactly* modify these #%!$#!@ autoconf/automake files in the CVS, to avoid messing up everything. On my own repository I have made some scripts and stuff to not use them, but for inclusion it will become necessary. Michael, would it be possible for you to update the README.driver to explain that as much as you can ? I don't want to mess up the repository. Thanks ! Anybody that have such a display, and the cable from this schematics: http://liquid-mp3.schijf.org/schematics/noritake_gu128x32-311.gif is welcome to try and send feedbacks. Next projects in the pipeline : - A driver for a SED1335 on USB display [ a so-called cPad on a Toshiba laptop, see http://www.janerob.com/rob/ts5100/cPad/index.shtml ] - A driver for a framebuffer display, because I want to map any graphical display on a framebuffer, if the bandwidth to the display is sufficent. Cheers ! OB On Sat, 2005-04-23 at 21:18, fr...@gu... wrote: > > > I'll start the tests in windows as soon as I can, and if/when I get it > > > to work there I'll get back to you .... > > but, at least, it was useful to verify that the wiring was correct and > > the display answered. > > It works like a charm, I grabbed the latest alpha and simply renamed the corresponding noritake311 xml file to liquid-mp3.xml and got it to work instantly. > > > I have much more time now to work on the driver for the noritake, count > > 1 or 2 weeks at most before I can push a beta to the CVS. > > No rush here, I still have to figure out to make this thing fit my HTPC box, in worst case I'll have to unsolder all the 198 connectors between the PCB and the VFD, to attach extra cables in between :D > > > Do you have any programming experience ? > > None really worth mentioning, I've been working with C, but I've never really done any advanced programming in it, and when it comes to C++ I'm totally lost :D > > ___________________________________ > Sent from www.guldnallen.com > > |
|
From: Kiley C. <Ca...@ja...> - 2005-04-26 04:40:46
|
Hello, nature of his altercation with Wolverstone, was embarrassing. pleading, that he is putting forward excuses for his hero. I thi waterside tavern, he was accosted by a splendid ruffian in a soul and honour, sir, you go much too far. You are.... boats, laden to capacity with survivors. And there were others became a very welcome guest. M. d'Ogeron was in the Captain's de this supercilious, arrogant cockerel. as it had with hers. that very day. Some, I think. You have been very hardly used by Fate. of the bar. My prisoners, most of whom are persons of considerat that they were unsteady. The satisfaction of a mariner. Have a nice day. |
|
From: Paul K. <pau...@xs...> - 2005-04-06 05:34:02
|
> I have just downloaded our own 'buildtool' tom compile stuff for > uClibc, and the current CVS compiles lcd4linux with i2c support right > on the first run! Don't know if it will actually work, as I don't have > the hardware at hand right now. But no major compile errors is a > pretty good start. > Same here. And it even runs properly with i2c support > (now lets gather in prayer, hoping Michael can exorcise his devel PC...) > Amen Paul |
|
From: Luis C. <lfc...@lf...> - 2005-04-05 22:40:08
|
Michael Reinelt wrote: >Hi Luis, > > > >>Try this, go to your current kernel source and enable I2C support. >>Then, run make dep. >> >> > >I do have I2C support enabled. ANd 'make dep' gives me > >merlin.ethnet:/usr/src/linux # make dep >*** Warning: make dep is unnecessary now. > >on my 2.6.11 kernel :-) > > >nice try! :-) > > >bye, michael > > > It is official, you really have things screwed up in your machine. I would advise you to install a new PC with all standard development packages, including kernel, of your favorite distro, using the distro's provided kernel and see if this particular problem still exists. This is only if you can spare some hours doing it, and if you have the spare hardware, of course :) I have just downloaded our own 'buildtool' tom compile stuff for uClibc, and the current CVS compiles lcd4linux with i2c support right on the first run! Don't know if it will actually work, as I don't have the hardware at hand right now. But no major compile errors is a pretty good start. Well done Paul & Michael! (now lets gather in prayer, hoping Michael can exorcise his devel PC...) Luis Correia |
|
From: paul k. <pau...@xs...> - 2005-04-05 09:13:14
|
>Yes, there *is* something broken here. It has something to do with the >i2c.h file. It includes lots of other files, which should be used only >when compiling the kernel. > > > So if I understand correctly, you have (for some reason) this __KERNEL__ define set. That is strange. That should only be set when compiling the actual kernel, ie compile for kernel space use. We want to use it in user space. So __KERNEL__ should not be defined. Can you verify your default compiler settings? or the environment variables (probably using a windows term here)? >A ugly workaround would be to extract the needed symbols from i2c.h and >hardcode them into drv_generic_i2c. But, as I said, ugly ugly ugly.... > >Is there any other sowftware out there which uses the i2c subsystem? I >once had a look into lm_sensors, but they do not really use the i2c >interface, but the various files in /proc or /sys only. > >bye, Michael > > That is too ugly for me too. Would it be possible to undefine __KERNEL__ prior to building L4L? If I am not mistaken, the only reason we need this i2c stuff, is for the i2c_smbus* definitions. I am not sure how lm_sensors handle these issues. Actually I think I know. /proc and /sys require kernel space drivers to perform the i2c actions. However I would expect that 'i2cdetect' would do it directly. And I do know that lm_sensors does require the 2.6 kernel headers installed for the i2c support. On kernel 2.4 lm_sensors had their own set of i2c includes. Paul |
|
From: Luis.F.Correia <Lui...@se...> - 2005-04-05 09:08:24
|
Hi! > -----Original Message----- > From: Michael Reinelt [mailto:re...@eu...] > Sent: Tuesday, April 05, 2005 9:42 AM > To: lcd4linux-devel > Subject: Re: [Lcd4linux-devel] Re: fixes to the i2c patch > that Luis suppli ed > > Sorry for the first post, hit the wrong button :-) > > >>on my 2.6.11 kernel :-) > > Are you absolutely sure that that's your running kernel? > > Yes, I am. Absolutely very shure. > > > In my Fedora system, the source can be looked at > > /lib/modules/(kernel-version)/build > > if i'm not mistaken... > I'm using debian, but none of the debian kernels, but my own vanilla > homebrew kernel 2.6.11 from kernel.org. > > > Anyway, you must have something broken over there, I just > don't know what... > Yes, there *is* something broken here. It has something to do with the > i2c.h file. It includes lots of other files, which should be used only > when compiling the kernel. > > A ugly workaround would be to extract the needed symbols from > i2c.h and > hardcode them into drv_generic_i2c. But, as I said, ugly ugly ugly.... > > Is there any other sowftware out there which uses the i2c subsystem? I > once had a look into lm_sensors, but they do not really use the i2c > interface, but the various files in /proc or /sys only. Well, to be able to talk with I2C devices, some drivers must be present. lm_sensors does use i2c interface, in fact they were the originators of the current I2C support in Linux. But I really don't have an answer to your particular problem. I'll ask my other Linux co-workers for possible workarounds... > > bye, Michael > > -- > Michael Reinelt <re...@eu...> Luis Correia |
|
From: Michael R. <re...@eu...> - 2005-04-05 08:47:07
|
Sorry for the first post, hit the wrong button :-) >>on my 2.6.11 kernel :-) > Are you absolutely sure that that's your running kernel? Yes, I am. Absolutely very shure. > In my Fedora system, the source can be looked at > /lib/modules/(kernel-version)/build > if i'm not mistaken... I'm using debian, but none of the debian kernels, but my own vanilla homebrew kernel 2.6.11 from kernel.org. > Anyway, you must have something broken over there, I just don't know what... Yes, there *is* something broken here. It has something to do with the i2c.h file. It includes lots of other files, which should be used only when compiling the kernel. A ugly workaround would be to extract the needed symbols from i2c.h and hardcode them into drv_generic_i2c. But, as I said, ugly ugly ugly.... Is there any other sowftware out there which uses the i2c subsystem? I once had a look into lm_sensors, but they do not really use the i2c interface, but the various files in /proc or /sys only. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Luis.F.Correia <Lui...@se...> - 2005-04-05 08:00:19
|
Hi Michael, > -----Original Message----- > From: Michael Reinelt [mailto:re...@eu...] > Sent: Tuesday, April 05, 2005 8:53 AM > To: lcd4linux-devel > Subject: Re: [Lcd4linux-devel] Re: fixes to the i2c patch > that Luis suppli ed > > Hi Luis, > > > Try this, go to your current kernel source and enable I2C support. > > Then, run make dep. > > I do have I2C support enabled. ANd 'make dep' gives me > > merlin.ethnet:/usr/src/linux # make dep > *** Warning: make dep is unnecessary now. > > on my 2.6.11 kernel :-) Are you absolutely sure that that's your running kernel? In my Fedora system, the source can be looked at /lib/modules/(kernel-version)/build if i'm not mistaken... Anyway, you must have something broken over there, I just don't know what... > > > nice try! :-) > > > bye, michael > > -- > Michael Reinelt <re...@eu...> > http://home.pages.at/reinelt > GPG-Key 0xDF13BA50 > ICQ #288386781 Luis |
|
From: Michael R. <re...@eu...> - 2005-04-05 07:53:27
|
Hi Luis, > Try this, go to your current kernel source and enable I2C support. > Then, run make dep. I do have I2C support enabled. ANd 'make dep' gives me merlin.ethnet:/usr/src/linux # make dep *** Warning: make dep is unnecessary now. on my 2.6.11 kernel :-) nice try! :-) bye, michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Luis.F.Correia <Lui...@se...> - 2005-04-05 07:25:10
|
Hi! > -----Original Message----- > From: Michael Reinelt [mailto:re...@eu...] > Sent: Tuesday, April 05, 2005 7:02 AM > To: lcd4linux-devel > Subject: [Lcd4linux-devel] Re: fixes to the i2c patch that > Luis supplied > > Take #2: this should have gone to the list :-) > > Hi Paul and others, > > Paul Kamphuis wrote: > > I created a patch file for the corrections I made to > current CVS tree to > > make the i2c work properly. > > I applied the following changes: > > drv_generic_i2c.c > > - store section in the open function > > - made Section variable const to remove compiler warning > I reverted this one a bit. I casted the parameter on assignment to the > global variable, and stored 'Driver', too. Same as in > drv_generic_parport. > > > configure.in > > - modified the i2c verification/detection to correctly > detect and enable > > i2c support > > note: i2c support requires a 2.6 kernel and kernel headers > installed. I > > assume this detection would be > > sufficient for proper i2c enable/disable > > But it still does not work here. I again get tons of errors: Try this, go to your current kernel source and enable I2C support. Then, run make dep. I remember having to do such a trick to get it compiling on 2.4 a loooooong time ago :) Btw, my 2.4 development system is not ready yet... Luis Correia |
|
From: Michael R. <re...@eu...> - 2005-04-05 06:01:50
|
Take #2: this should have gone to the list :-)
Hi Paul and others,
Paul Kamphuis wrote:
> I created a patch file for the corrections I made to current CVS tree to
> make the i2c work properly.
> I applied the following changes:
> drv_generic_i2c.c
> - store section in the open function
> - made Section variable const to remove compiler warning
I reverted this one a bit. I casted the parameter on assignment to the
global variable, and stored 'Driver', too. Same as in drv_generic_parport.
> configure.in
> - modified the i2c verification/detection to correctly detect and enable
> i2c support
> note: i2c support requires a 2.6 kernel and kernel headers installed. I
> assume this detection would be
> sufficient for proper i2c enable/disable
But it still does not work here. I again get tons of errors:
gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include -D_GNU_SOURCE
-Wall -W -g -O2 -c drv_generic_i2c.c
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 drv_generic_i2c.c:48:
/usr/include/linux/jiffies.h:16: error: parse error before "jiffies_64"
/usr/include/linux/jiffies.h:20: error: parse error before "get_jiffies_64"
In file included from /usr/include/linux/cpumask.h:8,
from /usr/include/linux/sched.h:15,
from /usr/include/linux/module.h:10,
from /usr/include/linux/i2c.h:31,
from drv_generic_i2c.c:48:
/usr/include/linux/bitmap.h: In function `bitmap_empty':
/usr/include/linux/bitmap.h:15: error: `BITS_PER_LONG' undeclared (first
use in this function)
[.....]
There must be something wrong with my linux/i2c.h...
# dpkg-query -S /usr/include/linux/i2c.h
linux-kernel-headers: /usr/include/linux/i2c.h
# dpkg-query -l linux-kernel-headers
linux-kernel-headers 2.5.999-test7-bk-17
/usr/include/linux/i2c.h:
/* $Id: i2c.h,v 1.68 2003/01/21 08:08:16 kmalkki Exp $ */
I tried to replace the two directories /usr/include/linux and
/usr/include /asm with symlinks to my actual kernel source, but I get
(more or less) the same errors.
What the hell is going wrong here?
Anyway, I committed Paul's patch. So be warned - CVS may not compile!
bye, Michael
--
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
|
|
From: Michael R. <re...@eu...> - 2005-04-05 04:46:52
|
> I've added two little utility functions to the mathematical plugin : > floor and ceil. It's useful when you don't want to be bothered by long > decimal numbers ... Commited. Thanks a lot! -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Paul K. <pau...@xs...> - 2005-04-04 20:50:25
|
Hi Xavier and the others, Sorry I wasn't more clear. I was talking about the i2c based display support. That is only support on kernel 2.6, i2c access is completely changed from kernel 2.4 to kernel 2.6. But i2c display support should automatically be disabled when the i2c kernel includes are not properly detected. So I am quite sure that it wouldn't prevent building L4L on kernel 2.4 (or even 2.2) There is just no i2c display support in that case. cheers, Paul > Hello Paul and the whole team. > >> One more thing pops up in my mind. On what kernel versions lcd4linux >> supposed to run? kernel 2.4 and 2.6, kernel revisions etc? >> I am sure that eg. the i2c support only works for the later revision of >> the 2.6 kernel. > Are you talking about i2c_sensors or the i2c display ? > About i2c_sensors, I wrote that plugin to be compatible with 2.4 > (procfs) and 2.6 (sysfs). As far as I know, there's no kernel version > needed for any plugin (at least higher than 2.4). I don't really know > the situation for drivers, but even for hd44780, ppdev (>=2.4) can be > avoided. So I don't think I'm wrong to think that L4L should even run on > a 2.2 kernel ! > > Bye ! > PS : As you can see, I'm not dead, just very busy. > > > |
|
From: Xavier V. <xav...@fr...> - 2005-04-04 19:52:16
|
Hello Paul and the whole team. > One more thing pops up in my mind. On what kernel versions lcd4linux > supposed to run? kernel 2.4 and 2.6, kernel revisions etc? > I am sure that eg. the i2c support only works for the later revision of > the 2.6 kernel. Are you talking about i2c_sensors or the i2c display ? About i2c_sensors, I wrote that plugin to be compatible with 2.4 (procfs) and 2.6 (sysfs). As far as I know, there's no kernel version needed for any plugin (at least higher than 2.4). I don't really know the situation for drivers, but even for hd44780, ppdev (>=2.4) can be avoided. So I don't think I'm wrong to think that L4L should even run on a 2.2 kernel ! Bye ! PS : As you can see, I'm not dead, just very busy. |
|
From: Luis.F.Correia <Lui...@se...> - 2005-04-04 16:11:25
|
Hi Paul! > -----Original Message----- > From: Paul Kamphuis [mailto:pau...@xs...] > Sent: Monday, April 04, 2005 5:02 PM > To: lcd4linux devel; Luis .F.Correia ; Michael Reinelt > Subject: fixes to the i2c patch that Luis supplied > > Hi, > > I created a patch file for the corrections I made to current > CVS tree to > make the i2c work properly. > I applied the following changes: > drv_generic_i2c.c > - store section in the open function > - made Section variable const to remove compiler warning > > configure.in > - modified the i2c verification/detection to correctly detect > and enable > i2c support > note: i2c support requires a 2.6 kernel and kernel headers > installed. I > assume this detection would be > sufficient for proper i2c enable/disable > > lcd4linux.conf.sample > - changed the model to 'generic' for the HD44780-I2C display (model > 'WRAP1C-PCF8574' is unknown?) :) this is my own personal model, it is quite innocous to lcd4linux since it is the only driver I have in my lcd4linux.conf, it works. > > This is the first patch file I ever created so I hope it is ok. > > Let me know if it works, > > Paul Looks good! Luis Correia |
|
From: Paul K. <pau...@xs...> - 2005-04-04 16:01:33
|
Hi, I created a patch file for the corrections I made to current CVS tree to make the i2c work properly. I applied the following changes: drv_generic_i2c.c - store section in the open function - made Section variable const to remove compiler warning configure.in - modified the i2c verification/detection to correctly detect and enable i2c support note: i2c support requires a 2.6 kernel and kernel headers installed. I assume this detection would be sufficient for proper i2c enable/disable lcd4linux.conf.sample - changed the model to 'generic' for the HD44780-I2C display (model 'WRAP1C-PCF8574' is unknown?) This is the first patch file I ever created so I hope it is ok. Let me know if it works, Paul |
|
From: Maxime P. <max...@bu...> - 2005-04-04 14:08:03
|
Hi,
I've added two little utility functions to the mathematical plugin :
floor and ceil. It's useful when you don't want to be bothered by long
decimal numbers ...
Here comes the patch :
diff -Naur lcd4linux-0.10.0-RC1-new/plugin_math.c lcd4linux-0.10.0-RC1/plug=
in_math.c
--- lcd4linux-0.10.0-RC1/plugin_math.c 2004-06-26 14:05:00.000000000 +0200
+++ lcd4linux-0.10.0-RC1-new/plugin_math.c 2005-04-04 16:02:10.2544510=
00 +0200
@@ -131,6 +131,17 @@
SetResult(&result, R_NUMBER, &value);=20
}
=20
+static void my_floor (RESULT *result, RESULT *arg)
+{
+ double value=3Dfloor(R2N(arg));
+ SetResult(&result, R_NUMBER, &value);
+}
+
+static void my_ceil (RESULT *result, RESULT *arg)
+{
+ double value=3Dceil(R2N(arg));
+ SetResult(&result, R_NUMBER, &value);
+}
=20
int plugin_init_math (void)
{
@@ -151,6 +162,10 @@
AddFunction ("min", 2, my_min);
AddFunction ("max", 2, my_max);
=20
+ /* floor, ceil */
+ AddFunction ("floor", 1, my_floor);
+ AddFunction ("ceil", 1, my_ceil);
+
return 0;
}
Regards,
- Sam
--=20
/ Maxime Petazzoni - <max...@bu...> - bulix.org |
| Zwe (zwe.bulix.org) - Gobelins : http://gobelins.nekeme.net |
| Gpg Id: 0x83E6AE0D - Jabber: sa...@ja... ________________/
|
|
From: Luis.F.Correia <Lui...@se...> - 2005-04-04 10:12:06
|
Hi all! > -----Original Message----- > From: Michael Reinelt [mailto:re...@eu...] > Sent: Monday, April 04, 2005 10:51 AM > To: lcd...@li... > Subject: Re: [Lcd4linux-devel] lcd4linux 0.10 release? > > Hi Paul, > > > Only one personal interest, the i2c support. :-) Did you get it > > compiling correctly? I only had one correction for Luis, > not sure if he > > reported it to you already. And I suggested a modification to > > configure.in to correctly enable/disable i2c support. > Well, I didn't follow your conversation too closely. Dod > someone checkin > something to CVS? Or could someone provide a patch? I was hoping to get the configure detection thing ready and stable before a commit. At this moment I can't test 2.4 kernels yet, but intend to do so this week. (which responds also to your other email) I don't want to break things now just to have i2c support plugged in. The changes to the drv_HD44780.c file, were integrated already, as the two new driver helper files. I did not commit the correction Paul provided yet, due to lack of time... (Paul, can you please send me a unified diff?) > You are right, i2c *is* important for 0.10. Either it should compile > cleanly on *any* client (even without kernel-headers, > kernel-source and > so on), or we shouuld deactivate it somehow. Well, i find it difficult to compile without kernel headers/source, as it will talk (more or less) with a /dev, which I'm not really sure if this is kernel or userspace access... Unless we can come up with some way to properly detect I2C presence in a reliable way. > > Besides that, looking at the ticket list, most show stopper > issues with > > RC1 are solved. Your latest plugin changes, worked smoothly > for me. No > > more confusing plugin messages for me. > Fine, thanks for your feedback! > > > I think you are ready for a release. > I personally think so, too. Any feedback from other developers and/or > users would be appreciated! > > > bye, Michael > > -- > Michael Reinelt <re...@eu...> > http://home.pages.at/reinelt > GPG-Key 0xDF13BA50 > ICQ #288386781 Luis Correia |
|
From: Michael R. <re...@eu...> - 2005-04-04 09:52:21
|
paul kamphuis wrote: > One more thing pops up in my mind. On what kernel versions lcd4linux > supposed to run? kernel 2.4 and 2.6, kernel revisions etc? > I am sure that eg. the i2c support only works for the later revision of > the 2.6 kernel. Good point! I can test 2.6 (2.6.11, to be precise) only. I don't have any other running kernel avaliable here. So if someone could do some testing with 2.4, this would be great! bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-04-04 09:51:06
|
Hi Paul, > Only one personal interest, the i2c support. :-) Did you get it > compiling correctly? I only had one correction for Luis, not sure if he > reported it to you already. And I suggested a modification to > configure.in to correctly enable/disable i2c support. Well, I didn't follow your conversation too closely. Dod someone checkin something to CVS? Or could someone provide a patch? You are right, i2c *is* important for 0.10. Either it should compile cleanly on *any* client (even without kernel-headers, kernel-source and so on), or we shouuld deactivate it somehow. > Besides that, looking at the ticket list, most show stopper issues with > RC1 are solved. Your latest plugin changes, worked smoothly for me. No > more confusing plugin messages for me. Fine, thanks for your feedback! > I think you are ready for a release. I personally think so, too. Any feedback from other developers and/or users would be appreciated! bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: paul k. <pau...@xs...> - 2005-04-04 09:40:52
|
One more thing pops up in my mind. On what kernel versions lcd4linux supposed to run? kernel 2.4 and 2.6, kernel revisions etc? I am sure that eg. the i2c support only works for the later revision of the 2.6 kernel. |
|
From: paul k. <pau...@xs...> - 2005-04-04 09:34:24
|
Only one personal interest, the i2c support. :-) Did you get it compiling correctly? I only had one correction for Luis, not sure if he reported it to you already. And I suggested a modification to configure.in to correctly enable/disable i2c support. Besides that, looking at the ticket list, most show stopper issues with RC1 are solved. Your latest plugin changes, worked smoothly for me. No more confusing plugin messages for me. I think you are ready for a release. Cheers, Paul Michael Reinelt wrote: >Hi Paul, > > > >>In January you released the 0.10 RC1 of lcd4linux. Can you give some >>information on what remains to be done prior to 0.10 release? >> >> > >Well, the docs in the wiki are finished, at least most of'em. So - there >is no real reason *not* to release 0.10. > >There are a lot of things planned - more displays, vents, scrolling, >keypad support, but these could be implemented after 0.10 > >Any comments? Otherwise we should release 0.10! > >bye, Michael > > > |
|
From: Michael R. <re...@eu...> - 2005-04-04 08:57:30
|
Hi Paul, > In January you released the 0.10 RC1 of lcd4linux. Can you give some > information on what remains to be done prior to 0.10 release? Well, the docs in the wiki are finished, at least most of'em. So - there is no real reason *not* to release 0.10. There are a lot of things planned - more displays, vents, scrolling, keypad support, but these could be implemented after 0.10 Any comments? Otherwise we should release 0.10! bye, Michael -- 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.
