Hello,

> > Maybe we should add an ioctl that
> > returns the framebuffer offset and size
> 
> Yes, we should do that. And maybe include the current graphic mode
> information as well (colorformat, stride, ...)

An ioctl to read informations about framebuffer geometry, organization
and so on exists, maybe it should be extended. Or another ioctl uses
what this one uses with additional fields for offest and size.

> But isn't that about the end of the story?
> Everything beyound the mapping will be device dependend anyway.

Depends, if you only mess around in the framebuffer and don't try to
access anything else you're still pretty much hardware independent.
Another problem with the BAR method is that many graphics boards offer
different views on the framebuffer, in this case the mach64 offers two -
one with endianness conversion in the 2nd 8MB of the aperture, one
without in the 1st 8MB ( or was it the other way around? Anyway,
getting the wrong one would cause confusion ), others offer RGB and BGR
views or, like the ffb, something more complex.

have fun
Michael