lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] Re: Namespace

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

Hi Michael, hi Martin, hi list !

> Hrm... I'm afraid you won. I vote for :: too. Martin?
\o/

> Here's my plan: prepare the parser, rewrite all plugins so that ne 
> namespace is used, but DO NOT IMPLEMENT DYNAMIC LOADING!
> Why? I want to release 0.9.12 as soon as possible...
It's ok for me.

> a) how should the namespace look like when it contains only one 
> function? (or "contains itself")
> I guess this has already been answered:
> xmms()
> xmms::filename()
Yes. Another solution would be that plugin registers a parse() function
 acessible by xmms::parse(), and that if we call xmms(), the eval adds
 ::parse to function name.
Maybe it would be easier to implement, but do as you want.

> b) I think I'll modify the AddFunction call:
> AddFunction (<namespace> <function> <parameters> <real_function_ptr>)
> i.e.
> AddFunction ("xmms", NULL, 2, my_xmms)
> or
> AddFunction ("xmms", "filename", 2, my_xmms)
Okay.

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

PS: what about the 'french connection' ? Sam are you here for
debiannisation ? 
PS #2: Luk: there's a problem with postinst script, it
fails. We should disable dialog, which is not worth debugging debconf.

[Lcd4linux-devel] Re: Namespace

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

Hi Xavier,

> The new plugin imon from nico does a very hazardous thing : it registers
> a version() function !! I'm sorry it can't be acceptable. With the next
> 'soing' redesing it can register imon::version (imon_version) but
> version() is not that clear.

Right, but how should he know? We didn't finish our discussion about the 
namespace delimiter....

> PS to Michi : about ::
> 
>>- there is no real 'object/method' system behind, so why try to mimic
> 
> one?
> In Perl, for Objets, the syntax is object->method. The '::' delimiter
> expresses namespace::function or namespace::variable concept, exactly
> lcd4linux claim ;)

Hrm... I'm afraid you won. I vote for :: too. Martin?

I will try to rewrite the parser as soon as possible.

Here's my plan: prepare the parser, rewrite all plugins so that ne 
namespace is used, but DO NOT IMPLEMENT DYNAMIC LOADING!

Why? I want to release 0.9.12 as soon as possible...

Two questions:

a) how should the namespace look like when it contains only one 
function? (or "contains itself")

I guess this has already been answered:
xmms()
xmms::filename()

b) I think I'll modify the AddFunction call:

AddFunction (<namespace> <function> <parameters> <real_function_ptr>)

i.e.
AddFunction ("xmms", NULL, 2, my_xmms)
or
AddFunction ("xmms", "filename", 2, my_xmms)


Is this ok with you ?


bye, Michael

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

[Lcd4linux-devel] plugin_imon.c

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

Hello list !

The new plugin imon from nico does a very hazardous thing : it registers
a version() function !! I'm sorry it can't be acceptable. With the next
'soing' redesing it can register imon::version (imon_version) but
version() is not that clear.

PS to Michi : about ::
> - there is no real 'object/method' system behind, so why try to mimic
one?
In Perl, for Objets, the syntax is object->method. The '::' delimiter
expresses namespace::function or namespace::variable concept, exactly
lcd4linux claim ;)

Bye !

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

Re: [Lcd4linux-devel] Re: Dynamic loading (once more ;)

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

Hello list !

> - there is no real 'object/method' system behind, so why try to mimic one?
But there's a king of 'namespace/function' like in Perl, so I keep ::
 (I like being flamed ;) ). Another argument is below.

> - the only reason for this delimiter is that the evaluator needs a hint 
> how to find the plugin that offers a specific function. So the function 
> name has to start with the plugin name. If a plugin offers just one 
> function, it may take only the plugin name (without any extension)
>
> function call to foo():
>     [...]
> function call to foo_bar():
>     [...]

And what about i2c_sensors() and proc_stat() ?? The eval will try to
load plugin_i2c.so or plugin_proc.so !!
We'll have to find another replacement for spaces or write i2csensors()
or I2cSensors() which is quite uggly :/
So I don't think '_' is the best choice as it's already used.

> from the plugin's point of view, it's absolutely free to you (the 
> author) wether to implement a "generic parsing function" with the 
> requested item as a parameter, or to implement a seperate function for 
> each item, or both.
That's what we were talking about. But instead of calling xmms::parse()
 you call it xmms().

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

