[lcdproc] Progress

David Douthitt n9ubh@callsign.net
Mon, 24 Sep 2001 19:34:12 -0400


Guillaume Filion wrote:
> 
> At 18:35 -0400 24/09/01, David Douthitt wrote:
> >I've just gotten through making LCDd work with a SINGLE driver.  This is
> >in preparations for a single output driver but with multiple input
> >drivers.
> >
> [...]
> >
> >I've not tested this with other drivers, and haven't put this through
> >rigorous testing except against my pseudo-MatrixOrbital setup.  It seems
> >to work with lcdproc and LCDd; however, I noticed lcdproc's X mode is
> >not right.  May have to take a diversion and fix it.
> 
> Here's also a problem with the (n)curses driver:
> -----
> [gfk@cesam lcdproc]$./configure --enable-drivers=curses --enable-debug
> [gfk@cesam lcdproc]$ make
> [gfk@cesam lcdproc]$ gdb server/LCDd
> (gdb) run -d curses
> Starting program: /usr/local/home/gfk/lcdproc/lcdproc/server/LCDd -d curses
> ^[(B^[)0^[[1;50r^[[m^O^[[4l^[[?7h^[[?1h^[=sock_create_server()

This looks like a bug in the "debug" stuff; I've not looked at that
yet... or is that curses output?

> Program received signal SIGSEGV, Segmentation fault.
> 0x0 in ?? ()
> (gdb) quit
> -----
> 
> Don't really know what's the problem... 8(

I do :(

I committed a fix for curses; other drivers will need to follow.

Here's the main change that will cause trouble:

The new driver code does this:

1. Run the function (such as lcd.clear())

The old driver code does this:

1. If function is 0, return;
2. If function is -1, run base driver code;
3. Run function...

My thought was that all of this testing will cause a lot of excess code
time - the above added two function calls to the time, plus all of the
testing - for EVERY function that went by.


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