nanogui@linuxhacker.org

: Let's keep this very simple. We need to define an interface
: for the graphics driver to match MicroWindows requirements. 
: 
: interface fb_for_microwindows
: {

Great.  Almost perfect.

:     /* Selects the mode of the graphics subsystem */
:     fb_set_mode()

This may not be needed, it could possibly be merged
with fb_init().

: 
:     /* Get the UserMode address of the framebuffer device */
:     fb_get_fbaddr()

This doesn't need another entry point, it can be returned by
the fb_get_screeninfo() above.  But that means that
you'll make a kernel->user memory mapping just by opening
the device.  You might want to have another entry point,
like this one, do that.

:     /* Basic operational services of the graphics subsystem */
:      fb_drawpixel()
:      fb_readpixel()
:      fb_drawhorzline()
:      fb_drawvertline()

Drop these.  They definitely don't belong in the kernel, or you'll
have to include drivers for every framebuffer type.  That's
what Microwindows is for.

: };
: 
: All we have to do is define the signature and data-structures 
: required by this functions.

Yep.  Take a look at /usr/include/linux/fb.h for the main
ones to do with fb_get_screeninfo.


: 
:   open( "/dev/fb_svga", .. );

This should probably just be generic, i.e. /dev/fb0.



:   ioctls( fd_no, FB_GET_INTERFACE, &driver_table );

No, here just use
    ioctl(fd, FB_GETSCREENINFO, &table);
or
    ioctl(fd, FB_GETPALETTE, &table)
etc for each function above.  The kernel driver in RTEMS
cases on the FB_XXX value under the ioctl switch.


: 
: 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.
: 
Don't bring pointers to kernel driver functions into user mode, just
case on ioctl values as explained above.

Regards,

Greg