Menu
▾
▴
lcd4linux-devel
|
From: Xavier V. <xav...@fr...> - 2004-01-12 20:14:13
|
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...> |
|
From: Michael R. <re...@eu...> - 2004-01-13 10:31:59
|
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... |
|
From: Xavier V. <xav...@fr...> - 2004-01-13 20:00:19
|
> 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
|
|
From: Michael R. <re...@eu...> - 2004-01-14 10:06:06
|
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... |
|
From: <Mar...@t-...> - 2004-01-14 12:21:53
|
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 |
|
From: Michael R. <re...@eu...> - 2004-01-17 09:53:56
|
Hi Xavier, Hi list,
>>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.
>
> Okay, I understand it ! In fact, hashes are handled by the plugins internally.
Right!
>>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.
> What about this timeout ? Is there a helper ? Maybe a function to
> register timeouts and see if they timed-out. It may be in yet, sorry
> I don't have to code under my eyes :/
The code is that simple that I didn't write a helper for it(although
there is a timer queue management, but this is used for widge updates).
If your timeout is 1 second or higher, and second-resolution is enough,
use the following:
static int parse_anything(void)
{
static time_t now=0;
// reread every second only
if (time(NULL)==now) return 0;
time(&now);
// real parsing happens here...
return 0;
}
If you need higher resolutions (milliseconds), you need the following
snippet:
static struct timeval end = {0, 0};
struct timeval now;
// update every 10 msec
gettimeofday(&now, NULL);
if (now.tv_sec==end.tv_sec?
now.tv_usec<end.tv_usec:now.tv_sec<end.tv_sec) {
return 0;
}
end.tv_sec = now.tv_sec;
end.tv_usec = now.tv_usec + 1000*msec;
while (end.tv_usec > 1000000) {
end.tv_usec -= 1000000;
end.tv_sec++;
}
// parse it...
> 'lcd4linux -l' can load all
> the drivers it knows, we don't matter about memory usage as it'll die
> then. Same to list plugins.
Thats what I'm thinking of, too.
> I fact, I thinked about a sort of 'callback' function : now if the eval
> doesn't know a function, it returns an error. It may call a function
> which loads the good plugin and evaluates the function, so that the
> evaluator doesn't mind and everybody's happy ;) It's not the evaluator
> that searches for plugins at startup, it 'learns' with its "errors". In
> this way, we don't need to modify much the eval.
And how should the evaluator know which .so to load?
> This .so-ing may be later, but we should keep it in mind so that we
> don't do silly things that will prevent us to make it then.
Full ACK.
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-01-17 11:12:25
|
Hi Michael, Hi list,
> > I fact, I thinked about a sort of 'callback' function : now if the eval
> > doesn't know a function, it returns an error. It may call a function
> > which loads the good plugin and evaluates the function, so that the
> > evaluator doesn't mind and everybody's happy ;) It's not the evaluator
> > that searches for plugins at startup, it 'learns' with its "errors". In
> > this way, we don't need to modify much the eval.
> And how should the evaluator know which .so to load?
That's what the compile-time generated hash is about. We can generate
(or staticaly write) a hash which lists all functions supported by a
.so, so instead of printing "Unknown function", the eval should call a
sort of "fallback" function which browses this hash, searching for the
function the eval doesn't know, example :
- we have this hash
plugins {
"i2c_sensors.so" -> "i2c_sensors";
"xmms.so" -> "xmms";
"example.so" -> "func1, func2";
...
}
then the eval has to evaluate xmms('Title'), but doesn't know this
function, it calls fallback('xmms') which :
- browses the hash
- finds function xmms is provided by xmms.so
- loads /usr/lib/lcd4linux/plugins/xmms.so
- return 0
then the evaluator can re-evaluate the function is fallback returns 0 or
print "Unknown function" if !fallback(), that's all.
I know it may be a bit confused, but it's clear in my head. I may try to
write an example of such a fallback() func, but I'm not sure to succeed.
> > This .so-ing may be later, but we should keep it in mind so that we
> > don't do silly things that will prevent us to make it then.
> Full ACK.
ACK ? what does it mean ?
Bye !
--
Xavier VELLO <xav...@fr...>
PS: please Michael DON'T cc me anymore when ou reply to the list ! Isn't
there a way to have a "reply-to" header like others maillists ?
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X