Re: [Lcd4linux-devel] Re: Dynamic loading (once more ;)

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

Hi guys,


Here's my vote: I vote for '_'

why?

- there is no real 'object/method' system behind, so why try to mimic one?

- the only reason for this delimiter is that the evaluator needs a hint 
how to find the plugin that offers a specific function. So the function 
name has to start with the plugin name. If a plugin offers just one 
function, it may take only the plugin name (without any extension)

- integrating into the parser is not that easy with other delimiters. Te 
parser reads "tokens", and one possible token is a NAME, which consists 
only of alphanumeric chars and the _. The trick is that variable names 
and functions can be parsed the same way (and have the same token), if 
the next char is an opening brace, it's a function, if not, its a variable.

When using any of the chars you suggested, I have rewrite the parser, 
and take the following into account:

- double occurence of the delimiter
- delimiter at the beginning or the end
- delimiter in variable names

>> Maybe a plugin could register multiple namespaces, but how would the
>> eval know them ? We fall in the same problem :/
>>
>> Another solution would have to have : - xmms::parse('token')
>> - i2c_sensors::parse('token')
>> - proc_stat::parse('token')
>> - proc_stat::disk('token')
>> - proc_stat::cpu('token', 'delay')
>> - ...
>> So a plugin may have multiple functions, and one-function plugins
>> register only a generic parse() function. What about it ??
> 
> Well, after checking the existing code of the plugins (and lots of 
> editing this email...), that would sound like a very good idea to me, if 
> we can get rid of the (somewhat redundant) "parse". Maybe something like 
> a "default function", if only the name of a plugin is supplied?

I'm sorry, but I don't understand this discussion.

 From the evaluator's point of view, he knows nothing about tokens and 
parsers and stuff. It behaves simple:

function call to foo():
    if foo is registered, call it
    else try to load a modules called 'plugin_foo.so'
    if registered now, call it
    else remember the failure and output an error (so on the
    next try it won't try loading again)


function call to foo_bar():
    if foo_bar is registered, call it
    else try to load a modules called 'plugin_foo.so'
    ...


from the plugin's point of view, it's absolutely free to you (the 
author) wether to implement a "generic parsing function" with the 
requested item as a parameter, or to implement a seperate function for 
each item, or both.

Both ways may make sense: there are sources where you cannot know which 
items may occur: netdev() for example: how should I know how much 
network interfaces are there, and how thy're called today?


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] Re: Dynamic loading (once more ;)

[Martin H. <ma...@he...>]

Hi Xavier,

Xavier VELLO wrote:
>> From (briefly) looking at the evaluator, I guess it should also be 
>>possible to use more than one character as a delimiter, without things 
>>getting _too_ complicated (so, "::" or "->" should be doable). But I 
>>don't see the need to do the extra work, which is why I'd vote for "$".
> 
> I vote for xmms::filename, it's the same syntax as Perl !
> In Perl, to call the function init() provided by module Gtk2, we call
> Gtk2::init() or so. Great idea !
I agree that it would look nicer (or more familiar, to a coder) - but I 
guess it mainly comes down to how difficult it is to implement that in 
the evaluator. I mean, _theoretically_ it should not be difficult to 
implement a "look-ahead" if the evaluator finds ":" to find out if the 
next char is also a ":" - but as I said, I only looked briefly at the 
evaluator, so I can't say if it's actually as easy as it sounds.

> Maybe a plugin could register multiple namespaces, but how would the
> eval know them ? We fall in the same problem :/
> 
> Another solution would have to have : 
> - xmms::parse('token')
> - i2c_sensors::parse('token')
> - proc_stat::parse('token')
> - proc_stat::disk('token')
> - proc_stat::cpu('token', 'delay')
> - ...
> So a plugin may have multiple functions, and one-function plugins
> register only a generic parse() function. What about it ??
Well, after checking the existing code of the plugins (and lots of 
editing this email...), that would sound like a very good idea to me, if 
we can get rid of the (somewhat redundant) "parse". Maybe something like 
a "default function", if only the name of a plugin is supplied?

this would make it
xmms('token')
i2c_sensors('token')
proc_stat('token')
proc_stat::disk('token')
proc_stat::cpu('token', 'delay')

