Subject:
nano-X driver stability discussion
From:
Greg Haerr ####@####.####
Date:
19 May 1999 23:02:56 -0000
Message-Id: <01BEA219.2AE49C60.greg@censoft.com>
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
