101 lines
3.4 KiB
Plaintext
101 lines
3.4 KiB
Plaintext
UNDERSTANDING LCDPROC DRIVERS
|
|
|
|
LCDproc drivers are compiled as modules that will be loaded by the
|
|
LCDd daemon's core on request.
|
|
|
|
To understand how to write a driver see docs/API-0.5.txt and the
|
|
section about the driver API in the Admin Guide.
|
|
|
|
|
|
-------- 8< snip >8 ------------------
|
|
The remainder of this file may be horribly outdated.
|
|
Treat the information contained herein with caution.
|
|
You have been warned.
|
|
|
|
|
|
------------------------------ lcd_logical_driver ------------------------------
|
|
|
|
The first thing that is done is that lcd_init (lcd.c) is called. This function
|
|
first sets up basic housekeeping details. Then it calls lcd_drv_init, which
|
|
initializes the basic functions for the lcd structure.
|
|
|
|
Each function loops through the list of currently loaded and active drivers.
|
|
The framebuffer is set to point to the appropriate framebuffer. Then
|
|
the function determines what function to call (for each driver) - which
|
|
is one of three possibilities:
|
|
|
|
1. driver->function() > 0
|
|
|
|
Call the driver function contained in driver->function();
|
|
|
|
2. driver->function() == NULL
|
|
|
|
Ignore (no function);
|
|
|
|
3. driver->function() == -1
|
|
|
|
Call the generic driver.
|
|
|
|
The generic driver functions are drv_base_* and are contained in drv_base.c
|
|
|
|
Note that these drv_base_* functions are also installed as part of the "base"
|
|
driver, and thus could be called not only once, but many times.
|
|
|
|
So... to clear the screen (after initializing the drivers) one might do
|
|
this - and it leads to the sequence of activities shown...
|
|
|
|
lcd.clear;
|
|
--> lcd_drv_clear;
|
|
--> driver->clear;
|
|
--> drv_base_clear;
|
|
--> driver->clear;
|
|
--> MtxOrb_clear;
|
|
--> driver->clear;
|
|
--> drv_base_clear;
|
|
--> driver->clear;
|
|
|
|
In the first case, the "base" driver is called. In the second, the "MtxOrb"
|
|
driver is called, and it has a function to use. In the third, an unnamed
|
|
driver is called, but it delegates back to the base function. In the fourth,
|
|
the driver has no function; so it is ignored.
|
|
|
|
SUGGESTED SIMPLIFICATIONS
|
|
|
|
1. Remove the base driver entirely.
|
|
|
|
The base driver does not provide any substantial advantage, and significantly
|
|
complicates code.
|
|
|
|
2. Separate the input driver data from the output driver data.
|
|
|
|
This promotes easier comprehension and allows more specialization of each.
|
|
Some drivers may only have input or output components; some may have both.
|
|
This also permits coding such that only one output device is allowed
|
|
while multiple input devices are allowed.
|
|
|
|
3. Use only ONE output driver for each invocation of the server.
|
|
|
|
This simplifies coding - since there is then only one size, one width, one
|
|
height. It also removes the need for scanning a big loop for functions to
|
|
execute.
|
|
|
|
Given these enhancements, all of drv_base.c could be eliminated, and
|
|
probably most or all of lcd.c. It would dramatically reduce all of the
|
|
processing overhead necessary to handle screen output.
|
|
|
|
MORE SUGGESTIONS AND ENHANCEMENTS
|
|
|
|
1. Make input keys driver-specific.
|
|
|
|
This permits the use of each and every key without overlap. For example,
|
|
it would keep a joystick button press from conflicting with a LCD display
|
|
button.
|
|
|
|
2. Specify the standard (configurable) set of keys for server actions
|
|
in each driver.
|
|
|
|
This permits not only a unique standard configuration for each device,
|
|
it also hides what that is from the program itself. If this is configurable,
|
|
it also makes it possible to adjust this set of keys during operation.
|
|
|