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.

I take a look at some source files, but I'm afraid current wsfb driver
is still problematic.

- wsfb uses WSDISPLAYIO_LINEBYTES ioctl() and WSDISPLAYIO_MODE_DUMBFB
  flag for WSDISPLAYIO_SMODE to mmap(), but they were added after 2.0
  was branched.
- Only sparc64/dev/ffb.c supports these new ioctls, doesn't it?
  Furthermore, the ioctl on ffb.c has a weird magic number (8192).
- IMHO, these ioctls (taken from OpenBSD?) seem really stupid.
  I think we should have more generic ioctl which returns whole info
  about MI rasops(9), which includes screen size, bitmap vaddr
  for mmap(), depth, and stride etc. rather than limited ioctls for
  LINEBYTES, DUMB or so.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp