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