Re: Analysis On Getting Rid Of xresprobe
On Wed, Dec 05, 2007 at 08:45:26AM +0100, Brice Goglin wrote:
> 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?
I can't really tell. It seems like it's pretty much in maintainance mode.
Only the g80 bits of the nv driver were ported to randr 1.2, for instance.
> 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...
Yeah, my hope is that for most people the standard vga modes will work
fine, and they can manually configure other resolutions in xorg.conf if
necessary. Ideally someone with the hardware and time will pop up and port
it to randr 1.2 (which doesn't really look so terribly difficult) but
that's probably just wishful thinking.
> > 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?
The paths in the server that take quirks in to account are exclusively via
the randr 1.2 interfaces. That interface allows the server to hide some
things from the drivers and allows you to work around the issues in the
server. With the old interface, the driver gets the DDC info directly and
can do what it wants with it. We might be able to patch the server to make
it work, if it turns out to be necessary, although it'd be kind of ugly.
> > 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...
Yeah, this is really unfortunate. As it is though, we really need upstream
maintainers for these drivers.
> > 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 :)
My thoughts exactly :-)
- David Nusinow
Reply to: