nanogui: Re: nanoGui development


Previous by date: 3 May 1999 23:40:03 -0000 Re: nanoGui development, Alex Holden
Next by date: 3 May 1999 23:40:03 -0000 Re: nanoGui development, Alistair Riddoch
Previous in thread: 3 May 1999 23:40:03 -0000 Re: nanoGui development, Alex Holden
Next in thread: 3 May 1999 23:40:03 -0000 Re: nanoGui development, Alistair Riddoch

Subject: RE: nanoGui development
From: Greg Haerr ####@####.####
Date: 3 May 1999 23:40:03 -0000
Message-Id: <01BE958C.300CFC30.greg@censoft.com>

Definitely put a link to Alex Buell's Framebuffer HOWTO...

On Monday, May 03, 1999 3:57 PM, Alex Holden ####@####.#### wrote:
> On Mon, 3 May 1999, Greg Haerr wrote:
> > 	Thanks for answering so quickly.  It seems like you've got no
> > problem with me moving this stuff forward, since you've got other projects and
> > exams.  I've been looking for just this kind of initial project, since I'm into
> > "small" systems, guis, compiler/interpreters.
> 
> Yep, no problem. I find it interesting making systems which require less
> than 64MB Ram and a 1GB hard disk to run optimally too :) I've spent quite
> a bit of time developing for small PICs, and it's amazing what you can do
> with a few hundred bytes if that's all you have.
> 
> > 	I'll get all this stuff working, and change a few things so that
> > the project can be compiled as client/server, as well as a non-network version.  I also
> > have some ideas on how to better integrate the "screen drivers" (bogl) so that
> > different bits-per-pixel etc can be supported, and that the screen driver interface
> > is extremely well defined.
> 
> Okay, I was talking to someone else who has also ported mini-X to
> Linux-2.2 framebuffer, but done it without bogl. He was interested in
> merging his work with nano-X, but I haven't been able to contact him
> lately as his DNS is dead. If his code is a better way of doing it than
> bogl, I might use that instead, but I haven't seen it yet. Certainly a way
> of supporting more bit-depth levels, preferrably in the same binary with
> autodetection, is needed.
> 
> > 	I got into this because I've been watching the ELKS development work,
> > and they were wondering whether this work could used for their project.  The answer
> 
> That's something I've never played with...
> 
> > is absolutely yes, although some direct real-mode linked in frame-buffer support would
> > be necessary.  To get ready for that, and the associated possible 16-bit compiles, this
> > project should use typedefs for the internal types, like colors, and x,y,w,h stuff.  I would
> > like to typedef all that stuff.  All-in-all, this would allow for nanoGui to become quite
> > portable.
> 
> Yes, quite a lot of it is typedef'd to start with.
> 
> > 	On another note, it took me quite a while to figure out the v2.2 framebuffer support,
> > since I was running v2.0.  It might be a good idea to include some setup info in your
> > FAQ.  With the low-level interface well implemented, it would also be fairly straight-forward
> > to include support for vgalib, which would allow older v2.0 linux users to run this.
> 
> I never used the framebuffer on a 2.0 kernel... Perhaps a pointer to the
> Alex Buell's Framebuffer-HOWTO would be a good idea?
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 

Previous by date: 3 May 1999 23:40:03 -0000 Re: nanoGui development, Alex Holden
Next by date: 3 May 1999 23:40:03 -0000 Re: nanoGui development, Alistair Riddoch
Previous in thread: 3 May 1999 23:40:03 -0000 Re: nanoGui development, Alex Holden
Next in thread: 3 May 1999 23:40:03 -0000 Re: nanoGui development, Alistair Riddoch


Powered by ezmlm-browse 0.20.