Hello,

just some thoughts how we might get around the XFree86 problem on 
MacPPC.
The problems:
- XFree can't access (PCI) IO registers on macppc, only memory mapped 
stuff
- some drivers use the vgahw module to change resolution and so on ( 
tdfx for instance)
- XFree maps /dev/wscons0, not /dev/mem

IO space is handles by the PCI hostbridges on MacPPC, they just map the 
registers into memory. The exact location depends on the bridge. 
Problem: some Macs have more than one host bridge - the PM9500 and 9600 
have 2 bandits, each one has it's own IO space. So to access IO 
registers XFree must know where they appear in memory, map them and use 
memory mapped IO. Sounds easy, but isn't.
I've experimented with additional ioctl()s for /dev/pci, to find IO 
space - works, but not too well because of the following caveats:
- you can access all PCI busses through /dev/pci0, even if they don't 
share their IO space.
- it requires additional code which isn't portable
So while trying to figure out why XFree constantly complained about 
errors while mapping certain memory ranges which worked fine in any 
test programs using /dev/mem I found that XFree uses /dev/wscons0 for 
both console and framebuffer access. This device does some sanity 
checks, that's why for instance mapping 0xa0000 fails on macppc ( there 
is no VGA framebuffer! ) but works on x86.
So a possible solution is this:
Hack the ofb driver so it:
- allows mapping of IO register space - this way we can hide the 
physical address, just redirect any attempts to mmap stuff below 
0x800000 ( because according to Apple all PCI PowerMacs implement 23bit 
IO addressing ) to the corresponding host bridge's IO range. This could 
be safely extended to other architectures as well.
- optionally redirect attempts to map anything between 0xa0000 and 
0xbffff to the actual framebuffer, so vgahw may try fool around with it 
as much as it likes and doesn't need to be hacked - the redirection is 
2 lines in the ofb.c, 4 with #ifdef/#endif around it - hacking vgahw 
could be a major headache.
Allowing to mmap only the IO range that belongs to the framebuffer 
itself sounds sensible but isn't - it would need more XFree hackery, in 
this case it's way easier to let it have it's way... maybe we could 
make this optional too - in default/strict mode you can only map memory 
or IO resources that belong to the framebuffer, in 
sloppy/xfree-friendly mode you can map all the IO space of the 
corresponding host bridge. Besides that IO ranges are often much 
smaller than a page and might not be page aligned either.
Caveats: only the card which belongs to ofb0 will work. That's not our 
fault, it's xfree's - it doesn't map different devices for different 
cards.
Benefit:
- XFree would need only minimal changes to get a lot of PCish graphics 
cards to work - we'd only need to add code to mmap IO registers and 
access them through memory - the vgahw driver for instance already has 
this. The same code could work on other architectures without changes 
provided wscons would do the same mmap redirections.
- since we don't need to expose the IO register's real position in 
memory or the mechanism to access them xfree only needs to know if it 
should map and use memory access or if it should use PIO instructions.

most of the above already works on my S900 btw...

have fun
Michael