> Date: Tue, 13 Aug 2013 16:21:51 +0200 > From: Egbert Eich <[email protected]> > > On Tue, Aug 13, 2013 at 01:30:00PM +0200, Mark Kettenis wrote: > > > > There defenitely is an issue with the driver here. For one thing, the > > following bit: > > > > #if defined(__powerpc__) > > vgaHWSetMmioFuncs(VGAHWPTR(pScrn), (CARD8 *)pNv->IOAddress, 0); > > #endif > > Mark, what version of the driver are you looking at? I cannot find > this line in nv_driver.c 49ee1c26ea982e. > The line above however has a different offset than what I see used > in my driver.
Hmm, was looking in the OpenBSD "xenocara" tree. Looks like this is a local modification. Sorry for the noise. > > in nv_driver.c doesn't really make any sense. Shortly afterwards, > > NVCommonSetup() gets called which overrides most of the VGA I/O > > routines and hijacks MMIOBase. What probably needs to be done is to > > make sure NVCommonSetup() also overrides ->readST01. However, there > > are potential issues with making ->readST01 use MMIO, as the timing > > Currently (at least on 49ee1c26ea982e) the idea seems to be that readST01 > is routed thru the PIO access path possibly for timing reasons. This will > however not work for PowerPC. At least not without further fixes to libpciaccess and your kernel... Yes, this is the issue I was hinting at below. > Moreover there's a bug in the libvgaHW so that IOBase does not get set > correctly at least for vgaHWSave/RestoreColormap(). This function would > require the same logic as vgaHWSave/RestoreFonts(). Or rather make sure vgaHWGetIOBase() gets called by the nv driver. I'll see if I can find some time to dust off my G5 iMac and figure out what's the best approach here. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
