mangavalk/lcdproc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove some outdated documentation

Browse Source 
Most of it has been integrated into the User's Guide.
This commit is contained in:
mmdolze
2009-03-23 22:58:44 +00:00
parent 0a811b47f6
commit ddd39c7fd4
11 changed files with 4 additions and 1496 deletions
Download Patch File Download Diff File Expand all files Collapse all files
server/drivers/README
+2 -95
View File
@@ -3,98 +3,5 @@ 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.
To understand how to write a driver see docs/API-0.5.txt or the
section about the driver API in the Developer's Guide.