nanogui: RTEMS graphics
Subject:
RTEMS graphics
From:
Greg Haerr ####@####.####
Date:
4 Feb 2000 23:07:20 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFB054C08@SYS.CenSoft.COM>
I've been looking a little further into existing graphics code
that we could use for Microwindows and RTEMS or another
operating system.
Actually, I'm changing my opinion in using the Linux fb code.
This is because, it's pretty messy, and overkill for embedded
systems. I recommend the following:
The GRX package already has the chipset-specific code
and the drawing code separated. We could use the tested
GRX package to support various chipsets for RTEMS.
Yes, they would need rewriting, but we start with a chipset
that someone has.
Next, we use the barely modified Microwindows framebuffer
drivers that already exist, and start with a first-version RTEMS
mod that just inits/deinits the graphics mode and has
a mechanism that returns a usermode address for the video
memory (this is called framebuffer). We could or could not
use the Linux APIs for this, it doesn't really matter.
In this way, we start by porting specific chipset init/deinit
code from GRX into the RTEMS kernel. We add a very
simple address-mapping capability to map a physical
address and length into usermode. We have a simple
mechanism to set the video mode requested, in the
case that the chipset supports multiple modes. We
have a simple facility to communicate this (start by
using the Linux ioctl() to get that info and use the
same struct, if desired.
Later, we can add a graphics console, and/or integrate
text mode and graphics with RTEMS. In this way
we start with a simple solution that doesn't add any
more code than is required. Basically, it's just
like the Microwindows code that's running now,
except the init/deinit code is moved from Microwindows
to the kernel, and we get the framebuffer address from
the kernel as well.
Comments?
Greg
