Re: Analysis On Getting Rid Of xresprobe
On Fri, Dec 21, 2007 at 11:11:46AM +0200, Timo Aaltonen wrote:
> On Fri, 21 Dec 2007, Timo Aaltonen wrote:
>
>> On Tue, 4 Dec 2007, 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.
>>
>> There's a bug open about vmware (*), which seems to default to low
>> hsync/vrefresh values (or is it the server?). You end up with 800x600...
>> Maybe the driver could be patched to use 1024x768 by default? It doesn't
>> seem to use any DDC probing.
Yeah, patching the driver sounds about right. I don't know if vmware
actually supports ddc anyway.
>> * https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/172821
>
> The same happens when using a KVM that doesn't support DDC probing.
Ouch. These are an issue that I don't think anyone has a good answer to. No
matter what, it seems like these users will have to do some custom
xorg.conf writing. We'll need a proper frontend to this at some point.
- David Nusinow
Reply to: