nanogui: Images resolution
Subject:
Re: Images resolution
From:
Chris Johns ####@####.####
Date:
28 Jan 2000 23:29:03 -0000
Message-Id: <389223AA.655DD6C@acm.org>
Alex Holden wrote:
>
> On Fri, 28 Jan 2000, Rosimildo daSilva wrote:
> > Thanks for your straight answer. This was the type of answer
> > that i was looking for. I trust your knowledge of graphics
> > stuff. I guess FB is the right answer for RTEMS in the long
> > run.
>
> I wouldn't bother trying to hack the Linux Framebuffer code directly into
> RTEMS if I were you, but the general Framebuffer as a mmapable file
> concept is a good idea. If you don't want to support mmap() yet, then just
> have a driver independant device file you can do ioctl()s on to handle
> locking and find out and set things like the resolution and colour depth,
> and read the address at which you can find the hardware framebuffer.
>
This would be a nice solution. RTEMS supports this file system concept.
For RTEMS I would also like to see the idea of a "virtual framebuffer".
For example I am considering connecting a small low cost parallel port
LCD graphics display. MicroWindows would write to a "virtual
framebuffer" using existing code (I hope :)). The LCD driver needs to be
told the framebuffer is dirty and look for changed screen sections and
flush them to the display. Where would this be added ?
--
Chris Johns, ####@####.####
