Re: Analysis On Getting Rid Of xresprobe
On Tue, Dec 04, 2007 at 11:47:27PM -0500, David Nusinow wrote:
> I've been spewing my random findings in to the irc channel for a few
> days now but I think it's time I posted a summary of where things stand on
> getting rid of xresprobe. Please do provide corrections, commentary, and
> questions.
Thanks for this write up and explaining the strategy and details about
how the system works. It appears consistent with my own thinking on
this (https://wiki.ubuntu.com/DesktopTeam/Specs/HardyHardwareDetection)
although you've dug in a lot deeper than I did. :-)
> Motivation:
> xresprobe and the parts that call it in the postinst script require a
> knowledge of what driver we're working with, which in turn requires
> discover. So in order to get rid of discover we either need to get rid of
> xresprobe or slim it down substantially. Additionally, it's a bunch of
> code that really papers over actual deficiencies in the various drivers,
> and our goal should be to get the drivers fixed rather than work around
> them.
xresprobe also has suffered from lack of maintenance attention.
Fortunately I was able to get a bunch of the issues we knew about in
Ubuntu fixed up for Gutsy, the basic stuff in it is duplicating code in
X; the non-basic in it is papering over real issues, as you say.
> How modesetting works in the pre-randr1.2 world:
> The server provides the necessary services to do a DDC probe. It doesn't
> actually run the DDC normally though. Instead, it relies on the driver to
> tell it to run a DDC probe, and it passes the information back to the
> driver as a monitor structure. Initially, the server will pass the driver
> all the standard VGA modes and settings so the driver will always have
> some sort of modes to deal with. Most drivers will tell the server to do a
> DDC probe normally, so they don't have to rely only on the standard modes.
There's one additional twist with EDID in that we have certain
situations where xresprobe experiences EDID read fails. In these cases,
read-edid seems to fail as well, and I think the problem is also
affecting X's EDID reading. Some simply chalk it up to lying hardware,
but as this seems to be a relatively common issue, I think it'd be worth
getting a deeper understanding. In reading the EDID spec, I see it's
gone through a number of revisions (1.0, 1.1, 1.2, 1.3, and 2.0), and
has an extension mechanism, and I'm suspicious if the failures are due
to either the code lacking support for one of the versions, or getting
messed up by extensions or something. Or perhaps the monitor is failing
to implement the EDID protocol correctly. Or maybe the graphics card is
corrupting the read somehow. Monitor cable adapters, kvms, and the like
have also been known to louse up the EDID info.
Whatever the case is, this is an area where xresprobe and postinst would
catch and try to handle (not always with good results, but better than
nothing). Xorg may be able to handle some of these cases better, but
it's an area we'll need to keep a strong eye on.
> 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. However, given that xresprobe uses the exact
> same information as the driver itself I fail to see how xresprobe would be
> of any help here.
Right; if we need workarounds for these cases, there's no reason those
workarounds shouldn't be pushed into xorg itself.
> 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.
With how fast core X has moved with major architectural changes, this
seems to be becoming a common issue with the less well maintained
drivers. This is particularly hurting with embedded and educational
users, who seem to be the biggest place where these drivers show up, and
when they do, they seem to be among groups that lack the technical
resources to participate in the driver work, so the issues end up
falling on the packager's desk. If the issues are just minor bugs,
those are probably fixable, however stuff like xrandr, pci rework, and
the like seem like non-trivial efforts, and hard to do without access to
the hardware (and sometimes hard even when you do have it).
I'm concerned about this because the way things are scaling, this is
going to become a larger and larger sore spot for all of us. Maybe we
need to start (threatening to?) deprecate extremely out of date drivers,
or become more proactive at recruiting driver maintainers, or even just
publish task lists for them?
> 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.
Great, I'll be happy to help test on the hardware I have, and send
patches where I can.
Bryce
Reply to: