Analysis On Getting Rid Of xresprobe
Hi everyone,
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.
---
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.
---
Quick terminology:
DDC: protocol to talk to the monitor
EDID: block of information received from the monitor
---
What xresprobe does:
It uses laptop-detect to see if we have a laptop. It then makes a few
decisions based on this, as well as our architecture and the driver we're
checking against. Ultimately though, it almost always ends up just doing a
DDC for the EDID info in the monitor, and then printing that information
out so it can be read back by the postinst script. To do DDC it carries its
own forked copy of a program to read the DDC info.
---
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.
---
How modesetting works in the post-randr1.2 world:
All the same services are provided by the server so that legacy drivers
continue to work. Additionally, there is a new API that allows the driver
to set things up a little more simply. The driver calls xf86OutputGetEDID
and xf86OutputSetEDID, which calls the same services that were present in
the pre-randr1.2 world. randr1.2 essentially divides the information
differently, splitting up the CRTC and Output. You can check out the doc in
hw/xfree86/doc/README.modes for a wonderful overview.
---
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.
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.
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.
---
Final Analysis:
I think we can dump xresprobe, provided that we also have the postinst
stop writing the resolution and sync information to xorg.conf. We should be
able to work around any serious problems in the drivers themselves or get
them fixed upstream. Even though this is probably the most problematic part
of the postinst to stop writing, I think it'll benefit us in the long run.
Upstream is obviously intersted in getting modesetting right within the
drivers themselves, so we should be able to lean on them for support.
---
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.
thanks for reading,
David Nusinow
Reply to: