lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] HELP! CVS problems

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

Michael :

For sending the mail, if you have exim and mutt, the script will be :
#!/bin/sh
cd /home/michael/cvs-diff
rm -rf lcd4linux.old patch.bz2
mv lcd4linux lcd4linux.old
CVS CHECKOUT
diff -u lcd4linux.old lcd4linux > patch
bzip2 patch
echo " " | mutt -a patch.bz2 -s "lcd4linux cvs patch" xav...@fr...

For the checkout, you can make the checkout with your account, or I can
send you my pass. With ssh and a certificate, cvs won't ask for a
password.


Bye !

Re: [Lcd4linux-devel] HELP! CVS problems

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

> So I'm asking the list: anyone has some ideas? Can anyone provide such a 
> script? I've got a server which is running and online 24h via ADSL, so 
> running a cron job every night or so should be no problem for me.
I thinked about a script which keeps yesterday's checkout in
'lcd4linux.old', retrieves today's in 'lcd4linux', then make a patch
'diff -u lcd4linux lcd4linux.old > patch' and bzip it.

Is it possible to do a checkout without asking for password (on my
account or as anonymous) ? Then it would be easy to do :


#!/bin/sh
cd /home/michael/cvs-diff
rm -rf lcd4linux.old patch.bz2
mv lcd4linux lcd4linux.old
CVS CHECKOUT
diff -u lcd4linux.old lcd4linux > patch
bzip2 patch
MAIL IT.

Is there a simple command to send an attached file by mail ?

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

[Lcd4linux-devel] HELP! CVS problems

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

Hi Xavier, Hi List,


>>as I'm working on /proc/cpuinfo and /proc/meminfo parsing, could you 
>>please send me these two files from Kernel 2.6?
> 
> Here they are !

Thanks a lot!
The format did not change very much. There are some new fields, and some 
are gone, but that's no problem with my plugin, because its independant 
from the field names.

As for the meminfo, there are three header lines missing. This is good 
and bad. good, because I had to skip them. Bad, because I may not skip 
them with 2.6. I hate it...

> By the way, I tried cvs via my 9.6k connection, it's technically
> impossible ! I tried checking out multiple projects, on multiple
> servers, via ssh, rsh or anonymous, it can't even login within 10
> minutes ! I'm sorry I can't do daily cvs checkout :/

Bad. Very bad.

> But I would really like to keep in sync with the "bleeding edge"
> lcd4linux, can you think of sending me daily patches of changes to the
> CVS ? It's possible to write a small script to automate it all.

I want you to stay in sync, too. But I have no idea how to achieve this. 
I checked the docs on sourceforge, the only thing I found is the 
"nightly CVS tarball", but this is a tar.bz2 from the _complete_ 
Repository. I did not check, but this may be far too big for you.


So I'm asking the list: anyone has some ideas? Can anyone provide such a 
script? I've got a server which is running and online 24h via ADSL, so 
running a cron job every night or so should be no problem for me.


TIA, Michael

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

Re: [Lcd4linux-devel] Dynamic loading of drivers / plugins ?

[<Mar...@t-...>]

On Wed, 14 Jan 2004 11:05:59 +0100
Michael Reinelt <re...@eu...> wrote:

> [hashes]

> Sorry. Marksu, are you listening? Are you subscribed to lcd4linux-devel?
 
Yes.  

> The reason for hashes is the following:
> 
> Say you write a plugin which returns values from /proc/cpuinfo. There 
> are values like "CPU MHz" or "BogoMips". You get these values by reading 
> and parsing /proc/cpuinfo.
> 
> Now if the plugin is asked for "MHz", it doesn't know that a few 
> microseconds later a call for "BogoMips" will happen. Therefore for 
> every call, the whole file would be parsed.
> 
> If you use a hash, you fill up the hash with all values from 
> /proc/cpuinfo when parsing it. Subsequent calls would not parse the file 
> again, but read the values from the hash.
> 
> You have to use something like a "timeout", and remember the time when 
> the contents of the file was last read. If the timeout is over, you have 
> to read and parse the file again.
> 
> SOme file change very seldom (/proc/cpuinfo probably changes never), 
> others change quite regular. But you can save a lot of CPU if you define 
> a timeout of, say, 100 msec.
> 
Great Michael! I will check out the CVS today.
Maybe that tommorow the XMMS-Plugin will use the HASH Function.
I will work on it.

Markus Keil

------
Saxony, Germany

