RTEMS graphics

[Erwin Rol]

This is probably more a question for the RTEMS list, but
still of interest of the microwindows list too.

What are the costs of the ioctl/open/close lib io functions
compared to the "native" RTEMS device driver interface ?
What does it do to the memory footprint ?

Wouldn't it be more apropriate to implement the FB interface ontop
of the RTEMS device driver interface ?

- Erwin


Greg Haerr wrote:
> 
> : 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: nanogui-unsubscribe at linuxhacker.org
> For additional commands, e-mail: nanogui-help at linuxhacker.org