nanogui: Thread: nano-X driver stability discussion

Alex,
	I would like to ask that I get your agreement on something.

	I would like to have a nano-X release that is stable, while you, I and
others work on all sorts of neat stuff, like blitting, window managers, keyboard
events, more low level drivers, and other platforms.

	One of the reasons that I worked for 80+ hours on the initial
nano-X tarball was that I could see that I could, quickly, get all the functionality
written and designed by David Bell running on Linux, DOS, and ELKS.  What was
very important to me during that process was that I kept the driver routines
simple, so that the could be debugged.  (I hope someone appreciates all the time
spent debugging the sample apps and getting the initial drivers working *near*
perfectly.)  There were quite a few off-by-one issues, etc that had to be dealt with.

	One of the ways that I dealt with all of this, since in the beginning nothing
worked, and the bogl driver didn't do everything we needed, was to build a driver
architecture, that initially, had to support nothing other than drawpixel, for instance,
so that, even though it was slow as hell, I could debug other layers.  Afterwards,
drawHline, drawVline were implemented in the driver, rather than by calling
drawpixel.  Fillrect still uses drawhline.  The text draw routines now use the general
bitmap out routine, so that a specialized low level text draw driver entry point doesn't
*have* to be written first.  In addition, the cursor doesn't use any specialized routines
either, except for readpixel.

	We need a stable nano-X that can be proved to work completely, 100% on
the time, on at least one platform, so that anyone can use the demo programs
as a reference for porting work, or additional window manager, etc, etc work that
may want to be added.  Believe me, there are still bugs in the upper level stuff.
I already merged David Bell's mini-x-new.tar changes and have changes to submit
for UnmapWindow bugs, for instance.

	Even when bitblting etc is added to the driver level, it's REALLY convenient
to be able to #define the older method to be used, so that someone wanting to take
a nano-system can actually get it to run on say a palmtop or something without spending
weeks.

	In this way, anyone could add driver enhancements, but they could be 
backwards compatible, for instance by filling in NULL for the proc address, the
simpler driver code could easily be used.  Yes, this takes a bit more space,
but we're still very much in the design stages here, and we *need* reference ports.
When someone implements window managers and/or gdk ports, we will want
reference ports.

	I need a 100% functional nano-X so that I can continue to work on 
getting it running on ELKS, as well as debug my vga planes driver, etc.  Otherwise,
I can't pull down the latest stuff, which means I can't contribute my changes
as quickly.

	The current plan suggests quite a few mods (I like them...) on top
of a non-existent stable release.  I would like a 0.5 or 0.6 release that
contains all the stability that I have worked for.   Afterwards, if you desire,
we can work on a longer release cycle with all the resultant goodies that
people want.

Comments?

Greg

On Wed, 19 May 1999, Greg Haerr wrote:
> 	I would like to have a nano-X release that is stable, while you, I and
> others work on all sorts of neat stuff, like blitting, window managers, keyboard
> events, more low level drivers, and other platforms.

The plan is to get all the immediate major changes done (like rewriting
the networking code) done before 0.5, and then debug them through the
0.6pre series, to get something which is both well featured and fairly
stable by 0.6. 0.5pre1 only works in the case that you use the CFB8 driver
(and presumably your DOS drivers) and the "application compiled into the
server" configuration. I don't want to even consider releasing 0.5 until
the networked version and the other FB drivers work. So, I don't know,
it's up to you whether you want to wait until the full 0.5 or keep using
0.5pre1, which works on your specific preferred setup.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Wednesday, May 19, 1999 6:13 PM, Alex Holden ####@####.#### wrote:
> On Wed, 19 May 1999, Greg Haerr wrote:
> > 	I would like to have a nano-X release that is stable, while you, I and
> > others work on all sorts of neat stuff, like blitting, window managers, keyboard
> > events, more low level drivers, and other platforms.
> 
> The plan is to get all the immediate major changes done (like rewriting
> the networking code) done before 0.5, and then debug them through the
> 0.6pre series, to get something which is both well featured and fairly
> stable by 0.6. 0.5pre1 only works in the case that you use the CFB8 driver
> (and presumably your DOS drivers) and the "application compiled into the
> server" configuration.

	Okay.  I admit I haven't spent too much time playing with the client/server