Re: [Lcd4linux-devel] Dynamic loading of drivers / plugins ?

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

Hi Xavier,

[hashes]
> I didn't wrote the XMMS plugin ! It was done by Markus Keil.

Sorry. Marksu, are you listening? Are you subscribed to lcd4linux-devel?


> So it  
>  means a function can store data within a hash, which is used by the
>   evaluator, am I right ? There should be some way to call periodicaly
>  a plugin so it refreshes the info.

The hashes have nothing to do with the evaluator.
> I wonder if this model won't be more memory and CPU using that calling
> bare functions. Maybe it would be used for "static" informations (like
> cpuinfo or uname), but I don't think it'd be used for pooling plugins,
> IMHO.

The reason for hashes is the following:

Say you write a plugin which returns values from /proc/cpuinfo. There 
are values like "CPU MHz" or "BogoMips". You get these values by reading 
and parsing /proc/cpuinfo.

Now if the plugin is asked for "MHz", it doesn't know that a few 
microseconds later a call for "BogoMips" will happen. Therefore for 
every call, the whole file would be parsed.

If you use a hash, you fill up the hash with all values from 
/proc/cpuinfo when parsing it. Subsequent calls would not parse the file 
again, but read the values from the hash.

You have to use something like a "timeout", and remember the time when 
the contents of the file was last read. If the timeout is over, you have 
to read and parse the file again.

SOme file change very seldom (/proc/cpuinfo probably changes never), 
others change quite regular. But you can save a lot of CPU if you define 
a timeout of, say, 100 msec.


> I was thinking about a compiletime-generated hash asociating plugins and
> the functions/drivers it provides, for example :

would be a possibility, too. But I'm afraid this would complicate the 
whole autotools stuff even more.

> In this way, the lcd4linux binary always know about which displays it
> can drive (and which .so to load for them) and 'lcd4linux -l' can
> esailly list the displays it support

But it doesn't know which models are supported by a particular driver. 
This info is known to the driver only. There may be drivers which 
support a lot of different models (MatrixOrbital for example), or with 
no models at all (or one Model named "any"), as the HD44780.

> For the plugins, it's a different approach : the evaluator doesn't know
> any function (except the ones defined in eval.c, and maybe plugin_math.c
> and plugin_string.c) but just a hash. If an undefined function is
> called, the eval can browse the hash for the function and if it is
> provided by a plugin, it can load it.

Hmm. I don't like this approach. The new structure will allow the use ov 
"events". Such an event can happen any time, maybe long after lcd4linux 
was started. If such an event requires a function which cannot be 
loaded, an error would occur. And you'll have no chance to test if all 
plugins and expressions are right.

> Someone may think it'll introduce a speed down, but this search is done
> only in the first loop, then it's like if nothing was changed. It may
> slowdown a bit interactive mode (but it's just intended for testing,
> isn't it ?)

Anyway, lets keep this ideas in mind, but try to get the "static" 
lcd4linux up and running first!

I made lots of progress lately. Tomorrow morning I even had my first 
marquee-like text field on my MatrixOrbital!

Stay tuned!

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] Dynamic loading of drivers / plugins ?

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

> btw, I just added some "hash" utility functions, they work similar to 
> the 'associative arrays' from perl. You can use them to store 
> information gathered from various /proc files (I'm pointing at your xmms 
> plugin). Take a look at plugin_cpuinfo.c, which parses /proc/cpuinfo, 
> and you get an idea of how this could be done.

I didn't wrote the XMMS plugin ! It was done by Markus Keil. So it  
 means a function can store data within a hash, which is used by the
  evaluator, am I right ? There should be some way to call periodicaly
 a plugin so it refreshes the info.
I wonder if this model won't be more memory and CPU using that calling
bare functions. Maybe it would be used for "static" informations (like
cpuinfo or uname), but I don't think it'd be used for pooling plugins,
IMHO.


> As I'm not familiar with dlopen() and friends, maybe someone out there 
> wants to take a look at that?
Sorry, I won't be very much help for this point :/

