=== Walkthrough === When Gfx features need to check if a feature is blacklisted, they use GfxInfo::GetFeatureStatus(). Here's for example what D3D9 layers do in gfx/layers/d3d9/LayerManagerD3D9.cpp: PRBool forceAccelerate = Preferences::GetBool("layers.acceleration.force-enabled", PR_FALSE); nsCOMPtr<nsIGfxInfo> gfxInfo = do_GetService("@mozilla.org/gfx/info;1"); if (gfxInfo) { PRInt32 status; if (NS_SUCCEEDED(gfxInfo->GetFeatureStatus(nsIGfxInfo::FEATURE_DIRECT3D_9_LAYERS, &status))) { if (status != nsIGfxInfo::FEATURE_NO_INFO && !forceAccelerate) { NS_WARNING("Direct3D 9-accelerated layers are not supported on this system."); return PR_FALSE; } } } The nsIGfxInfo interface is defined in widget/public/nsIGfxInfo.idl. GfxInfo is implemented in: widget/src/windows/GfxInfo.cpp on Windows widget/src/cocoa/GfxInfo.mm on Mac widget/src/xpwidget/GfxInfoX11.cpp on X11 Moreover, it inherits GfxInfoBase, defined in widget/src/xpwidgets/GfxInfoBase.* The only reason why this is in widget/ is that it's a place where we already had platform-specific code. The widget==platform equation is false however on X11, which is why we put that part in xpwidgets. The information is obtained in different ways for each platform. Mac is the most sane, we get the info from CGL (Core GL). On Windows, we get the info from the windows registry, and that fails miserably on dual-GPU systems (bug 628129). On X11, we get it by having a separate process create a GL context and call glGetString (see bug 639842). The key to understanding why we did this, is that during Firefox 4 development time, we had tons of crashes during D3D/GL initialization with buggy drivers. So we had to either find ways to get driver info that didn't involve D3D/GL initialization (like the registry on Windows), or do it in a separate process (as we do on X11). The entries in the blacklist are described on this wiki page (which must be kept up-to-date wrt the code at all times): https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers Notice that it has bug links to all the bugs behind these blacklist entries. In addition to the built-in blacklist, a downloaded blacklist is also used (bug 625160). Currently it only is implemented on Windows, and generalizing that to other platforms is important (bug 668004). Since the downloaded blacklist got implemented on Windows (bug 625160), blacklisting decisions are cached as preferences (the gfx.blacklist.*) preferences and only reevaluated every 24 hours. This means that if you were blacklisted and upgraded your drivers, you're still blacklisted for 24 hours until it reevaluates. That sucks big time, confuses users and makes bugs harder for us to understand. Bug 653102 is about fixing that. === What needs to be done === bug 628129: Make GPU blacklisting logic aware of dual GPU systems Short term, top priority, possibly challenging but does not require experience. Probably only needed on Windows. Ask Jeff or Joe or Bas about the D3D API bits. bug 653102: Do Not Cache the blacklisting decisions; instead cache the downloaded blacklist entries and reevaluate everytime Short term, important priority, may require some experience with GfxInfoBase etc, but not too much. This is going to change stuff that was introduced in bug 625160 so you will need to discuss with Joe. bug 668004: Generalize the downloaded GPU blacklist to non-Windows platforms Medium term, quite important but less than the above, may require some experience with GfxInfoBase etc, but not too much. This generalizes work done in bug 625160 on Windows, so you will need to discuss with Joe. bug 651981: The whole GfxInfo API is known to suck Long term, important but not an immediate priority, requires experience. I can be your contact for the C++ side, talk to Gavin for the JS side (notice that this API is used by the JS code in about:support and so it needs to have good JS-API-taste).