In article <08F0380B-6FB4-11D9-8201-000A95E95CCE@earthlink.net>
macallan18@earthlink.net wrote:

> > It's also provide to mmap register spaces, and an offset
> > for fb memory is not zero. I guess that was the reason why
> > OpenBSD guys introduced WSDISPLAYIO_MODE_DUMBFB for mmap op.
> Probably. On the other hand I've yet to see a program that uses offset 
> 0 to mmap() the framebuffer - XFree seems to expect BAR contents to 
> correspond to mmap() offsets though - not such a bad idea in my 
> opinion, especially on platforms where the BARs don't contain actual 
> physical addresses, like sparc64, because this way the Xserver doesn't 
> have to deal with this kind of remapping.

Maybe such programs should be fixed to use new ioctl to get
proper offset and range to map fb memory region.

> 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.
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)
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp