Hello,

> > - optionally allow mapping of 0xa0000 to satisfy vgahw when it tries to
> > access the VGA framebuffer. We could return the beginning of the real frame
> > buffer here. Of course vgahw shouldn't do that on NetBSD/macppc but it would
> > be pretty complicated to decide when to allow it and when not, returning the
> > beginning of the frame buffer here doesn't do any harm.
> 
> I don't like this part.
I don't either, I consider this an ugly hack I only made to avoid any architecture-specific changes in XFree86 drivers because the decision wether we can use the legacy framebuffer isn't quite as obvious as it seems. On the other hand - if we only care for NetBSD then it should be disabled on anything SPARC, PowerPC, 68k, enabled on x86 and probably others - no idea really, that's why I didn't touch it but used a hack instead.

> It realy should not try to access the legacy frame 
> buffer memory region.
Exactly, especially if it's not enabled.

> Why is it hard to realy fix it? On the cards I looked
> at (on sparc64) the BARs pretty much made it clear that the driver should
> not access 0xa0000.
That's a longer story. The PCI VGA specification allows a hard-coded memory range and another hardcoded IO range for the legacy registers, usually these things are enabled by some bit in one of the 'official' registers. That's why PCI bridges have a 'VGA mode'.
Some VGAs mirror the legacy registers in their 'official' range ( the Voodoo3 for instance ), some don't - like most Radeons as far as I can tell.
So, to clear things up - the legacy framebuffer shouldn't be accessed on anything that doesn't use the VGA text mode, and maybe not even then. I'm not sure if x86 would be the only architecture that could safely use it so I used a workaround.

have fun
Michael