lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] I can't actively work for l4l anymore by now

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

Hi Xavier,

> Hello everybody! You may have noticed I disappeared from sf for some
> time now. I'm sorry to inform you I'm in Toulouse since 09/01 and
> will only be back home last week of october; which explains I can't
> work for l4l actively. If you always plan on releasi

Somehow your mail has been cut off.

Anyway, that's bad news! But I'm looking forward to welcome you back in 
october/november.

Have a good time!


bye, Michael

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

[Lcd4linux-devel] I can't actively work for l4l anymore by now

[xavier66 <xav...@fr...>]

Hello everybody! You may have noticed I disappeared from sf for some time=
 now. I'm sorry to inform you I'm in Toulouse since 09/01 and will only b=
e back home last week of october; which explains I can't work for l4l act=
ively. If you always plan on releasi

RE: [Lcd4linux-devel] HD44780 changes

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

Hi! 

> -----Original Message-----
> From: Michael Reinelt [mailto:re...@eu...] 
> Sent: Saturday, September 18, 2004 10:54 AM
> To: lcd4linux-devel
> Subject: [Lcd4linux-devel] HD44780 changes
> 
> Hi List, especially Luis,
> 
> I just checked in a new version of drv_HD44780.c. I did some code 
> cleanups, and separated the parport specific stuff from the display 
> specific stuff, and already wrote a framework for other 
> 'busses'. There 
> is support for a keyword 'bus' in the display section of 
> lcd4linux.conf, 
> which can be 'parport (default) or 'i2c'. There are already skeleton 
> functions for I2C access.
> 
> So Luis can start filling these skeletion functions!
> 

I will, once I get back from vacations, that is on the 29th...
will look then what the changes are ;)

Thanks!

> But take care, I'm currently working on the HD44780 driver, too! So 
> update regularly!
> 
> The reason on my side is that I got a Nexcom 19" blade server 
> donated by 
> OpenSystems, which has a 16x2 display, and four keys.
> 
> Yes, keys! I'm working on keypad support for lcd4linux.
> 
> stay tuned!
> 
> -- 
> Michael Reinelt <re...@eu...>
> http://members.eunet.at/reinelt
> GPG-Key 0xDF13BA50
> ICQ #288386781
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your 
> judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Lcd4linux-devel mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
> 

[Lcd4linux-devel] HD44780 changes

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

Hi List, especially Luis,

I just checked in a new version of drv_HD44780.c. I did some code 
cleanups, and separated the parport specific stuff from the display 
specific stuff, and already wrote a framework for other 'busses'. There 
is support for a keyword 'bus' in the display section of lcd4linux.conf, 
which can be 'parport (default) or 'i2c'. There are already skeleton 
functions for I2C access.

So Luis can start filling these skeletion functions!

But take care, I'm currently working on the HD44780 driver, too! So 
update regularly!

The reason on my side is that I got a Nexcom 19" blade server donated by 
OpenSystems, which has a 16x2 display, and four keys.

Yes, keys! I'm working on keypad support for lcd4linux.

stay tuned!

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

RE: [Lcd4linux-devel] Hd44780 and I2C

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

Hi Michael!

> 
> Hi Luis,
> 
> nice to hear from you again!
> 
> Sorry for the delay, but, as always, I'm too busy...

No problem, we all have our priorities...

> > From the driver side, it will be working in userspace, using the
> > /dev/i2c-(0|1) access.
> This looks interesting! How fast is the i2c bus? From what 
> I've heard, 
> it's quite slow...

Don't know yet, but even if it is slow, I'll refrain myself of using
bars...

> The current HD44780 driver is a bit of a mess, but that's because the 
> different wirings and modes and stuff are a mess. This won't 
> get better 
> with a new backend (which nobody had in mind when writing the 
> driver. So 
> nobody is to blame. Especially not me :-)
I'm not blaming anyone, but if a redesign comes to be, you'll have for sure 
a loot to take in account...

