nanogui: Technical Framebuffer proposal for RTEMS graphics
Subject:
Re: Technical Framebuffer proposal for RTEMS graphics
From:
Erwin Rol ####@####.####
Date:
5 Feb 2000 18:31:07 -0000
Message-Id: <389C794B.19D524E7@muffin.org>
RTEMS has the following device entry points;
1. initialization()
2. open
3. close
4. read
5. write
6. control
The initialization function is called by RTEMS io manager to initialize
the
driver and device. (this could set the framebuffer in some standard
mode, like
80x25 text)
the open function could be used to open a framebuffer in a certail
resolution
and colordepth (depending on the parameters passed.
The close can be used to switch back to standard mode again.
the control function could be comparable to the ioctl function.
the read/write functions could be used as pixel set/get functions.
- Erwin
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.
>
> Regards,
>
> Greg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
