-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

>> 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 
this.
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.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQffMa8pnzkX8Yg2nAQJOrQf/b+hbW4nSXaI9ZlRPPyK8RXbxMQ6ZCw2w
wkGllsvgrhMTIE84fkwTsXX44eLtGEA7q26gRSdu27kO/Eva3/SpPmc64969Pl8V
K6Q3rXzfRwYtOK7s4mX+PEf1kOTxb4VVUBBKaDL6t7Pe9JXN9kFeg6qRk/YTCroR
N4qPRNjjL1e8VM3r0be5fYB1SV8+h2aRqFpFuMKn8sCmwmccK1T9C8wTyoie2LRH
T+aQITtdjPytgK7VV0gOhI9HAy0sMTb1eCX8GNXcc8cgSdsCd9tTMQUzToXWkrtR
b9jWHkg/mo+6S4kaCG5kN7nLBdWN0BNPcaTITULORl3nYlF52lJbWg==
=yUWU
-----END PGP SIGNATURE-----