> There should be some more levels of abstraction inside, to 
> encapsulate 
> the parport driver a bit. This abstraction could be used for the i2c 
> backend.

Ok, I'll follow Martin's steps and report back any success.

> As soon as you got your i2c backend working, just check it 
> in, and let 
> me know about the interface. I'll have a look at this 
> internal cleanup.
> 
> 
> bye, Michael

Thanks!

Luis Correia   
Bering uClibc Team Member

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

Re: [Lcd4linux-devel] Hd44780 and I2C

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

Hi Luis,

nice to hear from you again!

Sorry for the delay, but, as always, I'm too busy...

> I'm designing a simple I2C-to-4bit-HD44780 interface, to be able to have a
> LCD hooked up my PcEngines router board.
Sounds cool!

> From the driver side, it will be working in userspace, using the
> /dev/i2c-(0|1) access.
This looks interesting! How fast is the i2c bus? From what I've heard, 
it's quite slow...

> After having a good look into current CVS code and some conversations with
> Martin, I think the best approach is to have a drv_generic_i2c module as the
> backend, and extend the drv_HD44780 to make it possible to use this new
> backend.
Yes, correct. This would be the right approach.

> I could make it work using some sore of #ifdef constructs, but it does not
> seem to be the best way...
Shurely not. #ifdefs are very bad if you think of a binary distribution.

The current HD44780 driver is a bit of a mess, but that's because the 
different wirings and modes and stuff are a mess. This won't get better 
with a new backend (which nobody had in mind when writing the driver. So 
nobody is to blame. Especially not me :-)

There should be some more levels of abstraction inside, to encapsulate 
the parport driver a bit. This abstraction could be used for the i2c 
backend.

As soon as you got your i2c backend working, just check it in, and let 
me know about the interface. I'll have a look at this internal cleanup.


bye, Michael

-- 
Michael Reinelt                                         ICQ #288386781
e-mail: re...@eu...                          Tel: +43 676 3079941
Geisslergasse 4, A-8045 Graz, Austria          GPG/PGP-Key: 0xDF13BA50

[Lcd4linux-devel] Hd44780 and I2C

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

Hi!

I'm designing a simple I2C-to-4bit-HD44780 interface, to be able to have a
LCD hooked up my PcEngines router board.

The interface itself is just a PCF8574 8bit I/O extender for I2C. 
It has a 8 bit port which connects directly to the HD44780, using the same
4bit pinouts that Martin used in his GPIO driver for Soekris.

From the driver side, it will be working in userspace, using the
/dev/i2c-(0|1) access.

After having a good look into current CVS code and some conversations with
Martin, I think the best approach is to have a drv_generic_i2c module as the
backend, and extend the drv_HD44780 to make it possible to use this new
backend.

I could make it work using some sore of #ifdef constructs, but it does not
seem to be the best way...
Of course things could get tricky, and therefore I'm asking for your advice
on the best way to make this happen.

For now, all the low-level stuff is working, the needed modules are all
accounted for and my test programs make the LCD flicker.
(It isn't working yet, but that is a problem with some pullups are still
needed on the RS RW and EN lines. the PcEngines hardware works with 3.3v and
some voltage adaptation is needed)

Thanks, and I'll keep you guys posted on the results of my findings...

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

[Lcd4linux-devel] Re: HD44870 driver for routerboard

[RJoco <rj...@ma...>]

Hi Michael

> Just one thing: you rely on the fact that the backloisht state will be
> applied with the next LCD update. This is not that good, because if
> there's static content, and lcd4linux does a lot of double buffering,
> the next update may be delayed. Is it possible to update the backlight
> immediately?
Ok, added.

> Just in case you didn't know: you can test your backlight control by
> entering the "interactive mode" with "lcd4linux -i". Then you can call
> your new function by entering "LCD::backlight(1)" or
> "LCD::backlight(0)", and query the current setting with "LCD::backlight()"
I don't know it, i tested it now, intresting , now testing other plugins
with this. :-)


