On 26 Apr 2002, Jarno Paananen wrote:
> Hi,
>
> a recent change in riva_hw.c, namely version 1.30 broke clock
> calculation for my GeForce 3 (Elsa Gladiac 920).
>
> The change was:
>
> @@ -1982,8 +1982,8 @@
> chip->RamBandwidthKBytesPerSec = 1000000;
> break;
> }
> - chip->CrystalFreqKHz = (chip->PEXTDEV[0x0000/4] & (1 << 22))
> ? 27000 :
> - (chip->PEXTDEV[0x0000/4] & (1 << 6))
> ? 14318 :
> + chip->CrystalFreqKHz = (chip->PEXTDEV[0x0000/4] & (1 << 6))
> ? 14318 :
> + (chip->PEXTDEV[0x0000/4] & (1 << 22))
> ? 27000 :
> 13500;
> chip->CursorStart = (chip->RamAmountKBytes - 128) * 1024;
> chip->CURSOR = NULL; /* can't set this here */
>
> On my card the chip->PEXTDEV[0x0000/4] has both 22nd and 6th bit
> set so it used to select 27000, which worked fine. Now it selects
> 14318 which causes clocks to be half of the intended value and
> can't be displayed on my monitor. Reverting this change fixes
> it. It seems the logic still has some faults as the log message
> indicates this change was made to fix it on NV17...
I assume you mean the opposite of what you just said. It now
selects 27000 and used to select 14318. There is no 27000 clocks
on NV20 and I was told that bit 22 shouldn't be set. I will have
to investigate.
>
> Completely another thing I found out when checking out the video
> overlay support is that in NVAllocSurface, parameter id is not used
> for anything. On the other hand surface structure has a field
> called id, which is not initialized, but is given to
> NVPutOverlayImage from NVDisplaySurface. It doesn't use it for
> anything though. Anyway, I think the surface->id should be
> initialized in NVAllocSurface, which it isn't now. The patch to do
> that is attached.
>
OK, I've applied that one.
MArk.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