Which would look pretty appealing to me. We'd have the best of both 
(especially being able to have functions, that take more than just one 
parameter)

What do you think?

Martin

-- 
You think that's tough?  Try herding cats!

Re: [Lcd4linux-devel] Re: Dynamic loading (once more ;)

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

Hi all !

>  From (briefly) looking at the evaluator, I guess it should also be 
> possible to use more than one character as a delimiter, without things 
> getting _too_ complicated (so, "::" or "->" should be doable). But I 
> don't see the need to do the extra work, which is why I'd vote for "$".
I vote for xmms::filename, it's the same syntax as Perl !
In Perl, to call the function init() provided by module Gtk2, we call
Gtk2::init() or so. Great idea !

BTW:
> So if I understand it all, instead of invoking xmms('filename'), the
> > user should invoke 'filename@xmms', so that the eval knows it need
> > plugin_xmms loaded ? Am I right ?
> No, not really. There are some plugins that offer only one function 
> (like xmms). Here the function name should be the same as the plugin name.
> With Martin's example, the xmms plugin would offer a function 
> 'filename'. You would call this function 'xmms.filename()'. The 
> evaluator could use the portion before the dot to find the plugin.
> That's what I mean with "reverse".
But don't we loose flexibility and extensibility ? A great advantage of
new generation is to have a function which provides tokens independants
from the code ! example: i2c_sensors can provide 'curr_input3' if
there's one an the day a new file 'coffe_machine1' (totally random
example ;) ) appears the plugin will handle it with no change.
Please don't trow this excelent feature !!

Maybe a plugin could register multiple namespaces, but how would the
eval know them ? We fall in the same problem :/

Another solution would have to have : 
- xmms::parse('token')
- i2c_sensors::parse('token')
- proc_stat::parse('token')
- proc_stat::disk('token')
- proc_stat::cpu('token', 'delay')
- ...
So a plugin may have multiple functions, and one-function plugins
register only a generic parse() function. What about it ??


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

Re: [Lcd4linux-devel] Re: Dynamic loading (once more ;)

[Martin H. <ma...@he...>]

Hi Michael,

Michael Reinelt wrote:
>=20
> so lets try all the delimiters I can find:
>=20
> xmms^filename: NO (power 3^2)
> xmms=B0filename: NO (not standard ASCII)
> xmms!filename: NO (logical NOT)
> xmms"filename: NO (uncool)
> xmms=A7filename: maybe
> xmms$filename: maybe
> xmms%filename: NO (modulo)
> xmms&filename: maybe
> xmms/filename: NO (division)
> xmms(filename: NO
> xmms)filename: NO
> xmms=3Dfilename: NO (equality, assignment)
> xmms?filename: NO (implicit if)
> xmms`filename: NO (string delimiter)
> xmms?filename: NO (dangerous becaue looks like `)
> xmms+filename: NO (addition)
> xmms*filename: NO (multiplication)
> xmms~filename: NO (bitwise not)
> xmms#filename: NO (comment)
> xmms<filename: NO (less than)
> xmms>filename: NO (greater than)
> xmms|filename: NO (logical OR)
> xmms,filename: NO (expression list)
> xmms;filename: maybe, but uncool
> xmms.filename: NO (string concatenation)
> xmms:filename: NO (implicit if)
> xmms_filename: NO (normal char)
> xmms-filename: NO (subtraction)
> xmms@filename: maybe, but uncool
>=20
> Did I forget something?
>=20
> Votes are welcome!
I'd vote for "$" - that's the first one that came to my mind. What I=20
like about it is that it's a plain ascii character (no danger of messing =

things up with UTF8 - which "=A7" does for example).

 From (briefly) looking at the evaluator, I guess it should also be=20
possible to use more than one character as a delimiter, without things=20
getting _too_ complicated (so, "::" or "->" should be doable). But I=20
don't see the need to do the extra work, which is why I'd vote for "$".

If you want to get _really_ fancy (or if I lose my job and have tons of=20
time to spare), one could also extend the evaluator to do a more=20
sophisticated scanning/parsing (by writing up a grammar and feeding that =

to lex and yacc), but I guess none of us has that much time to spare=20
(especially for little or no additional benefit).

