Re: Analysis On Getting Rid Of xresprobe
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
Reply to: