On Friday 21 January 2005 07:21, Felix KÃhling wrote: > Am Donnerstag, den 20.01.2005, 20:43 -0500 schrieb Adam Jackson: > > > > 0x8c21 should also be moved down to 0x8a21, it seems: > > > > http://pciids.sourceforge.net/iii/?i=5333 > > Yeah, I fixed both IDs in CVS. BTW, some ProSavage names in > pciids.sf.net are a little questionable or inconsistent. Am I right in > assuming that pciids.sf.net is the upstream PCI IDs source used in the > Linux kernel? Should I report a bug only there or against the kernel > too?
I believe that's correct, ie, file bugs at pciids and they'll get pushed outward from there. > > Other savage3d woes to be detailed later... > > What woes? Something in the last few weeks has made my savage3d highly nonconformant. In 16bpp the corruption is best described as "some operations have their Y coordinate scaled down by two", so things looks squished against the top of the screen. In 32bpp these same operations are simply not on the screen at all. So, for example, my background image gets painted on half the screen in 16bpp but not at all in 32bpp. I can try for some screenshots if it'd help. Hopefully this is localizable to one XAA op. This is a dualhead card, two savages behind a PCI bridge. I see this corruption on both heads. GL works pretty well on the first head (runs glxgears, but times out in the quake3 splash screen), but not at all on the second head (times out on everything). This timeout brings down the server too after a few seconds. Oh yeah, and NoAccel makes the display totally broken, and ShadowFB crashes the server on startup for some vaguely Damage-related reason. On the flipside, my savage2k works in 2D now, so it's not all bad news. - ajax
pgp5EPW44aj5L.pgp
Description: PGP signature