> another possibility would be to use another char for string=20
> concatenation (but which one? I used the dot because Perl does so)
Well, it wouldn't really change anything - since then, we'd be looking=20
for a new separator for concatenation (and there's no "natural" one,=20
unless you think in Basic, where "+" or "&" are used for concatenation - =

not terribly elegant, especially since it's already used anyway).

Martin

--=20
You think that's tough?  Try herding cats!

Re: [Lcd4linux-devel] Re: Dynamic loading (once more ;)

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

Hi there,

>>>If you want to make it look like OOP, you can use "." for a delimiter=20
>>>(but it may screw up the parser, since "." is already used for string=20
>>>concatenation).

> we could use @, it seems to be very fashion ;) Moreover, it represents
>  well the 'namespace' concept.

I don't like it, because I'd reverse the 'object' and the 'method'.

> So if I understand it all, instead of invoking xmms('filename'), the
> user should invoke 'filename@xmms', so that the eval knows it need
> plugin_xmms loaded ? Am I right ?

No, not really. There are some plugins that offer only one function=20
(like xmms). Here the function name should be the same as the plugin name.

With Martin's example, the xmms plugin would offer a function=20
'filename'. You would call this function 'xmms.filename()'. The=20
evaluator could use the portion before the dot to find the plugin.

That's what I mean with "reverse".

xmms@filename looks

 >
 > But then, how would the plugin handle this ?
 > Eval my call the function xmms('filename'), but this may lead to
 > problems with plugin_proc_stat :/
 >
 >
 >>It gives us the same results as the "global function to plugin mapping=
",
 >>but easier to implement (no compile-time work necessary), and allows f=
or
 >>modules to be used without recompiling all the stuff. It does not
 >>require a list of modules to be specified in the config file.
 >
 > Right, it may be a good solution.
 >
 > About dynamic loading of plugins, Martin wrote :
 >
 >>But I'm looking at embedded systems (well, not _quite_ embedded, but a=
t
 >>least very limited as far as space goes), where building can be a pain=
,
 >>and always needs to be done on a separate system. So what I like to do
 >>is do a "build everything" on my devel box, and then just transfer the
 >>plugins/drivers I need on a specific installation. If a new module
 >>arrives in the source tree later on (and I need none of the new
 >>functionality of lcd4linux), I could simply pop in the new plugin on t=
he
 >>embedded box, and be done with it.
 >
 > I think you would have to pop lcd4linux binary too, or 'unresolved
 > symbols' may appear (think of hashes, cfg, ... which are evolving quit=
e
 > rapidly). But, it's right, in this case my fixed-compiletime hash isn'=
t
 > a good choice.
 >
 > Bye !
ugly.
xmms.filename look cool, but will not work.

so lets try all the delimiters I can find:

xmms^filename: NO (power 3^2)
xmms=B0filename: NO (not standard ASCII)
xmms!filename: NO (logical NOT)
xmms"filename: NO (uncool)
xmms=A7filename: maybe
xmms$filename: maybe
xmms%filename: NO (modulo)
xmms&filename: maybe
xmms/filename: NO (division)
xmms(filename: NO
xmms)filename: NO
xmms=3Dfilename: NO (equality, assignment)
xmms?filename: NO (implicit if)
xmms`filename: NO (string delimiter)
xmms?filename: NO (dangerous becaue looks like `)
xmms+filename: NO (addition)
xmms*filename: NO (multiplication)
xmms~filename: NO (bitwise not)
xmms#filename: NO (comment)
xmms<filename: NO (less than)
xmms>filename: NO (greater than)
xmms|filename: NO (logical OR)
xmms,filename: NO (expression list)
xmms;filename: maybe, but uncool
xmms.filename: NO (string concatenation)
xmms:filename: NO (implicit if)
xmms_filename: NO (normal char)
xmms-filename: NO (subtraction)
xmms@filename: maybe, but uncool

Did I forget something?

Votes are welcome!

another possibility would be to use another char for string=20
concatenation (but which one? I used the dot because Perl does so)


bye, Michael

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

Re: [Lcd4linux-devel] Re: Dynamic loading (once more ;)

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

Hi Michael, hi Martin, hi list !

