On Sat, Nov 09, 2002 at 03:13:10PM -0800, Chad Carr wrote: > "Branden Robinson" <branden@debian.org> wrote: > > > (--) PCI:*(1:0:0) S3 unknown chipset (0x8c2e) rev 5, Mem @ 0xffe80000/19, 0xec000000/26, 0xe8000000/26, 0xe6000000/25, BIOS @ 0x000c0000/16 > > > > I'd say the above is a good sign that your chipset isn't supported by > > XFree86 yet. > > Yes. But like I said, I am working with the upstream author to get > the bug fixed. The version of the savage driver in the unstable > package is 1.1.23t. I don't know how this works, but maybe getting > 1.1.27t (the at this time fictional next release which fixes the > gradient drawing issue) into Debian unstable will do the trick. I don't think you understand how I work on my Debian packages, or what (non-native) Debian packages really are. XFree86 4.2.1 doesn't support your chipset (as far as I know). You therefore cannot expect that Debian's XFree86 4.2.1 packages will, either. I include updates to drivers and miscellaneous other features from CVS HEAD and other sources to serve two purposes: 1) Make my life easier, by including bug fixes for things like hangs and segfaults -- this reduces the number of bug reports I get. 2) Make the lives of my users easier, because they don't have to suffer as many hangs and segfaults. However, the 2nd purpose must take a back seat to the first or I will be unable to work efficiently on my packages and little or nothing will get done. I have several recommendations: 1) continue working with Tim Roberts to get your chipset working well, and use the driver binaries he compiles; or 2) get patches from Tim Roberts and produce a patch that I will be able to incorporate into my 4.2.1 packages; I will *consider* such a thing, and I never guarantee that I will accept any particular patch that is sent to me. Some patches are just too large and/or disruptive to the rest of the codebase. Or 3) wait for XFree86 4.3.0 to be released and packaged for Debian I don't own any Savage hardware. I can't test these things. I am reluctant to introduce changes into my XFree86 packages that I cannot test, because I don't want to cause regressions. When someone wants an updated version of an XFree86 driver in the Debian packages, they generally have to do step 2) above, build the XFree86 packages for themselves with the patch applied, and test the result to make sure it works as it should. Yes, it's work. But it's also part of being respectful of the upstream author's release policy and release schedule. In my opinion it is reckless to just package up CVS HEAD every week or so, or to indisctiminately pull patches from CVS HEAD (which is just about the same thing). Much grief in Debian has been caused by this sort of recklessness, and I do not wish to contribute to it. Therefore, I hope you will understand that I do not react well to being told to blindly pull patches from anywhere into my packages. Support for the latest video hardware (or for video hardware of any age, really) is indeed important. But it's not *the* single most important thing, especially when that "support" is unstable or immature. > The MTRR bug is already fixed upstream, it just needs other work to > make it perfect. Well, why don't we revisit this issue after it *is* perfect? -- G. Branden Robinson | Debian GNU/Linux | // // // / / branden@debian.org | EI 'AANIIGOO 'AHOOT'E http://people.debian.org/~branden/ |
Attachment:
pgpaSON6zsWra.pgp
Description: PGP signature