> Another thing: are you interested in a developer account at SourceForge?
> You could apply patches to your driver yourself... All I'd need is your
> sourceforge account name.
rjoco77
But first need some cvs lesson. :-)

> and, finally, me being curious: where are you from? I got two different
> email addresses, one ending in .hu (hungaria?), one .ro (romania?)
My first email was .hu , this is redirected allways to my nearby email
wich is changing.
I'm born and live in RO , my mother language is HU but because leve here i
need it to learn ro too, soo i know hu,ro and some english :)

bye, Joco.

[Lcd4linux-devel] Re: HD44870 driver for routerboard

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

Hi Joco,

>>Could you please thest the driver?
> 
> Tested and ok!
Great!

>>Another thing: the RouterBoard LCD Header is capable of controlling the
>>backlight, right? That's what the LCD_BACKLIGHT=0x0800 is about? At the
>>moment, you have the backlight hardcoded/hardwired to "on". You should
>>make this one configurable! Have a look at the BeckmannEgle driver how
>>to do so. The "initial" backlight state should be read from the config
>>file, and the driver should register a function which allows querying
>>and setting the backlight.
> 
> Added, here is the patch.
Great again, thanks! Patch applied an checked in!

I modified it so that the "default" (no "Backlight" entry in the config) 
is enabled (the call to cfg_number())

Just one thing: you rely on the fact that the backloisht state will be 
applied with the next LCD update. This is not that good, because if 
there's static content, and lcd4linux does a lot of double buffering, 
the next update may be delayed. Is it possible to update the backlight 
immediately?

Just in case you didn't know: you can test your backlight control by 
entering the "interactive mode" with "lcd4linux -i". Then you can call 
your new function by entering "LCD::backlight(1)" or 
"LCD::backlight(0)", and query the current setting with "LCD::backlight()"

Another thing: are you interested in a developer account at SourceForge? 
You could apply patches to your driver yourself... All I'd need is your 
sourceforge account name.

and, finally, me being curious: where are you from? I got two different 
email addresses, one ending in .hu (hungaria?), one .ro (romania?)