> > If you want to make it look like OOP, you can use "." for a delimiter 
> > (but it may screw up the parser, since "." is already used for string 
> > concatenation).
> Right. A dot would look nice, but will not work. Maybe a ':' ?? (no, 
> impossible, because of the a?b:c)
we could use @, it seems to be very fashion ;) Moreover, it represents
 well the 'namespace' concept.

> > The user must know which functions exist (and most naturally, that would 
> > be documented on a "per plugin" basis, so the user would also know which 
> > plugin the function belongs to). Actually, it might even make the 
> > config-file more clear (since the plugin-name gives the function a 
> > context, so it's easier to understand what's going on). It would 
> > probably even solve the "duplicate function name" problem, since we 
> > could think of each plugin as a name-space. What I'm thinking about here 
> > is this:
So if I understand it all, instead of invoking xmms('filename'), the
user should invoke 'filename@xmms', so that the eval knows it need
plugin_xmms loaded ? Am I right ?

But then, how would the plugin handle this ?
Eval my call the function xmms('filename'), but this may lead to
problems with plugin_proc_stat :/

> It gives us the same results as the "global function to plugin mapping", 
> but easier to implement (no compile-time work necessary), and allows for 
> modules to be used without recompiling all the stuff. It does not 
> require a list of modules to be specified in the config file.
Right, it may be a good solution.

About dynamic loading of plugins, Martin wrote :
> But I'm looking at embedded systems (well, not _quite_ embedded, but at 
> least very limited as far as space goes), where building can be a pain, 
> and always needs to be done on a separate system. So what I like to do 
> is do a "build everything" on my devel box, and then just transfer the 
> plugins/drivers I need on a specific installation. If a new module 
> arrives in the source tree later on (and I need none of the new 
> functionality of lcd4linux), I could simply pop in the new plugin on the 
> embedded box, and be done with it.
I think you would have to pop lcd4linux binary too, or 'unresolved
symbols' may appear (think of hashes, cfg, ... which are evolving quite
rapidly). But, it's right, in this case my fixed-compiletime hash isn't
a good choice.

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

[Lcd4linux-devel] Re: Dynamic loading (once more ;)

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

Hi Martin, Hi Xavier,

> Ok, maybe I'm missing something obvious here - but if we want to take 
> the easy routem, why can't we simply define that a function name 
> consists of
> plugin_name + delimiter + function_name ?

Ahh...
> 
> If you want to make it look like OOP, you can use "." for a delimiter 
> (but it may screw up the parser, since "." is already used for string 
> concatenation).

Right. A dot would look nice, but will not work. Maybe a ':' ?? (no, 
impossible, because of the a?b:c)

I'm afraid we run out of delimiters :-)

> The user must know which functions exist (and most naturally, that would 
> be documented on a "per plugin" basis, so the user would also know which 
> plugin the function belongs to). Actually, it might even make the 
> config-file more clear (since the plugin-name gives the function a 
> context, so it's easier to understand what's going on). It would 
> probably even solve the "duplicate function name" problem, since we 
> could think of each plugin as a name-space. What I'm thinking about here 
> is this:
> the xmms plugin has a function "filename" (I don't know if it does, but 
> lets assume it does). If you know you're talking about xmms, "filename" 
> makes sense (pobably the name of the file currently being played).
> If someone else is writing a "plugin_printspooler", "filename" might be 
> the name of the file currently being printed. In both cases, it's a 
> filename, but I guess it would be nice to know (simply from looking at 
> the config) which plugin is being used by a statement in the setup.

Martin - that's why I've been waiting for your comments :-)

I really LOVE this idea! It solves all our issues, and is a win-win 
solution!

It gives us the same results as the "global function to plugin mapping", 
but easier to implement (no compile-time work necessary), and allows for 
modules to be used without recompiling all the stuff. It does not 
require a list of modules to be specified in the config file.

Great!

Xavier, what's your opinion?

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

[Lcd4linux-devel] Re: [lcd4linux] curses bug (was: GPO circuitry)

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

Hi Martin,

> Talking about testing - I'm having a problem with the current version 
> from CVS

