linux-mips
[Top] [All Lists]

Re: XFree86-FBDev and /dev/fb0

To: Andy Isaacson <adisaacs@mr-happy.com>
Subject: Re: XFree86-FBDev and /dev/fb0
From: Ulf Carlsson <ulfc@cthulhu.engr.sgi.com>
Date: Wed, 5 Jan 2000 17:27:33 -0800 (PST)
Cc: linux@cthulhu.engr.sgi.com
In-reply-to: <20000105201719.A16821@mr-happy.com>
Sender: owner-linuxmips@oss.sgi.com
> On Wed, Jan 05, 2000 at 04:55:22PM -0800, William J. Earl wrote:
> > Ralf Baechle writes:
> >  > A system with the XL graphics will never have a real working framebuffer.
> > 
> >      Since the real graphics framebuffer is in memory which is not 
> > addressable
> > by the processor, the only way to fake a CPU-addressable framebuffer is
> > to reserve a chunk of main memory, and then DMA the contents into the
> > real framebuffer when the CPU-addressable framebuffer is changed (or
> > every vertical refresh interval, if there is no way to tell when the buffer
> > changes).  You could probably play with the PTE valid and mod bits to detect
> > when pages are changed.  It would in any case be relatively inefficient
> > compared to using the graphics pipeline as intended, since uncached writes
> > to the graphics pipeline are pretty cheap (better than cached or uncached
> > writes to large areas of main memory).
> 
> XFree86 has builtin support for this mode of operation in the latest
> development snapshot (3.9.17).  They call it ShadowFB.  Of course that
> would only work in X, not on console.  Apparently it's fairly easy to
> write a driver that supports ShadowFB; all you have to be able to do
> is update a rectangular area of the screen on demand.

Yeah, and that's what I tried to get working but I ran into other problems with
the dynamic loading of X modules and stuff so I never got the chance to
concentrate on the driver.  I have the early stages of a driver around though.

Ulf


<Prev in Thread] Current Thread [Next in Thread>