David Nusinow wrote: > Potential Issues: > What we can assume from all this is that the drivers will call DDC on their > own, so why should we care about having xresprobe do it during the install? > Indeed, I've checked over several of the drivers and almost all of them > do use the DDC information during the PreInit. Of the various drivers that > are special-cased in the postinst, savage, trident, tdfx, via, > siliconmotion, chips, neomagic, ati/r128, and i810 all do use DDC. s3 does > not, and nv and riva do not either (although g80 is randr1.2). So for the > vast majority of chips that are special-cased for xresprobe they do use > DDC. nv is an obvious issue, but it's actively maintained and we should be > able to get bugs fixed. For newer chips, nv will not be a problem, as it's > ported to randr1.2. >
Is riva as well maintained as nv since it's part of it? Regarding s3, it's poorly maintained. But I feel like it is still used by a bunch of people, so I hope we won't have to many people hit by possible problems... > Another potential issue is that some monitors will lie. For drivers that > are randr1.2, we can use the quirks to work around it, but for those that > aren't we're still screwed. (/me has no clue) Are you talking about the monitor quirks in the server? Why would they not work for non-randr1.2 drivers? > Finally. there's the issue of unmaintained buggy drivers. I don't have a > good solution to this problem aside from simply fixing the bugs and > exhorting our users to help us out. We can always do some sort of horrific > patching of the drivers to force them not to do DDC on certain chipsets > (some drivers actually do this anyway) so they just use the standard VGA > modes, and let the user specify the modes they need in xorg.conf. It's not > ideal, but it would get us around the problem in unmaintained drivers > that will probably die off when pci-rework finally hits Debian. Given the > way we handle things now, this would still be a win because it's the same > method we're currently using, only with less code and fewer packages. > I tend to think that all these poorly maintained drivers will have much more problems than just this if upstream continues moving towards randr/shiny things without taking care of old drivers a bit. I am afraid that only intel/ati/nv/mga will compile/work fine next year. Of course, it won't happen, but still I don't really like how things go... > I'l be ripping out the code from the postinst and running it through local > tests over the next few days. Please let me know what you guys think, if > I've missed anything, and if you have concerns or questions that we should > address before doing this. This is a very complicated problem, so please do > think about this a little and speak up if you think of anything at all. > I don't have anything against all this. I'd say let's break things now, it's better than 2 months before the freeze :) And X is so broken in sid these days anyway that it won't change much if we break it even more :) Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
