nanogui: Thread: Nano-X-0.5pre3

0.5pre3 is up in the usual place. This just adds readpixel() to the
generic colour framebuffer and vga16 drivers and fixes the text position
bug again (the latter is a bit of a hack). I have only tested the new
colour framebuffer readpixel() in 8 bpp mode, as none of the other depths 
seem to work at all on the NetWinder. I've ordered a new graphics card for
my PC, so I should be able to tell whether it's a NetWinder specific
problem or not. The demos still don't work perfectly, I think because of
the lack of any drawing modes except for SET. I still think this is best
done at the driver level (bogl), but it looks like there is going to have
to be some major recoding done soon to support all the features we want.

The new networking stuff isn't in there because it still isn't ready for
primetime yet. I'm going to have to do some serious revision over the
weekend for an exam on Monday, so this'll probably be the last release
until at least Tuesday evening.

I've also been working on a new keyboard driver for Linux which reads the
modifiers and control keys, and a new mouse driver which doesn't require
GPM to be running. Both are based to some extent on those in libgii...

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

The demos still don't work perfectly, I think because of
> the lack of any drawing modes except for SET. I still think this is best
> done at the driver level (bogl), but it looks like there is going to have
> to be some major recoding done soon to support all the features we want.

The XOR drawing modes are supported in my 0.5pre1 release, which
includes a modified bogl library, for reference purposes.  All the demos
work in that version.

I suggest that various versions of the bogl library be contained in the
pre* releases that are currently being worked on, especially since
we now have multiple driver writers, which is a good thing.


As I have commented, I think that nano-X is going to have to have
it's own driver set, specific to it.  If however, we use the great work
started by Ben and the bogl stuff, we could at least build
intermediate files that are able to be used by other folks as well.

I have almost completed this for the vga 4 plane driver, and probably
could have all the other drivers completed this weekend, but I got sidetracked
with the direction of nano-X 0.5pre-* and now don't know what to do.


Greg
> 

> I've also been working on a new keyboard driver for Linux which reads the
> modifiers and control keys, and a new mouse driver which doesn't require
> GPM to be running. Both are based to some extent on those in libgii...
> 


Cool.  Look at the original mini-x-new mousedrv.c code, I've been getting
ready to write a low-level driver that just reads from the serial port only, and
uses that code.  That code will decode MS and PC mice bits, and requires
no other software...

Greg

Greg Haerr ####@####.#### writes:

   Cool.  Look at the original mini-x-new mousedrv.c code, I've been getting
   ready to write a low-level driver that just reads from the serial port only, and
   uses that code.  That code will decode MS and PC mice bits, and requires
   no other software...

Did you look at the code in boml.c from BOGL?
-- 
"It takes a certain amount of shamelessness
 to be a monomaniac billionaire dwarf."
--Jon Katz <URL:http://slashdot.org/articles/99/03/17/1634238.shtml>

No, but I will  ;-)

On Friday, May 21, 1999 12:25 PM, Ben Pfaff ####@####.#### wrote:
> Greg Haerr ####@####.#### writes:
> 
>    Cool.  Look at the original mini-x-new mousedrv.c code, I've been getting
>    ready to write a low-level driver that just reads from the serial port only, and
>    uses that code.  That code will decode MS and PC mice bits, and requires
>    no other software...
> 
> Did you look at the code in boml.c from BOGL?
> -- 
> "It takes a certain amount of shamelessness
>  to be a monomaniac billionaire dwarf."
> --Jon Katz <URL:http://slashdot.org/articles/99/03/17/1634238.shtml>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

On Fri, 21 May 1999, Greg Haerr wrote:
> The XOR drawing modes are supported in my 0.5pre1 release, which
> includes a modified bogl library, for reference purposes.  All the demos
> work in that version.

Only in the cfb8 driver, and in a way which doesn't scale all that well to
support all of the different modes in all of the drawing functions. I
started working on doing it again for the cfb8 driver before I found out
about the generic cfb driver, which wants to be done in a different way
again. It's not a lot of work though.

> I suggest that various versions of the bogl library be contained in the
> pre* releases that are currently being worked on, especially since
> we now have multiple driver writers, which is a good thing.

I don't see why.

> As I have commented, I think that nano-X is going to have to have
> it's own driver set, specific to it.  If however, we use the great work
> started by Ben and the bogl stuff, we could at least build
> intermediate files that are able to be used by other folks as well.

I'd prefer to keep bogl, and improve the capabilities of bogl in general.
Hopefully Ben will be willing to include the improvements (such as some
speed optimisations I've been thinking about, and the code to support
different drawing modes) in the general Bogl release, rather than keeping
our own version of it.

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

