WMI is a dead end

Just as a quick update, we've tried yesterday to get access to the device specific methods of the both graphics cards through the WMI interface wrapper, but it failed. Some methods of the WMI wrapper work, but there's a stupid bug in the DSDT program that prevents executing the really interesting stuff. For the technically interested ones, this is the head of the 'WMMX' method in device WMI1:

  Method (WMMX, 3, NotSerialized)
 {
   CreateDWordField (Arg2, Zero, FUNC)
   ...

Further down we find this:

   If (LEqual (FUNC, 0x4D53445F))
   {
     CreateField (Arg2, Zero, 0x80, MUID)
     CreateDWordField (Arg2, 0x10, REVI)
     CreateDWordField (Arg2, 0x14, SFNC)
     CreateDWordField (Arg2, 0x18, PARM)
     If (LEqual (Arg1, 0x10))
     {
       Return (^^OVGA._DSM (MUID, REVI, SFNC, PARM))
     }

This code block just splits Arg2 of method WMMX into sub arguments and calls the '_DSM' method of the built in graphics adapter. But there we find:

  If (LNotEqual (Arg0, Buffer (0x10)
  {
    /* 0000 */    0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D, 
    /* 0008 */    0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4
  }))
  {
    Store (0x80000002, RBUF)
    Return (Local0)
  }

So, the code in WMMX copies the first 128 bit of Arg2 into MUID, which in '_DSM' is compared to the byte array above. But wait, isn't FUNC also created by copying a DWORD from the start of Arg2? Hmmm. So, obviously the start of Arg2 cannot contain the function signature ('_DSM') and a MUID starting with 0xa0, 0xa0, 0x95 ... Consequently, every access to this method fails and just returns 0x80000002 to the caller. This part of the ACPI DSDT is just broken.

Now, obviously this is not the path Vista is using, unless they are replacing the original DSDT with something that works (and I cannot believe that). Maybe through a BIOS update? Does anybody know about graphics card related problems with Vista that are solved through a BIOS update? Or can some kind soul provide a DSDT dump while the system runs Vista?

Anyway, I'll continue my quest over the weekend, weather will not be good anyway. I think it should be possible to access the _DSM method of the chipset graphic card directly using its path, via acpi_evaluate_object(). We're going to try that next, stay tuned.