> That's right. But what about 'lcd4linux -l', which should list all 
> drivers and models? :-(
> With plugins, I could think of loading all plugins which can be found in 
> a directory, becausae they follow the naming scheme "plugin_*.so". The 
> same technique could probably be used for the "list all drivers problem"

I was thinking about a compiletime-generated hash asociating plugins and
the functions/drivers it provides, for example :

drivers {
"MatrixOrbital.so" -> "MatrixOrbital"
"xyz.so" -> "displayxyz"
}

and

plugins {
"i2c_sensors.so" -> "i2c_sensors()"
"math.so" -> "sqrt, exp, ln, log, sin, cos, tan, min, max"
...
}

In this way, the lcd4linux binary always know about which displays it
can drive (and which .so to load for them) and 'lcd4linux -l' can
esailly list the displays it support

For the plugins, it's a different approach : the evaluator doesn't know
any function (except the ones defined in eval.c, and maybe plugin_math.c
and plugin_string.c) but just a hash. If an undefined function is
called, the eval can browse the hash for the function and if it is
provided by a plugin, it can load it.
Someone may think it'll introduce a speed down, but this search is done
only in the first loop, then it's like if nothing was changed. It may
slowdown a bit interactive mode (but it's just intended for testing,
isn't it ?)

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

PS: I'm on the lcd4linux-devel ML, so please Michael reply directly to
the ML (my GSM dislikes double posts ;)

PS #2: For the hashes, it's in Perl syntax, I don't know how hashes work in C ;)

PS #3: We may use this tree model :
/usr/lib/lcd4linux/---model/---matrixorbital.so                    
|        \-cwlinuz.so                     |                    
\-plugin/---math.so                               \-i2c_sensors.so and
forget the drv_ and plugin_ prefix for .so, moreover, CAPITALS are
deprecated, so it would be matrixorbital.so and NOT MatrixOrbital.so

Re: [Lcd4linux-devel] Dynamic loading of drivers / plugins ?

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

Hi Xavier,

> I checked out the CVS from another machine with decent adsl internet
> acces, cfg_get() seems to work now. plugin_i2c_sensors will be soon
> finished ;)

Fine! But do a CVS checkout again, and regularly, because I'm changing a 
lot at the moment (which is bad for you and your GSM, but good for 
lcd4linux :-)

btw, I just added some "hash" utility functions, they work similar to 
the 'associative arrays' from perl. You can use them to store 
information gathered from various /proc files (I'm pointing at your xmms 
plugin). Take a look at plugin_cpuinfo.c, which parses /proc/cpuinfo, 
and you get an idea of how this could be done.

> I saw you're beginning a rewrite of LCDs drivers at the same time of
> plugins. One suggestion : shouldn't we think about so-ing all these
> plugins and drivers (and place them in /usr/lib/lcd4linux) so that
> lcd4linux can load only the driver(s) and plugins that are used, so it
> can consume a lot less memory ! Furthermore, with the debian packages,
> we shouldn't rely on compile-time options (dvb, X11, ...).

This is a very good idea! This came to my mind some months ago, but I 
forgot about it.

As I'm not familiar with dlopen() and friends, maybe someone out there 
wants to take a look at that?

> Automatic loading of LCDs driver will be somewhat easy to do as it's
> specified in the config file. I would be fast to implement.

That's right. But what about 'lcd4linux -l', which should list all 
drivers and models? :-(

> The case of plugins can be more problematic : how can the evaluator
> guess which .so it has to load, maybe an internal tree of functions
> provided by plugins asociated with a scan of functions evaluated. If the
> evaluator doesn't know a function it scans in the tree for the plugin
> providing this function. It won't produce a speed-down as the necessary
> plugins are loaded at the first loop (in the case of the config file,
> not interactive mode) and will permit IMHO more flexibility and consume
> less memory.

With plugins, I could think of loading all plugins which can be found in 
a directory, becausae they follow the naming scheme "plugin_*.so". The 
same technique could probably be used for the "list all drivers problem"


bye, Michael

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

[Lcd4linux-devel] Dynamic loading of drivers / plugins ?

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

Hello Michael and all the fantastics lcd4linux contributors ;) !

I checked out the CVS from another machine with decent adsl internet
acces, cfg_get() seems to work now. plugin_i2c_sensors will be soon
finished ;)

I saw you're beginning a rewrite of LCDs drivers at the same time of
plugins. One suggestion : shouldn't we think about so-ing all these
plugins and drivers (and place them in /usr/lib/lcd4linux) so that
lcd4linux can load only the driver(s) and plugins that are used, so it
can consume a lot less memory ! Furthermore, with the debian packages,
we shouldn't rely on compile-time options (dvb, X11, ...).

Automatic loading of LCDs driver will be somewhat easy to do as it's
specified in the config file. I would be fast to implement.