> if test "$TEXT" = "yes"; then
>    if test "$has_curses" = true; then
> #     DRIVERS="$DRIVERS Text.lo"
> #     DRIVERS="$DRIVERS Text.o"
>       DRVLIBS="$DRVLIBS $CURSES_LIBS"
>       CPPFLAGS="$CPPFLAGS $CURSES_INCLUDES"
>       AC_DEFINE(WITH_TEXT,1,[Curses driver])
>    else
>       AC_MSG_WARN(curses not found: Text driver disabled)
>    fi
> fi

Thanks for the hint - there's been a namespace clash between the curses 
driver (was called TEXT) and the new generic text display driver (TEXT too).

I renamed TEXT to CURSES. Fixed in CVS.


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] plugin_dvb

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

Hi Nico,

> plugin_dvb.c:50: linux/dvb/frontend.h: No such file or directory

Fixed. Thanks for the hint!


bye, Michael

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

[Lcd4linux-devel] plugin_dvb

[Nico W. <Nic...@po...>]

Hello,

I've a problem compiling the current cvs-version ...

gcc -DHAVE_CONFIG_H -I. -I. -I.     -D_GNU_SOURCE -Wall -g -O2 -c
plugin_dvb.c
plugin_dvb.c:50: linux/dvb/frontend.h: No such file or directory
make: *** [plugin_dvb.o] Error 1

Bye,
    Nico

Re: [Lcd4linux-devel] News from lcd4linux-CVS

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

Hi Michael, hi list !

> I just made the big cut inside CVS: all old drivers and plugins (called 
> "clients" in the old style) that have already been ported or are no 
> longer necessary have been removed.
> So the CVS code does contain only NextGeneration code, besides the 
> things not ported by now, but they will be neither compiled nor linked.
Good ! But maybe it would have been good to 'fork' a new CVS branch to
keep this just 'in case'

> Currently the NextGeneration is working with most of the plugins and a 
> few drivers (MatrixOrbital, Crystalfontz, HD44780, Cwlinux).
But Cwlinux is not tested ;)

> Plugins that should be ported:
> - wifi (Xavier?)
I'm working on, I have 2 weeks of holidays \o/

> Plugins that should be developed:
> - partition information (used, free, ...)
for partitions, you should parse /proc/partitions
and I would add : perl embedding (I'm working on)

> Drivers that should be written:
> - SED 15*
I found one of these (122x32) for 20euro in France, it appears to be
 good hardware.
and maybe : Samsung KS0107/KS0108 (128x64 for 40euro)

> For the Graphic display drivers (T6963, raster, X11) the framework is
> missing, too. I will work this out as soon as possible. 
About this : pure graphic displays don't know text, so it appears that
lcd4linux will emulate the text, so please keep it possible to add
multiple 'fonts' (not totally geek, think about the 'inverted text',
bold, ...)


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

[Lcd4linux-devel] News from lcd4linux-CVS

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

Hi LCD4Linux-Users and Developers,

I just made the big cut inside CVS: all old drivers and plugins (called 
"clients" in the old style) that have already been ported or are no 
longer necessary have been removed.

So the CVS code does contain only NextGeneration code, besides the 
things not ported by now, but they will be neither compiled nor linked.

Currently the NextGeneration is working with most of the plugins and a 
few drivers (MatrixOrbital, Crystalfontz, HD44780, Cwlinux).

Here's the ToDo-List:

Plugins that should be ported:
- battery (APM/ACPI)
- exec (external commands)
- imon (Nico?)
- isdn
- mail
- seti
- wifi (Xavier?)

Plugins that should be developed:
- partition information (used, free, ...)

Drivers that should be ported:
- Beckmann&Egle
- Milford Instruments
- Palm Pilot
- Raster (PPM, PNG)
- T6963
- USBLCD
- X11

Drivers that should be written:
- SED 15*

GPO's are not working at all, because the framework is still missing.

For the Graphic display drivers (T6963, raster, X11) the framework is 
missing, too. I will work this out as soon as possible.

Volunteers are welcome!


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] Re: icon visibility patch

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

Hello Michael, hello list !

Here's the patch to finish a proper implementation of the visible
attribute, following your instructions.

> > - a better solution would be to implement the visible attribute withing
> > the layout itself so it can work for text and other widgets without
> > implementing it for each one. But I can't figure out where to hack for
> > this.
> I'm afraid this is not possible.
I read several times drv_generic_text, and y idea is not applicable, we
 must implement it for each widget. It would be trivial for text.

