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 11:59:23
-----BEGIN PGP SIGNED MESSAGE-----
>> So maybe we should just provide a list of mmap()able address ranges,
>> probably with some additional flags which would sort of correspond to
>> PCI BARs but also work on - say - SBus?
> Maybe the new WSDISPLAYIO_GINFO should only provide an address range
> (a set of offset and size) for fb memory which can be used for
> generic raster ops.
Sure, I guess most programs that want to draw into the framebuffer
won't want to bother with card-specific registers.
> Other ranges for device dependent registers could be handled
> by another ioctl, like WSDISPLAYIO_GACCELINFO, as Allen suggested.
> (I have no particular idea how to implement the it though)
I still think there should be a new ioctl that returns all mmap()able
regions in an abstract way, so userland programs that want to access
registers wouldn't have to be bus-specific or deal with PCI BARs, this
way we could hide any address translation between CPU and (PCI-) bus -
in my opinion userland programs shouldn't have to deal with things like
I guess WSDISPLAYIO_GACCELINFO was intended for information about
acceleration functions provided by the kernel, not register space.
XFree for instance uses a bunch of 'acceleration primitives', like
screen-to-screen blits with various rasterops, line drawing, area
filling and such. We could define a bunch of these, at least
screen-to-screen blits and rectangle fills should be implemented in
some way by most accelerated console drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----