[lcdproc] TCP or .so

[Matthew J Dainty]

Joris Robijn mentioned the following:

| Hmm, yes. In the current implementation it's a bit half-half. There's 
| some stuff in the driver (creation of V-bar userdef-chars) and there's 
| something on the LCDd core side (the actual drawing of the bar). That 
| means that in the current implementation we need to change both (for 
| example if we add a graphical display). I think that is not optimal.

There was some discussion as to whether to send the entire framebuffer to
the driver, or just send "paint" commands. Such that the differing amounts
of customisable characters can be used more efficiently by devices that
support them, etc. instead of making LCDd decide. This would mean each
driver would have to have some form of widget implementation.

| > Do 'ya know how to build such a parser, though? I sure don't :)
| 
| The driver has on init supplied the parser a table with pairs of start-
| keywords and pointers to functions. The parser scans the input line for 
| start-words and then for parameters (PARAMETER="string" or PARAMETER=12 
| (number) etc ). After a line has been processed, these parameters are 
| stored inside the parser. Then the function is called from the table. 
| The function can then read-out the parameter table by using a get-
| function from the parser. For example it can do a 
| get_parameter_int("size",defaultval). The return value will then be the 
| SIZE parameter, or if it was not specified the defaultval value. This 
| is a very small parser, and it's easy to use by programmers of drivers. 
| It has a good degree of encapsulation, you need the function to 
| retreive values. 

Why not use hash tables? Using the parameter name as a key should
guarantee fairly good spread as long as the hashing function is good
enough. I worked out that passing each driver library, a hash of all the
options under their [section] section in the config file, would allow any
driver to have what they wanted in the file without LCDd governing the
syntax. Any serial based devices have the port config as "8 N 9600" or
whatever it is, while parallel port ones, have /dev/parport0, etc. I2C
have the bus address, while a network driver might have a hostname,
etc. Just passing each driver a parameter and a string value, which each
driver could convert into the form they want.

Matt



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net