linux-mips
[Top] [All Lists]

Re: XFree86-FBDev and /dev/fb0

To: linux@cthulhu.engr.sgi.com
Subject: Re: XFree86-FBDev and /dev/fb0
From: Andy Isaacson <adisaacs@mr-happy.com>
Date: Wed, 5 Jan 2000 20:17:19 -0500
In-reply-to: <14451.59386.542889.13018@liveoak.engr.sgi.com>
References: <38726C8D.D912DF94@detroit.sgi.com> <00010516082202.01432@pingu.kastner.net> <20000105114922.B20983@mr-happy.com> <20000106013723.A14707@uni-koblenz.de> <14451.59386.542889.13018@liveoak.engr.sgi.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.

-andy
-- 
Andy Isaacson  http://web.mr-happy.com/~adisaacs/   Fight Spam, join CAUCE:
adi@acm.org adisaacs@mr-happy.com isaacson@cs.umn.edu   www.cauce.org

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