The case of plugins can be more problematic : how can the evaluator
guess which .so it has to load, maybe an internal tree of functions
provided by plugins asociated with a scan of functions evaluated. If the
evaluator doesn't know a function it scans in the tree for the plugin
providing this function. It won't produce a speed-down as the necessary
plugins are loaded at the first loop (in the case of the config file,
not interactive mode) and will permit IMHO more flexibility and consume
less memory.

In think you know a little about external libraries as the binary uses a
liblcd4linux library, about me, I don't think I'll be able to help much
as I'm very lame at C coding ;)


What about it ? Please consider it, talk about it, enjoy ;)

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

[Lcd4linux-devel] Switch to new architecture

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

It has happened: I decided to start with the new driver architecture, 
which will use the Evaluator, and will support widgets.

I've been worrying for a long time how to start, and I had some other 
wishes which I didn't know how to do: for example, how to get a better 
naming convention into the source files (I want to keep them in one 
directory as long as possible). Anybode has an idea how to rename files 
when using CVS?

Now I'm goint the following way: I will introduce some new files, while 
keeping the old ones up and running. As far as the new architecture has 
at least the same level of functionality as the old one, I will start to 
drop the old files. At least I hope this works...

I started with drv.c and drv.h, which is the framework for all display 
drivers, and will someday replace 'display.c'.

Next I created an almost empty 'drv_MatrixOrbital.c'. You see, all 
drivers will have this 'drv_' from now on.

The new architecture has a seperation of drivers and models, where the 
old one only knew models (a model is what you specified in the config 
file as "Display")

A new driver has far less functions than the old ones, to be exactly, 
three as of now:

list() lists all supported models of this driver (for the output of 
lcd4linux -l)

init() initializes the driver
if it has to know what exact type of display it should serve, it's the 
driver's task to ask in the config file

quit() deinitializes the driver

There are no more put(), bar() and so on functions anymore, but the 
driver will register the widgets he offers. Every driver has to register 
a "text" or "label" widget, but nothing more. Think of a text-only 
display without user-defineable chars: there are no bars and no icons. A 
fully-graphics display can offer a lot of differet widgets, OTOH.


This is how the config file will look like:

Display "TheBigOne" {
    Driver MatrixOrbital
    Model  LK204-25
    Port   /dev/usb/tts/0
}

Display "TheSmallOne" {
    Driver HD44780
    Port   /dev/parport/0
    Size 16x1
    Wire {
       EX INIT
    }
}

Display "TheBigOne"


Note that you don't have to uncomment all the displays you don't have. 
Just select a "section"!


Stay tuned!


bye, Michael

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

[Lcd4linux-devel] Re: [lcd4linux] Re: Lcd4linux4debian

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

Hi Xavier,

> I'm not on the ML neither, to much traffic for my poor gsm ;)
Oh, sorry, I didn't CC you. Maybe you want to take a look at the archives...

There's the new "lcd4linux-devel" list, with low traffic, maybe your GSM 
can handle this list?

> About maintaining, I'm sorry but I don't have a very useable internet
> connection, maybe before this summer the wifi network will be up in my
> village (in fact between 3 houses, very large network ;) )

Where the hell are you living? :-)

> and I'll
> maybe be able to take the package, but for the moment Luk or Sam should
> make the package enter debian first and take care of it.

I think this is clear now: Sam is the temporary maintainer, Luk helps 
out as a co-maintainer. I'm considering you as a co-maintainer, too. 
Maybe if your internet access gets better, you will take over the 
maintenance later. Or I have to find anopther person. Lets see. I'd be 
glad if you could be the maintainer.

bye, Michael

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

[Lcd4linux-devel] cfg() new feature

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

Hi development team,

this is the first post to lcd4linux-devel. Hope you all arrived here. 
Just if you forgot, a CC'ed lcd4linux-users, too.

I wanted to let you know that I just extended the config file parser, so 
that "groups" are possible.

the syntax is:

same as ever:
key "value"

new:

group anyname {
     subkey "subvalue"
}

or even:

Layout "LargeScreen" {
     Display "TheBigOne" {
	Port "/dev/tts/0"
	Speed 2400
     }
}


The values are accessed like this:

"key" returns "value" as ever
"group:anyname.subkey" returns "subvalue"
"Layout:LargeScreen.Display:TheBigOne.Port" returns "/dev/tts/0"

You see, the ':' connects the two group specifiers, and the '.' connects 
sub-keys and/or sub-groups


This will bee needed for the new "widgets" which are next on my ToDo-List.


bye, Michael

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