Before I get into the meat of my reply, let me first say that I'm still on the lower end of the learning curve myself as regards the guts of MXM and display types, so I will apologize now if I make any bone-headed mistakes (or have made them already) and would welcome assistance from those who know better. Also, if my responses seem a little too aggressive (particularly when they may be wrong), please don't take it personally; it's a bad habit that I've had for so long that, at this point, there's little hope for grinding off all of the rough edges.
Also, I don't have a 9261 available that I can actually poke around in, so I cannot actually go and look at the motherboard and the cards or poke around in the code to see if any of my suspicions are correct - it would be very useful if someone who does have a 9261 available would try to get into the guts of the system, look at the physical structures on the motherboard and card(s), and try to get a dump of the VBIOS, SBIOS, and/or EDID data, including specs on the display and any registry data. If/when I come up with a test that could be performed, I will try to ask someone else to run it (and I'll try to give enough detail to make that feasible).
With that, my thoughts:
First, you only list the software specs NVidia has released, not the physical specs (which are important in this case because the problem with the 9261 is not just software-based). NVidia released at least two mech. specs this year, version 2.1 (Sept. 07) and version 2.1A (Nov. 07). Second, you also don't list the 2.0 version of the software specs, which were released between the 1.9 version and the 2.1 version (current version, rel. Sept. 07).
Second, from what I can glean from Justin Nolte's posting regarding the problem, the root of the problem is that NVidia decided to only provide modules that supported displays with built-in EDID, and that do not support so-called EDID-less displays.
The effect of that is that the data regarding the display's characteristics
must be retrieved from an EDID unit on the display, and can no longer be retrieved from the system BIOS or a separate ROM chip on the system board - in other words, an EDID-less display can no longer be used with an MXM-compliant videocard.
That is contrary to the published specifications, which explicitly contemplate the use of EDID-less displays; for example, on page 5 of the 2.1 version (rel. 9/07), the summary of required software support states "Func 2 is required if an EDID less internal flat panel is required." Obviously, that statement is now rendered moot if an EDID-less display cannot be used in any case for other, non-Func 2, reasons.
Second, with respect to the software specifications, the addition of MXM-IV does not appear to be relevant since there is not a single reference to MXM-I, II, III, or IV (nor to HE or non-HE) in the software specs.
I think, however, that I may have spotted the gist of the current Clevo problem on my last read-through of the current software specs (version 2.1, rel. 9/07). On page 17 of the current version, under the heading "Using a Serial ROM to Access the MXM v 2.1 Structure," the software spec states as follows: "In systems in which more than one MXM v 2.1 module may be supported, the serial ROM must not be used. Implementation of the INT 15h and ACPI methods is required in this case as this provides a means to directly distinguish the data for different modules."
That suggests to me that Clevo's old motherboards used the separate ROM method for providing the MXM display data to the videocards, and that for whatever reason the Int15h and ACPI system methods are not functional on those motherboards.
Another possible clue can be found on page 5, where the spec states that, because the VBIOS may need to be fully functional before OS or driver loading, and because the MXM card may have to act as a secondary display adapter, "Int15h methods alone are insufficient. Both the Int15h and ACPI interfaces are required to be supported when system methods are used for output and DDC selection."
Since, by hypothesis, the 9261 must use an EDID-less display (otherwise there wouldn't be a problem in the first place), the fact that a separate serial ROM cannot be used in multiple videocard setups (i.e., in SLi, which the 9261 is intended to support), when put together with this statement, implies that the root of the problem might lie with the inability of the current 9261 motherboard to provide both the Int15h and ACPI interfaces as required by the current spec.
Since the new version 3.0b of the ACPI spec adds the new support features for MXM (and not version 3.0a as referenced on page 24 of the 2.1 software spec, this suggests that the problem may lie with the inability of the 9261's motherboard to fully support the new ACPI specifications (i.e., the 3.0b version).
One way to test this might be to go looking for references to the GUID that is used under WMI to get user-space access to the new MXM info. On page 26 of version 2.1 of the MXM software specifications, the following GUID is listed for WMI MXMX methods: "{F6CB5C3C-9CAE-4EBD-B577-931EA32A2CC0}"
Thus, it might be useful if someone with a 9261 did a search in their Windows registry to see if that GUID is registered or not. If it doesn't show up, that might suggest that the root of the problem here lies with a lack of support for ACPI version 3.0b.
This, if true, may shift some of the blame from NVidia to Clevo, but only if it was already clear long before September 2007 (when the current software spec was released) that this sort of issue would crop up with systems using multiple MXM videocards. However, the facts that (a) none of this appears in the only other released version of the software specs (rel. in 2004)
and (b) these problems don't crop up in systems with SLi'd 8700s or earlier cards, suggest that it very well may not have been clear prior to the time Clevo made the revisions to the current 9261 motherboard (which must have been finalized in September, or earlier, since that version was released at the very beginning of October) that they would also have to revise the degree of ACPI support on the motherboard in order to support the 8800Ms.
Also, this suggests, if true, that the current 9261 may, in fact, support a single 8800M card, because the requirement to use both Int15h and ACPI v.3.0b only applies to systems with multiple MXM cards (i.e., systems with SLi'd 8800Ms).
However, in that instance, the current 9261 motherboard may also suffer from the same wake-from-sleep problems the current 5791 is supposed to have with the 8800M. Since ACPI is integral to the various wake and sleep states, the fact that the 5791 cannot adequately support an 8800M without having sleep problems suggests that the basic issue of Clevo's incompatibility with the 8800M stems from a lack of support for the 3.0b version of the ACPI standards.
Click to expand...
Problems? See this thread at archive.org.
