nanogui: Technical Framebuffer proposal for RTEMS graphics


Previous by date: 5 Feb 2000 19:36:26 -0000 Re: RTEMS graphics, Greg Haerr
Next by date: 5 Feb 2000 19:36:26 -0000 Re: Technical Framebuffer proposal for RTEMS graphics, Greg Haerr
Previous in thread: 5 Feb 2000 19:36:26 -0000 Re: Technical Framebuffer proposal for RTEMS graphics, Greg Haerr
Next in thread: 5 Feb 2000 19:36:26 -0000 Re: Technical Framebuffer proposal for RTEMS graphics, Greg Haerr

Subject: Re: Technical Framebuffer proposal for RTEMS graphics
From: Erwin Rol ####@####.####
Date: 5 Feb 2000 19:36:26 -0000
Message-Id: <389C88A1.7637B3AE@muffin.org>

Greg Haerr wrote:
> 
> : A small difference is how the access to the driver is made.
> : In your proposal, many ioctls() calls to do different things.
> :
> : The one that I proposed the driver would provide
> : a table with the entry points for the services provided
> : by the driver.
> :
> The addresses returned by the kernel aren't valid for
> user mode routines to call directly in RTEMS, right?
> They certainly aren't in Linux.  That's why I suggest
> ioctl.

I believe everything is flat without protection in RTEMS ?
but it isn't in Frank's PK, and we might want to make a interface
that works on both ?
 



> 
> Regards,
> 
> Greg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

Previous by date: 5 Feb 2000 19:36:26 -0000 Re: RTEMS graphics, Greg Haerr
Next by date: 5 Feb 2000 19:36:26 -0000 Re: Technical Framebuffer proposal for RTEMS graphics, Greg Haerr
Previous in thread: 5 Feb 2000 19:36:26 -0000 Re: Technical Framebuffer proposal for RTEMS graphics, Greg Haerr
Next in thread: 5 Feb 2000 19:36:26 -0000 Re: Technical Framebuffer proposal for RTEMS graphics, Greg Haerr


Powered by ezmlm-browse 0.20.