nanogui: Thread: Re: Running document -- RTEMS framebuffer interface specification (fwd)

> I have put something together as a starting point  for the design of 
> "framebuffer" interface
> for RTEMS. 
> 

Hi Ros,

This is a great idea.  I've been working furiously to get the Roadrunner/pk
system to the point where I can start porting Microwindows.  If you don't
mind, I'd like to contribute to this document with an eye towards helping
make whatever interfaces emerge easily incorporatable into this system
as well. Any thoughts on that?  The current device driver interface for
Roadrunner/pk is available in the code snapshot at www.cornfed.com.
The file in the distribution is roadrunner/include/dev.h

FM

--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com

: This is a great idea.  I've been working furiously to get the Roadrunner/pk
: system to the point where I can start porting Microwindows.  If you don't
: mind, I'd like to contribute to this document with an eye towards helping
: make whatever interfaces emerge easily incorporatable into this system
: as well. Any thoughts on that?  The current device driver interface for
: Roadrunner/pk is available in the code snapshot at www.cornfed.com.
: The file in the distribution is roadrunner/include/dev.h

Yes.  Perhaps the answer to RTEMS is to get a single, simple
framebuffer interface defined, and have well-defined entry points
into separate chipset specific .c files elsewhere.  This is what Linux
first tried to do I think, but the console code ended up being wound
into each of the chipset drivers, and now, it's huge and too complicated.

Having the chipset specific stuff in separate files, and NOT having
anything to do with the console structures would be great, since
the code could be reused for PK, or, for Microwindows in "bare
hardware" mode.

Greg