> Taking a quick look at the code, this has to be done in the draw() 
> function inside drv_generic_text.c. There are some lines where 
> Icon->ascii is transferred to the framebuffer and/or the display. Add 
> some short code here to use a blank instead of the ascii value.
I send the ASCII code 32 (space) instead of the code of user defined
  char corresponding to the icon. There's no 'empty' char, so I used
 space.
The ascii code is taken from the datasheet of cwlinux display, but it
works for my HD, so I suppose it'll work for the others.

> Another point: I would not issue a warning about a missing 
> visible_expression. If none is there (which should be the default), 
> don't replace it with "1", but hanlde this by not evaluating the 
> expression if NULL, but using 1 as a result.
Done

> Maybe this could be combinded with a "blinking" attribute.
I don't know really how to do this ? A simple solution using the same
blink speed as 'speed' would be to do a Icon->visible=!Icon->visible if
Icon->blink. But I don't know how to implement a blink speed independant
from the display speed.

Bye !

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

PS: I saw somebody on the lcd4linux-users ML who had a
software-controlled blacklight on his HD (the pin 3 was connected to a
transistor controlled by a spare pin of the // port if I remember),
maybe you could find him and implement this functionnality ? -> ToDo ;)

[Lcd4linux-devel] Re: icon visibility patch

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

Hi Xavier,

> Here is a preliminary patch to add support of a 'visible' attribute for
> icons. In fact it's not very mush work. But this would need more things:

Looks good, but I'd prefer another way of doing this.

> - if !visible, it uses the first frame of the sequence. For my icons the
> first bitmap is empty, but it may not be the case of all icons. Maybe
> add and empty bitmap at the beginning of each sequence (and skip it for
> normal showing) ?
This is exactly the stuff I'd do another way.

> - a better solution would be to implement the visible attribute withing
> the layout itself so it can work for text and other widgets without
> implementing it for each one. But I can't figure out where to hack for
> this.
I'm afraid this is not possible.

Now for my idea: I would process the icon just like any other icon, but 
replace its position in the framebuffer with a blank. This way, one does 
not have to care about empty bitmaps; and it would be faster (you don't 
need to redefine the bitmap if changing to invisible).

Taking a quick look at the code, this has to be done in the draw() 
function inside drv_generic_text.c. There are some lines where 
Icon->ascii is transferred to the framebuffer and/or the display. Add 
some short code here to use a blank instead of the ascii value.

Another point: I would not issue a warning about a missing 
visible_expression. If none is there (which should be the default), 
don't replace it with "1", but hanlde this by not evaluating the 
expression if NULL, but using 1 as a result.

The same should be applied to the text widget.

Maybe this could be combinded with a "blinking" attribute.


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] HD44780 stuff (F*CK! F*UCK! F*UCK! F*UCK!)

[Bill P. <goa...@ya...>]

re: the F*CK problem, glad to know you're human. ;)

>     snprintf (tmpbuffer, 2, "\%o", cu_vfd_brightness);
> What the heck is "\%o"? Is it octal? Why the backslash? What does the 
> resulting string look like? I suppose the backslash was a typo. 

ach yes backslash is a leftover. I was trying to pass the function
set along with the hd_write. Which didn't work. and octal is... whoops.

> It gets even more strange:
>     HD_write (0x03, tmpbuffer, 1, T_WRCG);
> If the abofe format string is correct, the brightness would be in the 
> second character. But you're sending only one byte (the backslash).
> 

That IS strange. Strange that it actually changes the brightness anyway.
It worked or I'd have spotted that (I hope, anyway). No clue why it works.

> But please double-check the code in 
> drv_HD44780.c Thanks!

Yep! It works like you knew it would. CLEAN too. Look at those sleek lines.
See what purpose crappy coding is for? It motivates real programmers. ;)

-BP

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: [Lcd4linux-devel] progress report RE: HD44780 stuff

[Martin H. <ma...@he...>]

Hi Xavier,

