Bug#430545: Corrupt display when installing packages
On Thu, Nov 29, 2007 at 10:25:28AM -0800, Bryce Harrington wrote:
> Hi David,
>
> We ran into this bug on Ubuntu (e.g. LP# 127008). The xprobe.sh script
> fails on Intel laptop hardware during configure when using the -intel
> driver. This cropped up after -intel driver support was added. I also
> fixed a number of other issues in xresprobe you might be interested in,
> although I know the goal is to get rid of xresprobe entirely.
>
> The two patches that fixed this for us are:
>
> http://people.ubuntu.com/~bryce/Testing/xresprobe/xresprobe_0.4.24ubuntu5.debdiff
>
> http://people.ubuntu.com/~bryce/Testing/xresprobe/xresprobe_0.4.24ubuntu8.debdiff
>
> Basically, we avoid using xprobe.sh for -intel. doddc probe seems to
> work adequately, and where it doesn't we just let the postinst ask the
> user (this is better than corrupting out the display).
Cool, thanks. This pretty much makes sense, given that with -intel there's
been the move away from asking the BIOS for the modes, which is what
xresprobe seems to do if I'm reading it right.
I'm trying to figure out if we can just dump xresprobe all together at this
point. From my readings of the various bits that manage modesetting (and
there's a lot, so I may well have missed some very important parts) the
drivers will be doing their own ddc probe, which seems to make xresprobe
redundant. I don't fully understand how DDC, VBE, and EDID all interact yet
though, which may be a source of misunderstanding, but I can't see anything
that xresprobe does that the drivers don't do themselves through the
services that the server exposes. Randr1.2 drivers are even better of
couse, especially because we can use the quirks to deal with issues that
xresprobe would have been used for in the past.
If I don't end up ripping out our reliance on xresprobe I'll definitely
grab your fix, but hopefully we can just dump a whole lot of shell script
instead.
- David Nusinow
Reply to: