On Wed, 2010-04-28 at 10:15 +0800, Zhenyu Wang wrote: > On 2010.04.23 16:16:12 -0400, Adam Jackson wrote: > > Multifunction SDVO cards stopped working after 14571b4, and would report > > something that looked remarkably like an ADD2 SPD ROM instead of EDID. > > This appears to be because DDC bus selection was utterly horked by that > > commit; controlled_output was no longer always a single bit, so > > intel_sdvo_select_ddc_bus would pick bus 0, which is (unsurprisingly) > > the SPD ROM bus, not a DDC bus. > > > > So, instead of that, let's just use the DDC bus the child device table > > tells us to use. I'm guessing at the bitmask and shifting from VBIOS > > dumps, but it can't possibly be worse. > > > > cf. https://bugzilla.redhat.com/584229 > > I'm worried about anything depending on BIOS table info for everytime. > Or if we have a fallback to spec method way to validate if BIOS info > really makes sense? As intel_sdvo_select_ddc_bus follows spec to select > ddc bus switch, which in most case should be followed by SDVO chip too.
Well, if the BIOS uses this data table, and if output detection of SDVO devices works at BIOS time, then we can probably use it safely at runtime too. Read the BIOS and find out. > We should fix the DDC bus selection issue by check attached_output now > and after detection for getting back the real connected output type, instead > of fixed in init. The "priority order" thing in the current implementation of intel_sdvo_select_ddc_bus is presented without justification. I assume it's derived from a design document given by Intel to BIOS vendors and/or ADD2 device manufacturers. If they're following _that_ recommendation, then they would probably also be following the recommendations to put the DDC bus they choose in the child device table. (Otherwise, why would that field in the CDT even exist.) So the DDC bus listed in the CDT is correct, and we should use it. If they're _not_ following that recommendation, but there's still a CDT that looks like it describes real SDVO devices, then either: a) they're using the BIOS' DDC routines, and they put the DDC bus they're really using in the CDT, b) they're not using the BIOS' DDC routines. Option b implies non-compatibility with off-the-shelf ADD2 cards, which would defeat the whole purpose of ADD2. Option a means the DDC bus listed in the BIOS is correct, and we should use it. If there isn't a CDT that looks like it describes real SDVO devices, then we're already unable to drive them sensibly. Seriously. Read the ADD2 design documentation (it must exist, and Intel must have written it, because it's your spec). Find out what it says to do and implement it. It _has_ to work that way because that's the whole point of ADD2, to have a bunch of vendors selling peripherals that interoperate with Intel's GPUs, and have them work even in DOS. If the cards didn't do what the spec says to do, no one would buy them. If the hosts didn't do what the spec says to do, they would have only limited market. Either way it's reducing the amount of money someone can make, so the Invisible Hand says that's just not going to happen. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
