Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100928 Firefox/4.0b7pre Driver version and date are empty in the graphic section of "about:support" page.

Do they show up with gfxbot?

Ftr, "Adapter RAM : Unknown" is bug 591787.

FYI, gfxInfo's mDeviceID gets the following string on my system: PCI\VEN_1002&DEV_4150&SUBSYS_0200174B&REV_00

I tried creating a patch by reference to the following document: "Adding a PnP Device to a Running System" http://msdn.microsoft.com/en-us/library/ff540535%28v=VS.85%29.aspx approach: 1. Get "Driver" value from HKLM\System\CurrentControlSet\Enum\<enumerator>\<deviceID>\<instanceID>. 2. Open HKLM\System\CurrentControlSet\Control\Class\<DriverValue> and get DriverVersion and DriverDate. Worrisome point is Microsoft has listed the registry's Enum branch for debugging purposes only. When using SetupAPI, it seems that we can avoid the direct access of Enum key, but I think Windows CE 6 may not include SetupAPI. :-(

(In reply to comment #6) I think this approach needs the instance ID of device which displays primary desktop, but I haven't found a way to get it... > approach: > 1. Get "Driver" value from > HKLM\System\CurrentControlSet\Enum\<enumerator>\<deviceID>\<instanceID>.

(In reply to comment #6) > Worrisome point is Microsoft has listed the registry's Enum branch for > debugging purposes only. > When using SetupAPI, it seems that we can avoid the direct access of Enum key, > but I think Windows CE 6 may not include SetupAPI. :-( Do we support Windows CE at all? Does it matter for the present purpose of checking desktop graphics cards drivers?

(In reply to comment #8) > Do we support Windows CE at all? Does it matter for the present purpose of > checking desktop graphics cards drivers? I don't own Windows CE and fixing this bug is beyond my knowledge...

I wouldn't worry about supporting Windows CE at all. If needed we can always #ifdef stuff out.

So, this bug is really important and we should review Tetsuro's patch. Will do ASAP...

My patch has a bug. I think, it is necessary to insert the following line before calling RegQueryValueExW: dwcbData = sizeof(value);

Indeed, I had to do something similar to fix another bug recently (bug 621393) Will apply this fix to your patch. Let me keep the r? flag, it ensures I dont forget to review.

When unused device's informations are left in the registry's Enum branch, my current approach may get a wrong information. So I submit a new patch using Setup API and obsolete my current patch.

Comment on attachment 505046 [details] [diff] [review] use Setup API rv1.0 The patch looks good!

Comment on attachment 505046 [details] [diff] [review] use Setup API rv1.0 Handing this over to Jeff who has more comments.

Comment on attachment 505046 [details] [diff] [review] use Setup API rv1.0 for our sanity, please check all 4 function pointers using this if condition (w && x && y && z): >+ if (setupGetClassDevs) { >+ if (devinfo != INVALID_HANDLE_VALUE) { >+ HKEY key; >+ LONG result; >+ WCHAR value[255]; >+ DWORD dwcbData; >+ SP_DEVINFO_DATA devinfoData; >+ DWORD memberIndex = 0; >+ >+ devinfoData.cbSize = sizeof(devinfoData); reference mark A >+ while (setupEnumDeviceInfo(devinfo, memberIndex++, &devinfoData)) { >+ if (setupGetDeviceRegistryProperty(devinfo, please align arguments to first argument, i.e. ^ here: >+ &devinfoData, >+ SPDRP_DRIVER, >+ NULL, >+ (PBYTE)value, >+ sizeof(value), >+ NULL)) { this should be split into an NS_NAMED_LITERAL_STRING (at reference mark A above) and an nsAutoString here. >+ nsAutoString driverKey(L"System\\CurrentControlSet\\Control\\Class\\");

Comment on attachment 505046 [details] [diff] [review] use Setup API rv1.0 A couple of quick comments (I haven't looked into too much detail yet): - Please drop the WINCE stuff. - It would be nice if the SetupAPI calls were commented more. It's not that easy to follow what they're doing. - Does this cause us to load setupapi.dll when wouldn't otherwise? and will it hurt startup performance?

* Checking all 4 function pointers of SetupAPI. * Aligned arguments to first argument. * Dropped the WINCE stuff, except the part of "#include <setupapi.h>". * Added comments about SetupAPI calls. I measured elapsed time from LoadLibraryW to FreeLibrary, using QueryPerformanceCounter. Tested under x86 Windows 7 (CPU: Athlon X2 5050e, HDD: IC35L090AVV207-0, Mem: 2GB): cold startup: 2.89452 ms 2.82560 ms 2.84988 ms 2.82544 ms 2.84692 ms hot startup: 1.56996 ms 1.55084 ms 1.55232 ms 1.52980 ms 2.81968 ms I got almost the same results under Windows 2000 SP4.

Comment on attachment 505416 [details] [diff] [review] use SetupAPI rv1.1 >+#ifndef WINCE >+#include <setupapi.h> >+#endif one WINCE left. >+ /* create a device information set composed of the current display device */ >+ HDEVINFO devinfo = setupGetClassDevs(NULL, >+ mDeviceID.BeginReading(), this should use PromiseFlatString(mDeviceID).get() >+ NULL, >+ DIGCF_PRESENT | DIGCF_PROFILE | DIGCF_ALLCLASSES); >+ Other than that, this looks good. Thanks a lot for getting the timing information!

Does this patch need superreview? If necessary, who should I request superreview to? I'm afraid I'm not used to patch-review-checkin process...

No need for superreview, as far as I know.

Comment on attachment 505753 [details] [diff] [review] use SetupAPI rv1.2 Nope, it just needs approval which I recommend.

I think this should wait until beta10 is cut to minimize the risk of it breaking things right before the freeze.