nanogui: RTEMS graphics
Subject:
Re: RTEMS graphics
From:
Rosimildo daSilva ####@####.####
Date:
5 Feb 2000 18:05:39 -0000
Message-Id: <200002051755.JAA26183@www2.xoommail.com>
Greg Haerr wrote:
> 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.
>
After read all the messages posted in the last couple of days,
I guess everybody is coming to the same conclusion that,
FB as it is on Linux, it too complicated and overkill for an
embedded environment.
Let's keep this very simple. We need to define an interface
for the graphics driver to match MicroWindows requirements.
My first cut for that is:
I am going to write this as something similar to IDL:
interface fb_for_microwindows
{
/* this function returns all information regarding the
* display. Something similar to the struct fb_var_screeninfo
* of linux FB implementation
*/
fb_get_screen_info()
/* Selects the mode of the graphics subsystem */
fb_set_mode()
/* returns the mode of the graphics subsystem */
fb_get_mode()
/* Get the UserMode address of the framebuffer device */
fb_get_fbaddr()
/* color scheme */
fb_get_pallete();
fb_set_palette();
/* initialization of the graphics mode */
fb_init()
fb_exit()
/* Basic operational services of the graphics subsystem */
fb_drawpixel()
fb_readpixel()
fb_drawhorzline()
fb_drawvertline()
/* Tell the driver that the "buffer" is dirty, and an update to the
* real device, maybe a serial/parallel LCD, whatever is required
*/
fb_dirty()
};
All we have to do is define the signature and data-structures
required by this functions.
On the driver side, it needs to provide a ioctl() that returns
the interface that MicroWindows would use. It is basically a
table with the pointers to the functions implemnted at the kernel level.
open( "/dev/fb_svga", .. );
ioctls( fd_no, FB_GET_INTERFACE, &driver_table );
To make a comparation to C++, the driver table returned would be like a
pointer to C++ instance with a public interface as define above.
Am I in the right track here ?
People with more "graphics expertise", please give some advise on
how to define the signature for these functions.
Rosimildo.
Thanks,
Rosimildo
______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com