configuration.  (Also there was a bug in the GrText() call over the network
that I never could figure out)

 I don't want to even consider releasing 0.5 until
> the networked version and the other FB drivers work.

	Probably a good idea.  I was just looking for some stable driver
release.


 So, I don't know,
> it's up to you whether you want to wait until the full 0.5 or keep using
> 0.5pre1, which works on your specific preferred setup.

	I'll wait.  BTW, I've created a portable VGA 4 planes driver that
runs unmodifed on linux, dos, and elks.  My first release included assembly
language, but, after looking at Ben's bogl-vga16.c, I have found a way to
make a common driver from it that doesn't include os specific headers...

> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 

On Thu, 20 May 1999, Greg Haerr wrote:
> 	Okay.  I admit I haven't spent too much time playing with the client/server
> configuration.  (Also there was a bug in the GrText() call over the network
> that I never could figure out)

I had a look at it, and the problem was just that the client wasn't
reading all the data returned from an earlier call, and that data was
staying queued in the network buffers, so when it sent the GrText() call,
it was reading garbage back. Due to the total lack of error handling, the
server and client both ended up blocked forever in read() as they were
expecting the other to send them something. The real answer is the total
rewrite I'm working on now, which does things much closer to the way X
does it, ie. it packages calls up in a message queue, and sends them all
at once when the client does a Grflush(), or any call which reads data
back from the server.

> 	Probably a good idea.  I was just looking for some stable driver
> release.

Hopefully it shouldn't be too long.

> 	I'll wait.  BTW, I've created a portable VGA 4 planes driver that
> runs unmodifed on linux, dos, and elks.  My first release included assembly
> language, but, after looking at Ben's bogl-vga16.c, I have found a way to
> make a common driver from it that doesn't include os specific headers...

Cool.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Thursday, May 20, 1999 1:03 PM, Alex Holden ####@####.#### wrote:
> On Thu, 20 May 1999, Greg Haerr wrote:
> > 	Okay.  I admit I haven't spent too much time playing with the client/server
> > configuration.  (Also there was a bug in the GrText() call over the network
> > that I never could figure out)
> 
> I had a look at it, and the problem was just that the client wasn't
> reading all the data returned from an earlier call, and that data was
> staying queued in the network buffers, so when it sent the GrText() call,
> it was reading garbage back. Due to the total lack of error handling, the
> server and client both ended up blocked forever in read() as they were
> expecting the other to send them something. The real answer is the total
> rewrite I'm working on now, which does things much closer to the way X
> does it, ie. it packages calls up in a message queue, and sends them all
> at once when the client does a Grflush(), or any call which reads data
> back from the server.

	Well I'm glad you figured it out, I couldn't.  But the problem that
I saw wasn't a hang bug a crash.  The client hangs on reads so it should
never get garbage back, though, right?

	Also, another thing I started to change in the client/server code,
but now you should know...  In the first version, the GrSendBlock took
an int, rather than a long for the size parm.  In ELKS and other 16-bit systems,
this would fail if say ReadArea were called with more than 256x256 pixels (64k).
Also, write() typically works only with < 64k data, so the internal write
loop also needs recoding...

Greg

On Thu, 20 May 1999, Greg Haerr wrote:
> 	Well I'm glad you figured it out, I couldn't.  But the problem that
> I saw wasn't a hang bug a crash.  The client hangs on reads so it should
> never get garbage back, though, right?

Hmm, I saw a hang, for the reason I described. It doesn't matter now as
it's getting thrown out anyway.

> 	Also, another thing I started to change in the client/server code,
> but now you should know...  In the first version, the GrSendBlock took
> an int, rather than a long for the size parm.  In ELKS and other 16-bit systems,
> this would fail if say ReadArea were called with more than 256x256 pixels (64k).
> Also, write() typically works only with < 64k data, so the internal write
> loop also needs recoding...

Do you mean that since write takes an int as the length argument, it can't
write more than 64K at a time on 16 machines?

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

> Do you mean that since write takes an int as the length argument, it can't
> write more than 64K at a time on 16 machines?
>
	Exactly.  Worse, it can't write exactly 64k, since that's 0   ;-)