>>>For example your patch breaks the ppdev init for 'generic' HD like mine
>>>! I have to use old raw handling.
>>
>>Sorry - I missed that you were using the "old raw handling".
> 
> I'm curently using the raw way because the new ppdev was broken by your patch.
> 
> 
>>Can you check if it's still broken (I just committed my changes to CVS)? 
>>  If it's still broken, I'll have to look into it - I'm not really sure 
>>how it could break things, unless if the "set_direction" call doesn't 
>>work with raw port access.
> 
> I'll look as soon as possible if it works now with the "models" rework
Ok - let me (or best, all of us) know how it turns out. I'm still 
confused as to what "broke" - since none of the changes should have 
changed anything, unless you had a "UseBusy 1" in your config.

Martin

-- 
You think that's tough?  Try herding cats!

[Lcd4linux-devel] Re: problem in widgets

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

Hi Xavier, Hi List, Hi martin,

>>>I tried to implement visibility attribute for icons (and then other
>>>widgets), but there's a problem that I spoted on your code :
>>>speed attribute on icons can't contain a real expression, just numbers.
>>>I fact if I put "speed 150-cpu('busy', 500)" it does draw the icon with
>>>a speed depending on the cpu usage, but other widgets don't show.

Xavier, for the good news: I found the bug you're talking about. You 
were right, as soon as you use certain functions in an expression, no 
more other widgets will be processed.

It took me hours to find that bug. Now that I found it, I hardly want to 
talk about it, because a few days ago I had a discussion with Martin 
about using a certain C function or better not using it.

Well, in short: Martin, you won.

It was strtok().

F*CK! F*UCK! F*UCK! F*UCK! F*UCK! F*UCK! F*UCK! F*UCK! F*UCK! F*UCK!

The widget list is processed using strtok. The cpu() function uses 
strtok. This second strtok interferes with the first one. Shit!

Having a look at strtok_r....

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] progress report RE: HD44780 stuff

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

Le dim 01/02/2004 =C3=A0 13:34, Martin Hejl a =C3=A9crit :
> Hi again,
>=20
> > For example your patch breaks the ppdev init for 'generic' HD like mi=
ne
> > ! I have to use old raw handling.
> Sorry - I missed that you were using the "old raw handling".
I'm curently using the raw way because the new ppdev was broken by your p=
atch.

> Can you check if it's still broken (I just committed my changes to CVS)=
?=20
>   If it's still broken, I'll have to look into it - I'm not really sure=
=20
> how it could break things, unless if the "set_direction" call doesn't=20
> work with raw port access.
I'll look as soon as possible if it works now with the "models" rework

Bye !

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

Re: [Lcd4linux-devel] capitals in lcd4linux.conf

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

> Hmmm. I think there's a quite very strict naming convention: case 
> doesn't matter.
Hmmm, sorry I have to iron my laces -->[]

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

Re: [Lcd4linux-devel] capitals in lcd4linux.conf

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

Hi there,

> There's one thing quite messy in the new config, the problem of
> CAPITALS; I'm explaining :
> - to set the transfert rate of a MO display, we use the 'Speed'
> attribute.
> - to set the speed a icon displays we use the 'speed' attribute.
> - class of a widget is 'Text' or 'Bar'
> - ... and so on ...
> 
> The claim is that the user is lost between capitalized and
> non-capitalised attributes, and typos will occur often.
> 
> I propose to have a strict naming convention. The easier would be to
> make all non-capitalized (even Widget, Layout, Row1, ...), or have
> something like "attributes non-cap and sections capitalized" or other
> thing like this.
> What do the "The LCD4Linux Team " think about it ? May preference goes
> to all non-capitalized.

Hmmm. I think there's a quite very strict naming convention: case 
doesn't matter.

So feel free to write Speed, speed, SPEED, or SPeeD

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

[Lcd4linux-devel] capitals in lcd4linux.conf

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

Hello list, hello Michael !

There's one thing quite messy in the new config, the problem of
CAPITALS; I'm explaining :
- to set the transfert rate of a MO display, we use the 'Speed'
attribute.
- to set the speed a icon displays we use the 'speed' attribute.
- class of a widget is 'Text' or 'Bar'
- ... and so on ...

The claim is that the user is lost between capitalized and
non-capitalised attributes, and typos will occur often.

I propose to have a strict naming convention. The easier would be to
make all non-capitalized (even Widget, Layout, Row1, ...), or have
something like "attributes non-cap and sections capitalized" or other
thing like this.
What do the "The LCD4Linux Team " think about it ? May preference goes
to all non-capitalized.

Michael, add it in your ToDo ;)

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