nanogui@linuxhacker.org

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