nanogui: Technical Framebuffer proposal for RTEMS graphics
Subject:
Re: Technical Framebuffer proposal for RTEMS graphics
From:
Rosimildo daSilva ####@####.####
Date:
5 Feb 2000 18:43:06 -0000
Message-Id: <200002051832.KAA04356@www2.xoommail.com>
"Greg Haerr" wrote:
> In looking at microwin/src/drivers/fb.c, I have identified the following few
> entry points as the minimal set of functionality for Microwindows
> to run on ANY framebuffer kernel. I suggest that these functions, with
> a suitable API, be implemented in RTEMS, as a very simple first round.
>
> 1. open() of framebuffer device
> 2. ioctl() to get framebuffer info:
> xres, yres, bpp, linelen, type, visual, size
> type is packed pixels or planes
> visual is truecolor or pseudo color
> type/visual is used to identify which fblinXX.c should be used for drawing
> by Microwindows. not a big deal.
> size - size of framebuffer
>
> 3. mmap() call to map the framebuffer fd and size into this process' address
> space. This
> could be replaced with the open framebuffer automatically being mapped into
> the process space, and just returning its virtual linear address in 2) above, if
> mmap()
> isn't around. Alternatively, the ioctl above could return the physical address
> of video, and a separate new physical address -> virtual linear address system
> call could be added to the kernel. This is slightly simpler than mmap().
> This item is the hardest part for RTEMS, and requires the most thought.
>
> 4. ioctl to switch to graphics mode.
> 5. ioctl to get the current palette, which is saved. (not required for
> truecolor)
> 6. ioctl to set the Microwindows palette at init. (not required for truecolor)
> 7. VT switching code, which is complicated, and should be left out in this first
> version.
>
> <thats it, Microwindows programs can now run with this little information>
>
> 8. On Microwindows exit, an ioctl() to reset the palette and an ioctl() to
> switch back to text mode, followed by a munmap() and close(fb).
>
>
> It doesn't have to be complicated.
>
Greg,
I've just posted a message with an interface similar to yours.
A small difference is how the access to the driver is made.
In your proposal, many ioctls() calls to do different things.
The one that I proposed the driver would provide
a table with the entry points for the services provided
by the driver.
I have no preferences for one way or the other.
The good thing is that we all agree that a very
simple interface is required.
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
