Subject: XF86 wsfb driver and wscons ioctl
To: None <firstname.lastname@example.org, email@example.com>
From: Izumi Tsutsui <firstname.lastname@example.org>
Date: 01/17/2005 21:12:20
In article <email@example.com> on source-changes
> Izumi Tsutsui <firstname.lastname@example.org> writes:
> > In article <email@example.com>
> > firstname.lastname@example.org 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
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
- 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.