LCDproc development and user support list

Text archives Help

[lcdproc] Driver Design (attn mattd)

Chronological Thread 
  • From: ken AT (Ken Robertson)
  • Subject: [lcdproc] Driver Design (attn mattd)
  • Date: Wed, 27 Sep 2000 13:39:37 -0700 (PDT)

Hey... this is mainly for mattd, since he is signed up for the task on SF,
but figured I'd send it to the list anyway.

I'm not sure how far along you are with the driver development, but I've
been working on some modular code with another program of mine as a sort of
testbed and I'd like to combine it with whatever you have so far.

To give you an idea of how it works, try and follow me. First, we have a
linked list of all our current output devices. When a new one is activate
(at run time), a module_init(file) func is run to handle the dlopen stuff.
dlopen then runs a _init function in the module. _init sets everything up
for itself and the server. First it goes and gets its configuration, then
it runs a register_device(deviceid, parse_data(data)) function that adds
itself into the linked list of output devices.

Whenever a new screen is suppied, or screens change, or anything else, the
server runs through the linked list sending each device the command, and
then the driver decyphers it and does what it needs to do. If it is screen
data, it will send the driver the data exactly as it gets it from the
client, so that then the formats the screen from it.

Another aspect I thought might be possible would be command widgits. I
don't remember what was decided on it before... whether not needed, or too
much too soon, but eventually we could adapt a similar thing for server
commands. I dunno... whatever.

Remember, this is just an idea about the main points. The little details
like parameters and what function calls another can be settled once we have
a basic structure. My main think I want to change is have the
configuration passed in a union with module_init, and then passed to _init,
but I haven't yet found if there is a way to give a parameter to _init.

So if you have any code or other ideas, it would be greatly appreciated. I
hope to get it fully working in my program this week, and get it adapted to
a LCDproc format over the weekend.


To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT

  • [lcdproc] Driver Design (attn mattd), Ken Robertson, 09/27/2000

Archive powered by MHonArc 2.6.18.

Top of page