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: andy b. <sku...@ho...> - 2004-06-10 12:26:29
|
thanks - I just checked it out again from cvs, and it's all working OK,
except the test widgets in lcd4linux.conf.sample should look like this:
Widget BarTest {
class 'Bar'
# test::bar(barno,maxval,startval,delta) - move a test value between 0 and
max.
# delta= step to change value by each time it's read.
# barno - ten different test bar values can be set up, with barno=0..9
# if delta=0, just returns the value of bar n instead of changing it.
expression test::bar(0,100,50,1)
expression2 test::bar(1,100,0,1)
length 10
max 100
direction 'E'
update 200
}
Widget BarTestVal {
class 'Text'
expression test::bar(0,100,50,0)
prefix 'Test '
width 9
update 200
}
Widget LightningTest {
class 'icon'
speed 500
visible test::onoff(0)
bitmap {
row1 '...***'
row2 '..***.'
row3 '.***..'
row4 '.****.'
row5 '..**..'
row6 '.**...'
row7 '**....'
row8 '*.....'
}
}
>From: Michael Reinelt <re...@eu...>
>To: andy baxter <sku...@ho...>
>CC: lcd4linux-devel <lcd...@li...>
>Subject: Re: test plugin code.
>Date: Mon, 07 Jun 2004 09:03:48 +0200
>
>Hi Andy, Hi List,
>
>
>andy baxter wrote:
>
>>I've included a file 'plugin_test.c'. An earlier version was
>>working OK, but
>>I've changed it since so you can have more than one test bar, and I
>>can't
>>work out how i got it working. I added lines to plugin.c,
>>configure.in, and
>>plugins.m4 and ran autoconf and automake, which compiled and linked
>>plugin_test, but it's saying it can't find the functions.
>
>I did add the plugin_test to plugin.c and Makefile.am. I did not add
>any with/without-handling, because I consider this to abe a 'basic'
>plugin (just like string, cfg, time, ...)
>
>Anyhow, I just checked it in, but did rename the functions to
>test::bartest() and test::onoff()
>
>>I've also included part of my lcd4linux.conf, with demos of how to
>>use the
>>test plugin, plus a 'rain' icon.
>Hey, I really like this 'rainy' icon! I added it to the
>lcd4linux.conf.sample, same for the debug widgets
>
>
>Here's a short description of the two test functions for other
>readers here:
>
>>static void my_bartest (RESULT *result, RESULT *rbar, RESULT *rmax,
>> RESULT *rstart, RESULT *rdelta)
>>// used for testing bars - keeps values for a series of 10 bars,
>>// which are incremented and decremented between 0 and rmax by
>>// amount rdelta every time they are read. Starting value is
>>rstart.
>>// rbar gives the number of the test bar.
>
>>static void my_onofftest (RESULT *result, RESULT *arg1)
>>// like above, but just switches a value between 1 and -1. Can use
>>to test
>>// visibility of icons.
>
>Funny, I needed such things since ever for testing bars. Why did
>such a plugin never come to my mind?
>
>
>bye, Michael
>
>--
>Michael Reinelt Tel: +43 676
>3079941
>Geisslergasse 4 Fax: +43 316
>692343
>A-8045 Graz, Austria e-mail:
>re...@eu...
_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger
http://www.msn.co.uk/messenger
|
|
From: Jerry S. <ye...@th...> - 2004-06-08 01:30:49
|
On Wed, Jun 02, 2004 at 07:19:02AM +0200, Michael Reinelt wrote: > Hi Jerry, > But I think I've already fixed this: I'm calling unlink() just before > the open() to remove the file if it exists. The open() is called with > the O_EXCL flag, which means it will fail if the file existed. As we've > unlinked it just before, this should never happen. If it happens, I emit > an error and abort. > > This looks secure enough to mee. Agreed. Failing out would prevent overwriting other files. Jerry -- Jerry Seutter Email: ye...@th... Web: http://www.thegeeks.net/~yello Gallery: www.thegeeks.net/~yello/gallery (email me for username and password). |
|
From: Michael R. <re...@eu...> - 2004-06-07 07:04:03
|
Hi Andy, Hi List, andy baxter wrote: > I've included a file 'plugin_test.c'. An earlier version was working OK, > but > I've changed it since so you can have more than one test bar, and I can't > work out how i got it working. I added lines to plugin.c, configure.in, and > plugins.m4 and ran autoconf and automake, which compiled and linked > plugin_test, but it's saying it can't find the functions. I did add the plugin_test to plugin.c and Makefile.am. I did not add any with/without-handling, because I consider this to abe a 'basic' plugin (just like string, cfg, time, ...) Anyhow, I just checked it in, but did rename the functions to test::bartest() and test::onoff() > I've also included part of my lcd4linux.conf, with demos of how to use the > test plugin, plus a 'rain' icon. Hey, I really like this 'rainy' icon! I added it to the lcd4linux.conf.sample, same for the debug widgets Here's a short description of the two test functions for other readers here: > static void my_bartest (RESULT *result, RESULT *rbar, RESULT *rmax, > RESULT *rstart, RESULT *rdelta) > // used for testing bars - keeps values for a series of 10 bars, > // which are incremented and decremented between 0 and rmax by > // amount rdelta every time they are read. Starting value is rstart. > // rbar gives the number of the test bar. > static void my_onofftest (RESULT *result, RESULT *arg1) > // like above, but just switches a value between 1 and -1. Can use to test > // visibility of icons. Funny, I needed such things since ever for testing bars. Why did such a plugin never come to my mind? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Michael R. <re...@eu...> - 2004-06-05 14:58:40
|
Hi Xavier, > I found the problem ! qprintf doesn't work with float ! Maybe you can > write support for %f in qprintf, but for the moment, we should put back > sprintf, patch included. applied, but with a change: I used snprintf() rather than sprintf. > PS: I dislike the fact to have *LCD4Linux* written on my LCD when L4L is > killed, I'd rather have a blanck screen. Conf option ? There is one, called "quiet", same as -q Works with startup splash screen, seems not to work with exit splash screen. I will fix this. bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Xavier V. <xav...@fr...> - 2004-06-05 12:31:52
|
> With your last commit, you broke plugin_i2c_sensors ! It seems like > qprintf doesn't work as expected. I'll try to work on it. I found the problem ! qprintf doesn't work with float ! Maybe you can write support for %f in qprintf, but for the moment, we should put back sprintf, patch included. PS: I dislike the fact to have *LCD4Linux* written on my LCD when L4L is killed, I'd rather have a blanck screen. Conf option ? Bye ! -- Xavier VELLO <xav...@fr...> |
|
From: Michael R. <re...@eu...> - 2004-06-05 09:27:20
|
Hi Xavier, >> With your last commit, you broke plugin_i2c_sensors ! It seems like >> qprintf doesn't work as expected. I'll try to work on it. > > Sorry. You're right, qprintf() does not support %f (float/double numbers). > > We could either replace with snprintf() or enhance qprintf() for floats. I just browsed through the manuals: There are these ecvt(), fcvt, gcvt() functions which convert a float/double into a string. But they are "not recommended", one should use sprintf() instead. So I won't rework qprintf(), it should be used for strings and integers only. We have to replace the call to qprintf() with snprintf in the i2c_sensors plugin. Xavier, will you, or shall I do so? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Michael R. <re...@eu...> - 2004-06-05 09:15:18
|
hI xAVIER, > With your last commit, you broke plugin_i2c_sensors ! It seems like > qprintf doesn't work as expected. I'll try to work on it. Sorry. You're right, qprintf() does not support %f (float/double numbers). We could either replace with snprintf() or enhance qprintf() for floats. bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Xavier V. <xav...@fr...> - 2004-06-05 09:01:12
|
Hello Michael ! With your last commit, you broke plugin_i2c_sensors ! It seems like qprintf doesn't work as expected. I'll try to work on it. Bye ! -- Xavier VELLO <xav...@fr...> |
|
From: Xavier V. <xav...@fr...> - 2004-06-02 19:06:39
|
Hi all ! You can use every valid XHTML1.1 syntax : > - Images Use <img ... />, I'll write a <image> wrapper to care about the path, but we'll make the transition later. > - Tables use the traditional <table>, <tr> and <td> stuff. No plan for another implementation. > - Navigation between displays There are indexes (HTML/drivers/index.html for example) to navigate between all the pages, and the <links/> tag in <head> to add a "See also" box for related pages/websites (see example.html). > As I'm very bad in writing XML or whatever this is called today, would > it be possible to 'port' one simple 'Display' section so I can use it as > a template? In fact, it's just XHTML1.1 syntax (there are bugs in the DTD that I'll fix later), so don't think XML, but HTML. I've done a lot of efforts to make the sources look like html pages (<head>, <body>, ...), please don't panic ;) Sorry, but I'm asking for a little vacancy of 2 weeks to pass my exams, I'll be back the 16th ;) Bye ! -- Xavier VELLO <xav...@fr...> |
|
From: Michael R. <re...@eu...> - 2004-06-02 06:07:09
|
Hi List, especially Xavier, I try to start the Display Driver documentation. If you look at the old 'Displays' section on the lcd4linux web page, you'll find several 'features' I don't know how to do with the new doc engine: - Images - Tables - Navigation between displays I want to show pictures here, for several reasons: First, its kind of 'advertising' or 'thanks' to companies who donated displays, second there are images that are documentation (think of the schematics from eagle) any hint? As I'm very bad in writing XML or whatever this is called today, would it be possible to 'port' one simple 'Display' section so I can use it as a template? Thanks, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Michael R. <re...@eu...> - 2004-06-02 05:30:22
|
Hi there, >>>Is it possible to create a "standard unix man page" out of this? >> >>>From my understanding, no. > > Right ! In fact, I'd prefer the html doc and the manpage not to be identical. > In fact, the manpage should just list the comandline options and point to > the html doc for the config. Moreover, I don't think we can generate manpages > with xslt (it may be possible to output docbook and them process it to > man, but it's not very clean). Okay, forget about the man page for now. >>>As a last step, we have to agree on who writes what parts of the >>>documentation. I think I should write the drivers section, because I >>>know most of them by heart :-) >> >>All right. You're nominated for writing driver documentation. I've >>been working on what basically is a "getting started" section. I'll >>also work on basic program usage. What other areas need documentation? > > I think I'll write the plugins section, as I know them well. Fine! >>>Xavier, you'll have to tell me what belongs into CVS, and what into a >>>distribution tarball. > > The data, drivers, dtd, lcd4linux, plugins and xsl folder and Makefile and > Makefile.generic are part of the build system. The HTML folder should never > be on the CVS, but in the tarballs. Check in done. > I don't know if we should include the whole build system in the releases or > just the compiled html ... Hmmm... Good question... Another point: how to include the documentation tree into the main Makefile? (automake!?!) bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Michael R. <re...@eu...> - 2004-06-02 05:19:10
|
Hi Jerry, > There are a few things you can try, each with their own limitations... > > 1. Use mkstemp() to create the filename. With a random filename, it > becomes much harder for a hacker to misuse the file. I don't know if or > how you can get the filename for the file created by mkstemp(). I don't want to create the file in the temp directory, but in the same dir as the output file (so that the following rename() call must not copy any data) > 2. Write the file to a directory owned by root. /tmp can be a bad place > for secure files because anyone can write to it. Then the rename > technique would work. That's not that easy, too: I want to write the file the user specifies with the -o option. But I think I've already fixed this: I'm calling unlink() just before the open() to remove the file if it exists. The open() is called with the O_EXCL flag, which means it will fail if the file existed. As we've unlinked it just before, this should never happen. If it happens, I emit an error and abort. This looks secure enough to mee. bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Xavier V. <xav...@fr...> - 2004-06-01 11:10:54
|
Hi Michael, Jerry and the others ! > > Hey! This look cool! I really like it! Great! Congratulations! Thanks ;) BTW, the CSS isn't finished. There are some glitches, especially with KHTML. > > Is it possible to create a "standard unix man page" out of this? > >From my understanding, no. Right ! In fact, I'd prefer the html doc and the manpage not to be identical. In fact, the manpage should just list the comandline options and point to the html doc for the config. Moreover, I don't think we can generate manpages with xslt (it may be possible to output docbook and them process it to man, but it's not very clean). > I'm okay with it. Xavier pointed out that man pages and html pages are > directed at different audiences, and I agree with him to a certain > degree. I think the driver documentation can be useful in both formats, > so I might look at hacking something together to make the driver docs > into part of a man page. Maybe an xsl to outpub docbook, but I don't think it would be useful nor coherent. Another solution would be to genrate plain text to be read with a terminal (this one is easy !) > > As a last step, we have to agree on who writes what parts of the > > documentation. I think I should write the drivers section, because I > > know most of them by heart :-) > All right. You're nominated for writing driver documentation. I've > been working on what basically is a "getting started" section. I'll > also work on basic program usage. What other areas need documentation? I think I'll write the plugins section, as I know them well. Another point : > > If this is okay with all of you, I'd like to add this stuff to the CVS. > > Xavier, you'll have to tell me what belongs into CVS, and what into a > > distribution tarball. The data, drivers, dtd, lcd4linux, plugins and xsl folder and Makefile and Makefile.generic are part of the build system. The HTML folder should never be on the CVS, but in the tarballs. I don't know if we should include the whole build system in the releases or just the compiled html ... Bye ! -- Xavier VELLO <xav...@fr...> |
|
From: Xavier V. <xav...@fr...> - 2004-06-01 11:10:44
|
Hello Sameer ! > Is there a debian version of lcd4linux? If so, where would I get it from? In fact, there's a "debian" folder in the CVS tree of Next Generation (which will be 0.10.0), but as we never released a "NextGen" version yet, there's no debian package. You can build one from the CVS sources if you want. Bye ! -- Xavier VELLO <xav...@fr...> |
|
From: Jerry S. <ye...@th...> - 2004-05-31 06:36:01
|
On Sat, May 29, 2004 at 06:00:30PM +0200, Michael Reinelt wrote: > Hi Xavier, Hi List, > > >>Can anyone tell me how to write documentation? I didn't follow these > >>discussions... > > > >You'll find in this tarball the documentation system. Read > >HTML/write_doc.html and HTML/test.html. > > Hey! This look cool! I really like it! Great! Congratulations! > > Is it possible to create a "standard unix man page" out of this? From my understanding, no. > What do the other guys think about it? I'm okay with it. Xavier pointed out that man pages and html pages are directed at different audiences, and I agree with him to a certain degree. I think the driver documentation can be useful in both formats, so I might look at hacking something together to make the driver docs into part of a man page. > As a last step, we have to agree on who writes what parts of the > documentation. I think I should write the drivers section, because I > know most of them by heart :-) All right. You're nominated for writing driver documentation. I've been working on what basically is a "getting started" section. I'll also work on basic program usage. What other areas need documentation? Jerry -- Jerry Seutter Email: ye...@th... Web: http://www.thegeeks.net/~yello Gallery: www.thegeeks.net/~yello/gallery (email me for username and password). |
|
From: Michael R. <re...@eu...> - 2004-05-31 06:08:12
|
Hi Andy, Hi List, > I found the bug - it looks like the display gets confused if you put 0xfe > escape characters inside a 'define char' sequence. I've added a loop which > AND's all the characters with 0x1f before sending them to the display. Funny, but I fixed a bug with Crystalfontz displays yesterday, which had exactly the same reason - bit 7 made a bar blinking. Thanks for debugging this one! > This has been checked in to cvs - hope that's OK. Ok, but I changed it a bit so it does not modify the passed buffer but copy it into a loxcal buffer. I modified all other drivers, too. > I also wrote a couple of plugin functions which are useful for testing - one > just increments and decrements a number between two limits every time you > call it, which is good for testing bars; Hey, that's a good idea! > another alternates one of a series > of numbers between -1 and +1, which i used for making icons visible and > invisible. I haven't checked these in because I'm having trouble adding the > plugin to the source tree properly - it was working on one machine, and then > not on the other, so I'll wait until this is sorted. You can send the to me, I'll add them. bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Jerry S. <ye...@th...> - 2004-05-31 06:01:43
|
On Tue, May 25, 2004 at 10:08:18PM +0200, Michael Reinelt wrote: > Hi there, > > I want lcd4linux not to contain any potential security holes. As we > don't have any networking, no client-server-model, no other fancy stuff, > this risc is quite low. But lcd4linux is running as root, and therefore > potentially dangerous. > > I'm worrying about a symlink security hole: The Image driver (was: > Raster) creates files, without checking if they exist. If a user places > a symlink, he may use lcd4linux to overwrite arbitrary files. Which I > consider not to be nice. > > The output file of the raster driver is passed with the '-o path/file' > option. To enshure that a potential reader always gets a complete file, > the image is first written to a temp file, which will be rename(2)'ed > afterwards. > > I see two problems here: > > 1. the temp file is opened with O_CREAT. If a symlink is already > present, it's target will be overwritten. Some security HOWTO's say one > should use O_CREAT|O_EXCL, which means that the call will fail if the > file already exists. OTOH, the open(2) man page states that thios > doesn't work over NFS :-( > > 2. the rename() will overwrite a symlink, too. > > > Anybody out there with the experience how to solve such issues? I didn't > find too much documentation out there, especially not for exactly the > cases we're dealing with here. There are a few things you can try, each with their own limitations... 1. Use mkstemp() to create the filename. With a random filename, it becomes much harder for a hacker to misuse the file. I don't know if or how you can get the filename for the file created by mkstemp(). 2. Write the file to a directory owned by root. /tmp can be a bad place for secure files because anyone can write to it. Then the rename technique would work. However, I think that your solution above is reasonable. It is pretty much assumed that if you want a secure setup you won't use NFS. Furthermore, it is not common practice to use NFS for /tmp. As far as using a symlink to subvert the rename operation, there really isn't anything you can do about that. It is a sysadmin issue. The program is run by root and shouldn't be writing to a directory that other users also have write access to. Jerry -- Jerry Seutter Email: ye...@th... Web: http://www.thegeeks.net/~yello Gallery: www.thegeeks.net/~yello/gallery (email me for username and password). |
|
From: Michael R. <re...@eu...> - 2004-05-31 05:43:44
|
Hi Sameer, > Is there a debian version of lcd4linux? If so, where would I get it from? At hte moment there's no ready-made debian package available. As soon as 0.10 is released, there will be one (At least I hope so :-) bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Sameer V. <sv...@sf...> - 2004-05-30 01:32:21
|
Is there a debian version of lcd4linux? If so, where would I get it from? -- Sameer |
|
From: Michael R. <re...@eu...> - 2004-05-29 16:00:38
|
Hi Xavier, Hi List, >>Can anyone tell me how to write documentation? I didn't follow these >>discussions... > > You'll find in this tarball the documentation system. Read > HTML/write_doc.html and HTML/test.html. Hey! This look cool! I really like it! Great! Congratulations! Is it possible to create a "standard unix man page" out of this? What do the other guys think about it? If this is okay with all of you, I'd like to add this stuff to the CVS. Xavier, you'll have to tell me what belongs into CVS, and what into a distribution tarball. I have to install these xmllint and xmlanything. As a last step, we have to agree on who writes what parts of the documentation. I think I should write the drivers section, because I know most of them by heart :-) bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Xavier V. <xav...@fr...> - 2004-05-29 15:18:08
|
Hello list ! First, sorry for the delay ! > Can anyone tell me how to write documentation? I didn't follow these > discussions... You'll find in this tarball the documentation system. Read HTML/write_doc.html and HTML/test.html. Bye ! -- Xavier VELLO <xav...@fr...> |
|
From: <An...@t-...> - 2004-05-29 12:21:08
|
>Hi Andreas, Hi List, Hi Michael,Hi Xavier, Hi List, =) >>>with kernel 2.6, /proc/stat does not contain a disk_io line anymore. >>>Looks like this info has moved to /proc/diskstat. >>>I have to write another plugin for this. >Done. COuld you please test this stuff? Have a look at >lcd4linux.conf.sample, you have to remove the stuff for 2.4 and activate >the new expressions for 2.6 I just changed the Disk-Widget like its in the sample config file like the scheme: proc_stat::disk. This works with 2.4 but still won't with 2.6. The Disk-Bar and Disk Numeric Widgets are the ones that didnt work as i can see. Did i miss something? To Xavier: The Busy-Bar works again with this change in config-file also with 2.6. Didnt realized the change, thanks for the tip - again. >bye, Michael bye, Andreas |
|
From: Michael R. <re...@eu...> - 2004-05-29 00:28:54
|
Hi Andreas, Hi List, >>with kernel 2.6, /proc/stat does not contain a disk_io line anymore. >>Looks like this info has moved to /proc/diskstat. >>I have to write another plugin for this. Done. COuld you please test this stuff? Have a look at lcd4linux.conf.sample, you have to remove the stuff for 2.4 and activate the new expressions for 2.6 bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Michael R. <re...@eu...> - 2004-05-28 14:53:56
|
Hi List, >>Can anyone tell me how to write documentation? I didn't follow these >>discussions... > Jerry answered: > Off the top of my head, I can't. I have just been writing plain text > for the moment, I write better that way. I'll be working on > formatting/markup hopefully next week. Hmm. What came to my mind is something like "embedded documentation", at least for all calls to cfg_get()/cfg_number(), and for all functions a plugin provides. This would be 1) clear text, and 2) always up-to-date with the code What do you think? Is there a "common format" for such things? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Michael R. <re...@eu...> - 2004-05-28 14:46:50
|
Hi Andreas, >>with kernel 2.6, /proc/stat does not contain a disk_io line anymore. >>Looks like this info has moved to /proc/diskstat. >> > > Ah, yes. I see. This just jumps in my eyes, after i upgraded. > Ive attached the output of the latest cvs. Maybe it is helpful? > It seems that cpu AND disk is broken - or maybe my config? > This is happen after a compile-run on a 2.6 Kernel. Well, you've been bitten by two things: First, the disapperaing infor from /proc/stat from Kernel 2.6, and second the function renaming: cpu() is now called proc_stat::cpu() (because it's a function from the proc_stat plugin). Take a look at the current lcd4linux.conf.sample... I changed the function names, because after 0.10 we will work on 'dynamic plugin loading', therefore the string before the double-colon has to match the plugin name. nevertheless, I've to change some plugins for kernel 2.6. This should be done before 0.10-RC1 bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
163 messages has been excluded from this view by a project administrator.
