RTEMS graphics

Joel Sherrill joel.sherrill at OARcorp.com
Mon Feb 7 21:17:40 UTC 2000


Erwin Rol wrote:
> 
> 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 ?

At this point in time, it is not much more than a couple of subroutine
calls in overhead.  If you look at the way device nodes are handled
in the In Memory Filesystem, you will notice that the calls boil down
to an rtems_io_XXX call.  I would like to eventually go to a model
where device drivers are dynamically registered (not indexed from a
table)
and the filesystem view of the device driver interface is closer to
the native one.  Basically make the POSIX style interface more
efficient.

I would go with the compatible path and assume that the proper way to
optimize the RTEMS version is to optimize the standards compliant 
path in RTEMS.  It benefits more people in the long run.


> - 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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985



More information about the users mailing list