bye, Michael (trying to catch some sleep now, need to get up at 5:00 
tomorrow :-(

-- 
Michael Reinelt                                         ICQ #288386781
e-mail: re...@eu...                          Tel: +43 676 3079941
Geisslergasse 4, A-8045 Graz, Austria          GPG/PGP-Key: 0xDF13BA50

[Lcd4linux-devel] Re: HD44870 driver for routerboard

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

Hi Joco,

I'm CC'ing this to the list, as maybe other developers may be 
interested, too...

We should continue our discussion on the list!

First for the good news: I just added your driver to CVS and checked 
everything in! (Hey! something is going on with LCD4Linux again!)

Could you please thest the driver?

>>>I'm used network control(and only localhost) only for command leds because
>>>the port is write-only and can't control outside lcdprogram or
>>>rewerse,the lcd4l store the port status!
>>
>>I didn't really understand that part. Are there any leds? Maybe they
>>sould be implemented as GPO's...
> 
> Yes 4 leds, 2 green 2 red and unfortunatelly use the same port with lcd
> and more, its only write, i not implemented as GPO-s because i did't
> understand the GPO-s. :(
Ok, and after having a closer look into your driver, I think I 
understood your LED approach :-)

> If you explain i rewrite the code, the questios is:
>  -can define a timer for update? (maybe somebody want to be faster update
>     example if using for transfer, ide-leds etc, others maybe for
>     rarelly changed data)
>  -from where get the led status externally?
>  or we can add GPO control from socket!

GPO's are "general purpose outputs", which means there is one or more 
pins where one can connect a LED, a beeper, a relais, or something else.

LCD4Linux has had GPO support from the beginning (because my first 
display, a MatrixOrbital, had one such GPO output). The current CVS 
version lacks GPO support, because the internal framework is not yet 
present. This is another story for 0.10.1

At the moment I think GPO's will be implemented the following way: If a 
driver wants to provide one or more GPO's, it will register a function 
to the evaluator. This function may be called "GPO (num, state)", where 
num is the output number, and state may be 0 or 1 (if binary) or any 
other useful range (0..255, some display have an analog output, or a PWM 
output)

The GPO will never be adressed directly from lcd4linux, but from an 
event handler specified in the config file (you remember, events is 
another thing for 0.10.1), There maybe events triggered by a keypad, 
triggered by some sort of "sensors" (not shure about this one), and, of 
course, timer events. This timer event may have a configurable 
frequency, which answers your question #1. The handler for this event 
would call the GPO() function, with the "state" gathered from any of the 
functions lcd4linux provides.

There will be no special "socket interface" for GPO's, but maybe a more 
general plugin for sockets, so one can use a socket as a data source for 
everything, not only GPO's.

You should probably modify your driver, throw away all the socket and 
LED stuff, but keep the RP_Leds variable (maybe rename it to "GPO" or 
something just like in the other drivers). As soon as GPO support will 
be there, I will browse through all drivers and add the GPO plugin.


Another thing: the RouterBoard LCD Header is capable of controlling the 
backlight, right? That's what the LCD_BACKLIGHT=0x0800 is about? At the 
moment, you have the backlight hardcoded/hardwired to "on". You should 
make this one configurable! Have a look at the BeckmannEgle driver how 
to do so. The "initial" backlight state should be read from the config 
file, and the driver should register a function which allows querying 
and setting the backlight.


Thanks a lot for your contribution!


bye, Michael


-- 
Michael Reinelt                                         ICQ #288386781
e-mail: re...@eu...                          Tel: +43 676 3079941
Geisslergasse 4, A-8045 Graz, Austria          GPG/PGP-Key: 0xDF13BA50

Re: [Lcd4linux-devel] plugin_i2c-sensors, DT_DIR, uClibc

[Xavier V. <xav...@fr...>]

>I read on internet the DT_ -s not implemented on uclib have problems
>others with this,do you try it the sample what i sed if working on glibc
>sytems, you can make autoconfigure setup to select this if detect uclibc?
>  
>
In fact, it should be easy to select your code at compile-time with a 
WITH_UCLIB flag. I say this flag in 0.9.x, but it isn't in 0.10. Who's 
the ****** who rewrite the compile system ?? Oh, it's me :p
I have to find a way to guess which of glib/uclib is used in configure 
(or while compiling, via a flag set by a header).

>Where are the guy with wirtual rows????
>  
>
Virtual rows will be implemented in 0.10.1, but 0.10.0 isn't already 
released :p In fact, summer didn't motivate us to write doc !

>The 0.9.x worked fine but has no time callback function to driver what i
>ned it, now my driwer is ok and everithing is fine only the wirtual row is
>missing :(
>  
>
Just wait a little ;)

>And guys i have to propose, ewery time when you write a new plugin please
>add a new example on lcd4linux.conf and unselect it with # , in this mode
>no problem if documentation is missing, now i need it to read every plugin
>how its working what parameters using etc. Thanks for understanding.
>
I've written a framework to easilly write documentation for new 
plugins/drivers, but no one loves to write doc :/
About the examples in lcd4linux.conf, there are already quite a lot. Are 
some plugins missing ? Maybe mine I think :D

Re: [Lcd4linux-devel] plugin_i2c-sensors, DT_DIR, uClibc

[RJoco <rj...@ma...>]

 Hi Xavier !

I read on internet the DT_ -s not implemented on uclib have problems
others with this,do you try it the sample what i sed if working on glibc
sytems, you can make autoconfigure setup to select this if detect uclibc?
Where are the guy with wirtual rows????
Or how it's working the rows displaying,i'm confused with widgets and so
many callback functions :(
The 0.9.x worked fine but has no time callback function to driver what i
ned it, now my driwer is ok and everithing is fine only the wirtual row is
missing :(
And guys i have to propose, ewery time when you write a new plugin please
add a new example on lcd4linux.conf and unselect it with # , in this mode
no problem if documentation is missing, now i need it to read every plugin
how its working what parameters using etc. Thanks for understanding.


Thanks,
Joco.

Re: [Lcd4linux-devel] plugin_i2c-sensors, DT_DIR, uClibc

[Xavier V. <xav...@fr...>]

Hi Luis !

>I have just read that you were the developper of the i2c_sensors plugins.
>I suppose that for your plugin to work, one must have the lm_sensors
>packages installed, right?
>I have a PcEngines hardware that has a LM77 sensor, placed on the i2c bus.
>But I have not that many info on how to read it, just a DOS example.
>
In fact, you must have the lm_sensors modules compiled for your 
hardware. The situation is alot better with linux 2.6 than 2.4 because 
the lm_sensors are right into the kernel tree by now (in the "char 
devices" section I think)
You have to find the good driver for your i2c bus (i2c-isa works in most 
situations, but if there's a better driver, use it) and for your chip 
(maybe one of lm*, but there's no lm77 which must be handled by one of 
the other lm* drivers).

You'll find more information at http://secure.netroedge.com/~lm78/

When you've loaded the good drivers, you should see your sensors in 
/sys/bus/i2c/devices/* (in 2.6) or /proc/something_I_don't_recall/ (if 
you have a 2.4 kernel and i2c-proc loaded).

Bye !

Re: [Lcd4linux-devel] plugin_i2c-sensors, DT_DIR, uClibc

[RJoco <rj...@ma...>]

Hello,

explaining detailed:
.....
 while((dir = readdir(fd1)) {
 debug("Searching for dir %s dir info: %X", dir->name, dir->d_type);
 /*Skip non-directories and '.' and '..' */
 if(( dir->d_type!=DT_DIR && .....
....

when running have:
 Searching for dir sensors dir info: 0
 Searching for dir lm87-i2c-1-2e dir info: 0

lm87-i2c-1-2e is a dir!!!

So resolved in this mode:
.......
 while((dir = readdir(fd1)) {

 struct stat info;
 if (strcmp ( dir->s_name, "." )==0 || strcmp(dir->s_name,"..")==0)
continue;
 strcpy(dname,base);
 strcat(dname,dir->d_name);
 lstat(dname,&info);
 if( !(info.st_mode&S_IFDIR) && !(info.st_mode&S_IFLNK)) continue;
 strcat(dname,"/");
.....


Best regards,
Joco.

> Hello joco
>
> >Somebody know why readdir not set DT_-s?, i'm usning uClibc.
> >Added debug("%X",dir->d_type) and i have always 0 , maybe uclibc bug, or
> >not implemented feature?
> >
> >
> I'm the developper of the i2c_sensors plugins, but I really don't
> understand. I think this is a bug in uClibc.
> Can you elaborate a little more so that I can understand ?
>
> Bye !
> ---
> Xavier VELLO (xav...@fr...)
>

Re: [Lcd4linux-devel] plugin_i2c-sensors, DT_DIR, uClibc

[Xavier V. <xav...@fr...>]

Hello joco

>Somebody know why readdir not set DT_-s?, i'm usning uClibc.
>Added debug("%X",dir->d_type) and i have always 0 , maybe uclibc bug, or
>not implemented feature?
>  
>
I'm the developper of the i2c_sensors plugins, but I really don't 
understand. I think this is a bug in uClibc.
Can you elaborate a little more so that I can understand ?

Bye !
---
Xavier VELLO (xav...@fr...)

[Lcd4linux-devel] plugin_i2c-sensors, DT_DIR, uClibc

[<rj...@ma...>]

Hi,

Somebody know why readdir not set DT_-s?, i'm usning uClibc.
Added debug("%X",dir->d_type) and i have always 0 , maybe uclibc bug, or
not implemented feature?


Best regards,
Joco.

Re: [Lcd4linux-devel] How to do an asynchronous plugin

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

Hi Javi,

> First I want to do is to turn them to run asynchronous, but I really
> have no idea about how to do it.
Async would be great. In fact, it's necessary here...

> If I do a fork inside the pluging...
YOu don't use fork() directly, but some helper functions provided by
thread.[ch] Here you'll find functions to pass values between the
processes, too.

> how can I do to read from de parent process values that are written
> by the child process, but without waiting for the child to end? Is
> there a way to child writes a value ("global variable"?) and the
 > parent  reads it's from a "shared memory"?

you have to create a mutex for every value you want to pass,
mutex_lock() it before reading and writing, and mutex_unlock() it
afterwards.

The value itself must be a shared memory segment created with shm_create()

The child process itself is created with thread_create().

Take a look at plugin_exec.c, it uses exactly this technique.

If you have any questions, feel free to ask.


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [Lcd4linux-devel] How to do an asynchronous plugin

[Xavier V. <xav...@fr...>]

Hi Javi, hi list !

> First I want to do is to turn them to run asynchronous, but I really have no idea about how to do it.
> If I do a fork inside the pluging...
>  how can I do to read from de parent process values that are written by the child process, but without waiting for the child to end?
> Is there a way to child writes a value ("global variable"?) and the parent  reads it's from a "shared memory"?

You should read plugin_exec.c and driver_x11.c I think.

Bye !
-- 
Xavier VELLO <xav...@fr...>

[Lcd4linux-devel] How to do an asynchronous plugin

[Javi <ja...@gs...>]

Hi List.

I'll finish my exams next Friday, so I'll continue the development of the MySQL and POP3 plugings.

First I want to do is to turn them to run asynchronous, but I really have no idea about how to do it.
If I do a fork inside the pluging...
 how can I do to read from de parent process values that are written by the child process, but without waiting for the child to end?
Is there a way to child writes a value ("global variable"?) and the parent  reads it's from a "shared memory"?

It's going to be the 1st time I program forks/wait stuff, any help is welcome.

Regards.

Javi.

[Lcd4linux-devel] Documentation framework updated

[Xavier V. <xav...@fr...>]

Hello to all documentation writers !

I've reworked the DTDs so that xsltproc generates valid XHTML 1.0 Strict
pages (and it should be XHTML 1.1 valid). I've introduced another
helper : <intro> to add an introduction text, and reworked the <index>
helper and the CSS. Moreover, the xsltproc output is passed through
xmllint to indent it and write a good-looking html, not the uggly things
it used to trow. And little bonus, the h* are numbered !!
I've updated write_doc.xml according to the new helper and started
hd44780 (even if it isn't in the archive).

BTW: Jerry, have you started writing ? I think this will be alot harder
to write the doc than the corresponding code :/ Doc writing is not very
exciting.

Last but not least, here's a list of allowed "toplevel" elements, as
XHTML-strict is quite, ... strict about this ;)
intro, h2, h3, h4, p, index, div, warn, note, cmd, conf, ul
You must put your text in <p></p>, but the div/warn/note/cmd/conf must
be a "toplevel", that's what XHTML wants.

Bye !
-- 
Xavier VELLO <xav...@fr...>
	

[Lcd4linux-devel] performance improvement

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

Hi ther,

I just finished the new hash model, and adoptet plugin_netdev to it.

On my AMD Athlon XP 1900 lcd4linux used to run with 17% CPU load 
(because of many disks and many network adatpters, especially 4 TUN 
devices), with the new version the load is between 1 and 2 %.

This is great, I think!

Please note that I changed the syntax of the netdev() function: It now 
needs three parameters:

netdev(device, parameter, delay)

device = e.g. 'eth0' (or 'eth.*')
parameter = e.g. 'Rx_bytes'

the plugin reads the /proc/net/dev file, and uses the header values for 
possible parameters, and prefixes them with either Rx_ or Tx_


Have fun,
           Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

[Lcd4linux-devel] improved hash handling

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

Hi there,

We do have some performance issues with the current lcd4linux, 
especially the netdev and diskstats plugin.

The reason is that both plugins read a lot of values (there are many 
lines in these two proc files, every line with many columns). The 
plugins used to split every line into peaces, calling hash_set (or even 
worse: hash_set_delta) for every value. However, most of the values were 
never used....

I rewrote the hash handling to solve this issues. The result has been 
just checked in. Please try to test some (or all) of the plugins, if 
they still work.

Some implementation details:

- new function 'hash_create(&HASH)': initializes a hash table
- new function 'hash_set_column()': allows you to specifiy column headers
- new function 'hash_set_delimiter()': allows you to specify column 
delimiting chars
- hash_set() and hash_set_delta() have been renamed to hash_put()
- hash_age() lost its 3rd parameter (as it has never been used)

The new handling allows you to go old-style, by using hash_put() and 
hash_get_delta, with a 'column' parameter of NULL.

If you want to save cpu cycles, you would no longer split a line into 
pieces and call hash_put() for every value, but save the line as a whole 
with one hash_put() call. Beforehand, you should specify column headers 
(or column names) and  the delimiting characters. After that, you can 
use hash_get() or hash_get_delta() with a column name as a parameter, 
and the hash subsystem will extract only this needed value from the line.

Take a look at plugin_diskstats(), where the new handling is used. 
plugin_netdev has been modified so it compiles cleanly, but has not been 
switched to the new time-saving handling.


Have fun,
            Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [Lcd4linux-devel] Advertisement for L4L ?

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

Hi Xavier,

> I've browsed the web to destress a little (tomorrow, it's the last day
> of my exams, biology plus spanish !),

Good luck!

  and I've realized that lcd4linux
> wasn't advertised out of SF. It isn't even in freashmeat,

Ah, and what's this: http://freshmeat.net/projects/lcd4linux ?

> and the only
> new in linuxfr (aka trollfr, a french friend of /.) was a journal I
> posted a week ago to find help for the doc :/
> 
> So I created an account on freashmeat and I'm ready to submit the
> project when you're ready to release
> TheBestEverSeenBugFreeNextGeneration, aka 0.10 ;)
I will do so. I announced the last two or three releases on freshmeat.


> Have you wrote documentation you and Jerry ? Sorry for the absence, I'll
> begin to write doc this WE !

Didn't find the time. At the moment I'm rewriting the hash handling, 
because lcd4linux eats up to 10% CPU on my Athlon XP1900. That's a bit 
too much :-(

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

[Lcd4linux-devel] Advertisement for L4L ?

[Xavier V. <xav...@fr...>]

Hello list, especially Michael.

I've browsed the web to destress a little (tomorrow, it's the last day
of my exams, biology plus spanish !), and I've realized that lcd4linux
wasn't advertised out of SF. It isn't even in freashmeat, and the only
new in linuxfr (aka trollfr, a french friend of /.) was a journal I
posted a week ago to find help for the doc :/

So I created an account on freashmeat and I'm ready to submit the
project when you're ready to release
TheBestEverSeenBugFreeNextGeneration, aka 0.10 ;)
Have you wrote documentation you and Jerry ? Sorry for the absence, I'll
begin to write doc this WE !

Bye !
-- 
Xavier VELLO <xav...@fr...>

PS: never tell me good luck for my exams, luck is for weak persons :p

Re: [Lcd4linux-devel] Re: test plugin code.

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

Hi Andy,

> 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:

Thanks, just checked in.

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...