LCDproc development and user support list

Text archives Help


[lcdproc] Idea for driver handling...


Chronological Thread 
  • From: Ken Robertson <ken AT qgyen.net> (Ken Robertson)
  • Subject: [lcdproc] Idea for driver handling...
  • Date: 08 Sep 2000 13:16:28 PDT

Here is an idea I had been talking with Will about on IRC. I think it would
be
a good idea to have the input and output drivers act as modules, rather than
all in a library. It work sort of like the kernel handles libraries, except
they are only loaded at runtime.

Picture it like this. All the i/o stuff is compiled into their own modules
(drv_text.o, drv_,mtxobl.o, drv_irman.o, etc), and they are placed into a
LCDproc lib directory. Then, at runtime, LCDd will load modules based on
command line input, or a section of the config file. Sort of like "LCDd -o
'drv_text.o,drv_irman.o'".

The main reason for doing this is to allow third parties to make drivers
easier, and reduce executeable size and memory usage, since unused modules
won't be in memory. I know probably a number of people have or would like to
write other drivers, but they are difficult to incorporate into LCDproc's
sometimes confusing code. In this situation, it could be rather easy. Have
LCDd run a module's module_init() function and it will set everything up and
integrate it correctly to the present code.

Implimenting it into LCDd shouldn't be too difficult. Use the dynamic library
functions for loading/unloaded, and then to keep track of the modules, use a
linked list. When it needs to produce output, LCDd goes through the modules
list for output ones, then sends them the data, and the module takes care of
trasnmitting to the device or whatnot.

The types of modules I'd suggest would be output and input of course, and then
client modules. Like if someone wants to add a function to LCDd, when an
outside client connects, it would send a command to the server allowing it to
be turned over to a module. Then when LCDd recieves socket info from it, it
will get turned over to the module. Like, I've wanted to do a remote LCD
feature, where say LCDd is running at home, and I want my LCD at work to show
the screen from home. Make a client module that will instead of recieving
widgets, will trasnmit widgets to a specified connection.

Opinions? Ideas?

Thanks,
Ken


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




Archive powered by MHonArc 2.6.18.

Top of page