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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]