On Fri, 21 May 1999, Greg Haerr wrote:
> Cool.  Look at the original mini-x-new mousedrv.c code, I've been getting
> ready to write a low-level driver that just reads from the serial port
> only, and uses that code.  That code will decode MS and PC mice bits,
> and requires no other software...

What I've been working on is something like a simpler version of the GGI
code. The original mini-X code wasn't very advanced, the gpm code is very
bloated and crufty, and boml is based on gpm (it is trimmed down and
tidied up a bit, but the cruftiness of the original GPM shows through,
IMO). The GGI code, BTW, supports all the mice of GPM but in a cleaner
way, I'm just trying to cut it down in size a bit.

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

On Friday, May 21, 1999 2:09 PM, Alex Holden ####@####.#### wrote:
: On Fri, 21 May 1999, Greg Haerr wrote:
: > The XOR drawing modes are supported in my 0.5pre1 release, which
: > includes a modified bogl library, for reference purposes.  All the demos
: > work in that version.
: 
: Only in the cfb8 driver, and in a way which doesn't scale all that well to
: support all of the different modes in all of the drawing functions. I
: started working on doing it again for the cfb8 driver before I found out
: about the generic cfb driver, which wants to be done in a different way
: again. It's not a lot of work though.
: 

	I agree that it'd be a good move to use the generalized variable
packed pixel drivers instead of the one I've been using.  That means
we'd support 8, 16, 24 and 32 bpp in one driver.


: > I suggest that various versions of the bogl library be contained in the
: > pre* releases that are currently being worked on, especially since
: > we now have multiple driver writers, which is a good thing.
: 
: I don't see why.

	Only to keep the distribution completely working for those of
us that want to add more features, while the driver-development can
continue as well.  Once everything works in a more generalized driver,
we can toss the earlier driver from the distribution.  This is in line with
my request to have some stability in the features working.
: 
: > As I have commented, I think that nano-X is going to have to have
: > it's own driver set, specific to it.  If however, we use the great work
: > started by Ben and the bogl stuff, we could at least build
: > intermediate files that are able to be used by other folks as well.
: 
: I'd prefer to keep bogl, and improve the capabilities of bogl in general.
: Hopefully Ben will be willing to include the improvements (such as some
: speed optimisations I've been thinking about, and the code to support
: different drawing modes) in the general Bogl release, rather than keeping
: our own version of it.

	I was originally much in favor of using unmodified bogl libraries,
for obvious reasons.  If we still can, let's do it.  The nano-X architecture has
moved on and doesn't need a number of bogl entry points, though, so the
code size is currently larger than it needs to be.  This was a concern of yours.
For example, the bogl kbd, pointer, and put routines are no longer used.

Another small issue is that the /dev/tty0 redraw stuff etc that's currently in srvmain.c
needs to be moved to driver level.  I've got plans to move all this stuff, but haven't yet.

Greg

On Friday, May 21, 1999 2:12 PM, Alex Holden ####@####.#### wrote:
: On Fri, 21 May 1999, Greg Haerr wrote:
: > Cool.  Look at the original mini-x-new mousedrv.c code, I've been getting
: > ready to write a low-level driver that just reads from the serial port
: > only, and uses that code.  That code will decode MS and PC mice bits,
: > and requires no other software...
: 
: What I've been working on is something like a simpler version of the GGI
: code. 

	Vidar sent me his working ggi drivers for nanoX v0.4.  Do you have them?
I don't have GGI installed but it seems like a very cool system.


The original mini-X code wasn't very advanced, the gpm code is very
: bloated and crufty, and boml is based on gpm (it is trimmed down and
: tidied up a bit, but the cruftiness of the original GPM shows through,
: IMO). The GGI code, BTW, supports all the mice of GPM but in a cleaner
: way, I'm just trying to cut it down in size a bit.

	I like your GPM driver alot.  I was thinking of writing a lower-level
mouse driver just for systems that don't have GPM, and run on bare hardware...

	The cool thing about the gpm driver is that it parses a single "instruction"
stream that's always the same.  Another low-level driver, mousedev.c, basically
would do nearly the same with two more "instruction" sets, and read /dev/ttyS1
rather than /dev/gpmdata...

Greg

Alex Holden ####@####.#### writes:

   I'd prefer to keep bogl, and improve the capabilities of bogl in general.
   Hopefully Ben will be willing to include the improvements (such as some
   speed optimisations I've been thinking about, and the code to support
   different drawing modes) in the general Bogl release, rather than keeping
   our own version of it.

I'm planning to *make* the nanogui version the standard version, and
figure out a way to leave out features that individual projects don't
need.

I've been missing-in-action when it comes to coding lately; hopefully
I'll be able to get some work done today or tomorrow.  I've got a huge
project due by the end of next month that people are paying me to do,
though.

-- 
"While the Melissa license is a bit unclear, Melissa aggressively
 encourages free distribution of its source code."
--Kevin Dalley ####@####.####