On Mon, Jan 17, 2005 at 09:12:20PM +0900, Izumi Tsutsui wrote:
> In article <mtuhdlrfgzp.fsf@contents-vnder-pressvre.mit.edu> on source-changes
> nathanw@wasabisystems.com wrote:
> 
> > Izumi Tsutsui <tsutsui@ceres.dti.ne.jp> writes:
> > 
> > > In article <mtuvfa7fxpz.fsf@contents-vnder-pressvre.mit.edu>
> > > nathanw@wasabisystems.com wrote:
> > > 
> > > > Perhaps Xhpc and Xdreamcast should migrate to using an XF864-style
> > > > server with the wsfb driver (I brought in wsfb exactly to avoid making
> > > > another clone of Xdreamcast for an embedded box). It would be a bit
> > > > easier if we only have to maintain one "dumb framebuffer" server, and
> > > > the shadow-fb use of wsfb is good for performance - and it's nice to
> > > > have the other XF864 options and X extentions avaliable on those
> > > > platforms.
> > > 
> > > Which port uses wsfb driver currently?
> > 
> > All ports that build XF86 4 should build the wsfb driver. Looking at
> > src/x11/Xserver/Makefile.common, I believe that is i386, amd64,
> > macppc, cats, and sgimips. Of those, I think i386, amd64, and cats are
> > ineligible to use wsfb (since their VGA interfaces do not present a
> > single memory-mappable framebuffer), but macppc could use it instead
> > of Xmacppc. I do not know what the framebuffer situation is on
> > sgimips.

It's a shame to rule-out so many VGA adapters.  ISTR that on i386, there
is a 64K window at 0xA0000 that you can slide over the video memory by
either calling the VESA BIOS, or by writing registers on the VGA chip.
Can't we use the existing VM machinery to trap accesses to video regions
that aren't under the window, move the window, and then restart whichever
process made the access?  In this way you win support for a large category
of framebuffers.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933