Subject: Re: cleanup xsrc/xfree/xc/config/cf/NetBSD.c
To: Izumi Tsutsui <email@example.com>
From: Michael <firstname.lastname@example.org>
Date: 01/26/2005 10:15:24
-----BEGIN PGP SIGNED MESSAGE-----
>> XFree's cgsix driver ( suncg6 ) is unaccelerated but usable, at least
>> it uses the hardware cursor. Adding acceleration shouldn't be too hard
>> though, there are other, sufficiently simple drivers one could use as
>> examples and then there's Xsun.
> Maybe we should think about how mmap function should be implemented.
> If we will introduce a "new" WSDISPLAYIO_GINFO ioctl, we should not
> have WSDISPLAYIO_MODE_DUMBFB and maybe the new ioctl should provide
> an offset value to be used to mmap framebuffer memory.
> (In cgsix case, CGSIX_RAM_OFFSET should be returned)
I agree, the Xserver shouldn't have to meddle with PCI BARs, at least
not to access the framebuffer. On the other hand the drivers I've seen
so far map the framebuffer when you mmap() offsets between 0 and
As far as I can tell XFree's SBus code uses /dev/fb to talk to the
> I wonder how we should also provide mmap offsets of device dependent
> registers for acceleration, though.
Agreed again, but it would be a bit more complicated - some PCI
framebuffers use more than one BAR for registers, then there's this
nonsense with hard-wired VGA registers and so on, some need access to
PCI IO space which is different on x86 and almost everything else - for
kernel code that's not a problem thanks to bus_space_* but userland
code can't use it.
Hmm, newer cards seem to use mainly memory-mapped registers but I'm not
sure we can rely on that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----