[lcdproc] Progress

[Guillaume Filion]

At 19:34 -0400 24/09/01, David Douthitt wrote:
>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 i=
s
>>  >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 seem=
s
>>  >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=3Dcurses --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 cur=
ses
>>  ^[(B^[)0^[[1;50r^[[m^O^[[4l^[[?7h^[[?1h^[=3Dsock_create_server()
>
>This looks like a bug in the "debug" stuff; I've not looked at that
>yet... or is that curses output?

The "^[(B^[)0^[[1;50r^[[m^O^[[4l^[[?7h^[[?1h^[" stuff is curses 
positionning characters (I was
using script to log this). Removing the --enable-debug flag to 
configure does not resolve the problem, the curses drivers still 
segfaults.

>
>>  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.

And it now works nicely for me!

>
>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.

I don't know, it seems to me that LCDd does not need to be optimized. 
Even the worst 386 is able to feed the LCD display at an acceptable 
speed (I guess). In class we learn that most speed improvements are 
done by improving the algorithms, not by removing validity checks. 
But as you know, school is not always equal to reality. 8)

My philosphy regarding software design is to always avoid changing 
the standards after releasing them. If I understood correctly what 
you said, your change will need a (small) code change for every 
driver. I don't personnaly like that, but on the other hand, it's not 
the first time this happends with LCDproc, so I guess developpers 
won't mind very much...

Regards,
GFK's


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