605053 - Direct2D is disabled by default and cannot be force-enabled on Vista with several Intel graphics chipsets

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect)

Description

[Helder "Lthere" Magalhães]

Motivation:
I'm dealing with an issue (see bug 594025 comment 30 and next ones, specifically bug 594025 comment 38) where I've been trying to do everything to allow me to use Direct2D. (Currently, I'm too busy for a decent experiment, like building and debugging Firebug and *really* figure out what's happening, sorry. I did try to follow instructions given, though - see bug 594025 comment 40 - I just wasn't lucky yet.) I think figuring this out may help a few which are also suffering from similar (the same?) issue.


Steps to reproduce:
1. Start Firefox;
2. Browse to 'about:support';
3. Force Direct2D and DirectWrite (see 594877 comment 31);
4. Restart Firefox;
5. Browse to 'about:support'.


Actual results:
After step 2, neither Direct2D or DirectWrite are enabled.
After step 5, only DirectWrite is enabled.


Expected results:
After step 2, I'd expect Direct2D and DirectWrite to be enabled, as my configuration shouldn't be blacklisted [2].
After step 5, I'd expect Direct2D and DirectWrite to be enabled, as forcing it should make it enabled regardless of device/driver/OS detection.


Additional information:
All expected results depend on the fact that I have (unless of a system inconsistency/driver install bugs) the proper driver version for my graphics adapted: in my case, 2A43 [1] with driver version 8.15.10.2202 on Windows Vista SP2 [2]). Also, anyone trying to reproduce please make sure the triple GraphicsAdapter+OperatingSystem+DriverVersion is correct (check it in the source code [3] if you have some technical background) before commenting. If one is able to reproduce and unable to provide relevant information, please just vote on this bug. Thanks! ;-)

As stated in bug 594025 comment 30 most of the relevant information I currently have. As stated there, a cool thing currently happening is that I currently have an environment which reproduces (mine) and another which doesn't (a co-worker with similar hardware but a different OS, Windows 7).

Currently, my guesses go to:
1. An issue in VerifyD2DDevice, UpdateRenderMode [5] or related code;
2. A DirectX regression (I have DirectX June 2010 Redist [4] installed while I guess my colleague has the stock DirectX (+ security updates, maybe) which came with Windows 7. My DirectX Diagnostic Tool (dxdiag.exe) version is 7.0.6002.18107 while his is 6.01.7600.16385. I *could* make an experiment with his PC (downgrade of DirectX is apparently difficult), but I don't want to potentially regress his system without a good reason. A redistributable DirectX version should be out (?) in a few weeks;
3. A driver install issue. Although in his system, driver upgrade went smooth and D2D started to work immediately. I guess I already reinstalled these drivers, although I can't remember if did it with my *this* particular driver;
4. A firmware regression (my BIOS is more updated than his, although that probably doesn't make much sense).

In the latest days, I've been harvesting information about these two curious systems (mine and my colleague's) and I still haven't had the chance to review/compare the whole data set. If anyone is interested, I may attach it to this bug, but I'd ask you to state *which* way was more interesting:
 * Single zip file containing data from both (working and non-working) systems. I'd prefer this one;
 * Two zip files, each containing data for one system;
 * Individual file attachments. Would probably clutter this bug report more than it already is!

Although this seems to happen in Windows 7 as well (Windows NT 6.1 in bug 594025 comment 24 and complaint about not working in bug 594025 comment 39), I'm setting it to Windows Vista (mostly because there is no way to combine them and also because I'm experiencing on Vista).

I'm not sure if this should block bug 549116 but given the amount of people suffering from this (for example, bug 594025 comment 39 and/or bug 594877 comment 37), I really think it should at least be considered. :-) (Maybe even consider adding this to block bug 569993, as I'm afraid this will leave many users frustrated if not solved before Fx4 is released, but at least for now I'm just leaving this in the open.)


[1] http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/GfxInfo.cpp#462
[2] http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/GfxInfo.cpp#525
[3] http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/GfxInfo.cpp#495
[4] http://www.microsoft.com/downloads/details.aspx?familyid=3B170B25-ABAB-4BC3-AE91-50CEB6D8FA8D
[5] http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

In any case --- regardless of whether this is an issue in our code or in your system --- we should understand where, in our code, it gets decided not to use D2D on your system.

In an ideal world, you would run Firefox in a debugger, set a breakpoint at the beginning of VerifyD2DDevice, and step through it.

In practice, I know you already tried debugging with debug builds we provide and it's not easy to get symbols to work (see bug 594025 comment 40).

If you have a development environment, you can always make a debug build yourself, but I certainly understand if you don't have time.

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

Let me write some instrumentation for VerifyD2DDevice...

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: instrument D2D device creation

Here's a patch adding lots of terminal output. I'm triggering a tryserver build for you, will let you know when it's done.

For example here's the output I get here:

d2dForceEnabled = 0
d2dDisabled = 0
d2dBlocked = 0
tryD2D = 1
isVistaOrHigher = 1
safeMode = 0
trying VerifyD2DDevice...
begin VerifyD2DDevice, mD2DDevice = 00000000
successfully created D3D 10.0 device
successfully created D3D 10.1 device
cairo_d2d_create_device_from_d3d10device returned mD2DDevice = 03ED32E0
VerifyD2DDevice exit, mD2DDevice = 03ED32E0
got mD2DDevice = 03ED32E0
end of D2D stuff, mD2DDevice = 03ED32E0

So once you're able to run this on your machine, we'll know a lot more.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

Here's your build:

Optimized:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-336f62bc2fe4/tryserver-win32/

Debug:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-336f62bc2fe4/tryserver-win32-debug/

Please try to reproduce with either of these builds, running from the command-line, and paste/attach the output here.

Comment 5

[solcroft]

I'd like to help diagnose this issue, seeing as how I'm affected and definitely do not want to see this bug in Fx4 final, but I'd classify myself as a relatively inexperienced user. Can someone provide some instructions on what do I do with the links in comment #4?

Comment 6

[Helder "Lthere" Magalhães]

(In reply to comment #4)
> Here's your build:

Thanks for all the hassle! :-)


> Optimized:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-336f62bc2fe4/tryserver-win32/

This is not very useful right? No console output for these... ;-)


> Debug:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-336f62bc2fe4/tryserver-win32-debug/
> 
> Please try to reproduce with either of these builds, running from the
> command-line, and paste/attach the output here.

I'm only attaching the (apparently) relevant part of the output, as I'm naturally getting a lot more (please reply if attaching the whole output would be useful):
d2dForceEnabled = 1
d2dDisabled = 0
d2dBlocked = 0
tryD2D = 1
isVistaOrHigher = 1
safeMode = 0
trying VerifyD2DDevice...
begin VerifyD2DDevice, mD2DDevice = 00000000
failed to create D3D 10.0 device
still no D2D device, forcing...
cairo_d2d_create_device returned mD2DDevice = 00000000
VerifyD2DDevice exit, mD2DDevice = 00000000
end of D2D stuff, mD2DDevice = 00000000


(In reply to comment #5)
> I'd like to help diagnose this issue, seeing as how I'm affected and definitely
> do not want to see this bug in Fx4 final, but I'd classify myself as a
> relatively inexperienced user. Can someone provide some instructions on what do
> I do with the links in comment #4?

Here's somehow (an extracted, summarized procedure of) what I did:
1. Download the debug ("tryserver-win32-debug") build. I found the ZIP ("firefox-4.0b8pre.en-US.win32.zip") to be the most convenient (simple and trouble-free for this case);
2. Extract the contents of the ZIP file to some temporary location;
3. Open a command prompt (cmd.exe) to the temporary location chosen in step 2 (tip: in Windows Vista and above, Shift+right click a folder in the *right* pane of Windows Explorer - an "Open Command Window Here" will be displayed);
4. (If you already have a blank profile for this sort of tests, skip to step 7) Run the following command to start the Profile Manager [1]:
firefox.exe -no-remote -ProfileManager
5. Create a new profile (named "minefield", for example);
6. Press "Exit";
7. Run the following command to start Firefox (adjust for the name used in step 5, if necessary):
firefox.exe -no-remote -P "minefield"
8. Analyze the console output and copy (tip: right click the console output and press mark; select the contents you want to copy and right click them again - when they are unselected, the content is copied to the clipboard) the relevant contents (from "d2dForceEnabled" to "end of D2D stuff", including those lines);
9. Paste the contents into a reply here! :-)

The creating profile stuff (steps 4-6) is only made once. Typically you can reuse the profile for many tests (I use it for my general nightly builds [2] testing).

This procedure may sound lengthy, but you'll see how once one catches up, its quite easy. The "no-remote" command line is mostly to avoid having to shutdown the running instance of Firefox (stable), which is naturally your browser of choice and is probably always running! ;-)


[1] http://kb.mozillazine.org/Profile_manager
[2] https://nightly.mozilla.org/
[3] http://kb.mozillazine.org/Opening_a_new_instance_of_Firefox_with_another_profile

Comment 7

[Helder "Lthere" Magalhães]

(In reply to comment #6)
> Here's somehow (an extracted, summarized procedure of) what I did:
[...]
> 7. Run the following command to start Firefox (adjust for the name used in step
> 5, if necessary):
> firefox.exe -no-remote -P "minefield"
> 8. Analyze the console output and copy [...] the relevant contents
> (from "d2dForceEnabled" to "end of D2D stuff", including those lines);

Humm, if forgot to mention something which can be useful as well. Between steps 7 and 8, you may also try forcing Direct2D by:
a. Navigate to "about:config";
b. Type "direct" into the filter box;
c. Change "gfx.direct2d.force-enabled" to "true";
d. Restart Firefox (use the command line in step 7 again);
e. Now you may copy the console output contents, which will include an extra step (note the "still no D2D device, forcing..." in comment 6).

I should have also stated that, when using nightly builds, the console parameters above are pretty useful: after installing the nightly build (which will then keep updated), simply edit the shortcuts created in Start menu and paste ' -no-remote -P "minefield"' after "firefox.exe" to always allow using two instances and testing while using (that's what I do!). :-)

Comment 8

[solcroft]

Thanks for the feedback, Helder. Unfortunately, the tryserver-win32-debug build refuses to run on my machine. The same error message pops up no matter how I try to run it (double-click in Explorer, run from command prompt, run using 'Run...' command from Start menu): http://i51.tinypic.com/bdpoax.png

To make sure it wasn't due to a corrupted download, I downloaded the zip file twice from this URL: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-336f62bc2fe4/tryserver-win32-debug/firefox-4.0b8pre.en-US.win32.zip

Using Win7 32-bit on my machine. Looks like I won't be able to help out with this issue, unfortunately.

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #6)
> (In reply to comment #4)
> > Here's your build:
> 
> Thanks for all the hassle! :-)
> 
> 
> > Optimized:
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-336f62bc2fe4/tryserver-win32/
> 
> This is not very useful right? No console output for these... ;-)

Hm, I really believe that you should get at least _my_ output even in release builds, as I used plain printf's.

Thanks a lot for running this and reporting back. I will have a close look at your data as soon as possible.

(In reply to comment #8)
> Thanks for the feedback, Helder. Unfortunately, the tryserver-win32-debug build
> refuses to run on my machine.

...so as I say above, you can still try the release build, it should still print the output that I added and that I'm interested in.

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

-> Bas: question for you below.

(In reply to comment #6)
> d2dForceEnabled = 1
> d2dDisabled = 0
> d2dBlocked = 0
> tryD2D = 1
> isVistaOrHigher = 1
> safeMode = 0
> trying VerifyD2DDevice...
> begin VerifyD2DDevice, mD2DDevice = 00000000
> failed to create D3D 10.0 device

Ah, so that's where things are going wrong on your system: we can't get Direct3D 10.

Since your graphics device (2a43 == Intel GMA 4500 Mobile HD) should support Direct3D 10, this seems to be an issue with your software setup (D3D DLL's ? drivers ? don't know)

For the record here's our Direct3D 10.0 creation code that's failing on your setup:

        HRESULT hr = createD3DDevice(
            NULL, 
            D3D10_DRIVER_TYPE_HARDWARE,
            NULL,
            D3D10_CREATE_DEVICE_BGRA_SUPPORT |
            D3D10_CREATE_DEVICE_PREVENT_INTERNAL_THREADING_OPTIMIZATIONS,
            D3D10_FEATURE_LEVEL_10_0,
            D3D10_1_SDK_VERSION,
            getter_AddRefs(device));

---> Bas : do you see any option there that could explain why it fails for him and that we could consider dropping?? like D3D10_CREATE_DEVICE_PREVENT_INTERNAL_THREADING_OPTIMIZATIONS ??

Comment 11

[Bas Schouten (:bas.schouten)]

(In reply to comment #10)
> -> Bas: question for you below.
> 
>         HRESULT hr = createD3DDevice(
>             NULL, 
>             D3D10_DRIVER_TYPE_HARDWARE,
>             NULL,
>             D3D10_CREATE_DEVICE_BGRA_SUPPORT |
>             D3D10_CREATE_DEVICE_PREVENT_INTERNAL_THREADING_OPTIMIZATIONS,
>             D3D10_FEATURE_LEVEL_10_0,
>             D3D10_1_SDK_VERSION,
>             getter_AddRefs(device));
> 
> ---> Bas : do you see any option there that could explain why it fails for him
> and that we could consider dropping?? like
> D3D10_CREATE_DEVICE_PREVENT_INTERNAL_THREADING_OPTIMIZATIONS ??

That's the one option we could theoretically drop, but I don't think it should ever fail on that though!

You should get a 'dxdiag' and look at the DDI version. It could in theory be failing on BGRA_SUPPORT, but it would certainly surprise me. In any case D2D requires BGRA support.

Comment 12

[Helder "Lthere" Magalhães]

(In reply to comment #11)
> You should get a 'dxdiag' and look at the DDI version. It could in theory be
> failing on BGRA_SUPPORT, but it would certainly surprise me. In any case D2D
> requires BGRA support.

DDI version displays "10". Vista has no WDDM support but my colleague's PC (which works fine, see comment 0) reports "1.1".

As stated (in comment 0), I may attach a bunch of interesting information, just say what you are interested in and I'll add it! :-)

Comment 13

[Bas Schouten (:bas.schouten)]

(In reply to comment #12)
> (In reply to comment #11)
> > You should get a 'dxdiag' and look at the DDI version. It could in theory be
> > failing on BGRA_SUPPORT, but it would certainly surprise me. In any case D2D
> > requires BGRA support.
> 
> DDI version displays "10". Vista has no WDDM support but my colleague's PC
> (which works fine, see comment 0) reports "1.1".
> 
> As stated (in comment 0), I may attach a bunch of interesting information, just
> say what you are interested in and I'll add it! :-)

Vista -should- have WDDM 1.0 support. You'll definitely want WDDM 1.0 I believe for this to work. I'm surprised it's not reported.

Comment 14

[solcroft]

(In reply to comment #9)
> 
> Hm, I really believe that you should get at least _my_ output even in release
> builds, as I used plain printf's.
> 
> 
> ...so as I say above, you can still try the release build, it should still
> print the output that I added and that I'm interested in.

Unfortunately I have to agree with Helder's previous observation: no console output for the tryserver-win32 build.

Comment 15

[[not reading bugmail]]

Bas, would testing your transparency tester from bug 571068 attachment 451280 [details] help here at all?

Comment 16

[Helder "Lthere" Magalhães]

I've been following this closely, as time permits (unfortunately, very little)... :-(

I can confirm that I've attempted the workaround from bug 604771 (setting vendor to zero) with no effect. :-|

Fortunately (for me), I hope to take a couple weeks vacation by the end of the year but, unfortunately (for this issue), that means I'll probably send my PC for the IT team for reconfiguration, this time with Windows 7 - which means less one broken system for aid debugging this. :-(


(In reply to comment #15)
> Bas, would testing your transparency tester from bug 571068 attachment 451280 [details]
> help here at all?

Not Bas but apparently not much... :-D

Details: "D3DTransparencyTest.exe has stopped working" (Vista's crash dialog appeared), detailed information follows.

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	D3DTransparencyTest.exe
  Application Version:	0.0.0.0
  Application Timestamp:	4c17901d
  Fault Module Name:	D3DTransparencyTest.exe
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	4c17901d
  Exception Code:	c0000005
  Exception Offset:	000018f7
  OS Version:	6.0.6002.2.2.0.256.6
  Locale ID:	2070
  Additional Information 1:	eee1
  Additional Information 2:	b2ba053f6b21eb702abb090f630f998e
  Additional Information 3:	4433
  Additional Information 4:	337a889a283b2e6fb7802d1ae5c186dc


Running again and debugging with Visual Studio reveals more or less the same:
Unhandled exception at 0x003118f7 in D3DTransparencyTest.exe: 0xC0000005: Access violation reading location 0x00000000.


As already stated (in comment #0), this is occurring in Windows Vista SP2.

Comment 17

[Bas Schouten (:bas.schouten)]

That crash suggests DX9level3 is not supported, that would indeed be problematic. I don't see us supporting level 2 hardware at all.

Comment 18

[Helder "Lthere" Magalhães]

(In reply to comment #17)
> That crash suggests DX9level3 is not supported, that would indeed be
> problematic. I don't see us supporting level 2 hardware at all.

Weird. That would hint towards a hardware limitation, while I've seen it working in similar hardware (more details will follow)... :-|

I'm CC'ing my colleague as is he interested in following this issue and also because I'm about to append further diagnostic information from both systems (his configuration working and mine being broken, both using similar hardware). :-)

@Pedro: could you download and run attachment 451280 [details] (see comment 16 for more details) and report back results? Thanks! ;-)

Comment 19

[Pedro]

Attachment: WinDbg session output for D3D Transparency Test

(In reply to comment #18)
> @Pedro: could you download and run attachment 451280 [details] (see comment 16 for more
> details) and report back results? Thanks! ;-)

I've run the utility but nothing happened. I'm attaching a WinDbg session output file for more details.

As Helder has already stated, in my configuration (Windows 7 Professional), Firefox 4 Direct2D *is* active (as well as DirectWrite) in a not very recent nightly build:
Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100926 Firefox/4.0b7pre

Comment 20

[Helder "Lthere" Magalhães]

(In reply to comment #0)
> Additional information:
> All expected results depend on the fact that I have (unless of a system
> inconsistency/driver install bugs) the proper driver version for my graphics
> adapted: in my case, 2A43 [1] with driver version 8.15.10.2202
> on Windows Vista SP2 [2]).

Just to confirm that using driver version 8.15.10.2226 (unfortunately) doesn't change the situation.

Comment 21

[Helder "Lthere" Magalhães]

Attachment: Broken PC vs. Working PC - Diagnostic information

I'm attaching additional diagnostic information I've been harvesting while trying to reduce this issue. It's not very up to date (most of it was retrieved about a month ago, although only now I've had the chance to filter out some identification details) but the symptoms are still occurring so it may become handy... :-)

The only thing which caught my eye this time (around comment #12 there was something about "WDDM" support) was the lack of "D3D9 Overlay" in my DirectX Diagnostic Tool - "DxDiag(BrokenPC).txt", while it appears in Pedro's computer - "DxDiag(WorkingPC).txt".

Comment 22

[Bas Schouten (:bas.schouten)]

Erm, alright, so, it appears that possibly the Vista Intel drivers lack support for some things. One thing you could try is a utility called 'DXCapsViewer' and attaching the output to this bug. It's part of the DirectX SDK, but since that's a pretty big package it also floats around the web.

Comment 23

[Helder "Lthere" Magalhães]

Attachment: BrokenPC and WorkingPC - DXCapsViewer (AllCaps)

Comment 24

[Helder "Lthere" Magalhães]

Attachment: BrokenPC vs. WorkingPC - DXCapsViewer (Comparison)

(In reply to comment #22)
> Erm, alright, so, it appears that possibly the Vista Intel drivers lack support
> for some things.

Yup, that sounds what's happening here... :-|


> One thing you could try is a utility called 'DXCapsViewer' and
> attaching the output to this bug.

Ran the utility and asked Pedro to do that in his machine as well. I've attached the full log (in ZIP format), although this is probably more interesting, as it's diff made between both to ease analysis. :-)


I'd say this kind of hardware acceleration issues deserved a wiki page, so that people could report working/broken hardware and driver versions. ;-)


Finally, do we know someone from Intel which can take a look at this? Should this issue be marked "invalid" (as it conceptually is, this currently feels like a driver issue - other insights would be appreciated!)

Comment 25

[Helder "Lthere" Magalhães]

FWIW, as already stated D3D device loads successfully. The following is displayed in Error Console:

Direct3D 9 DeviceManager Initialized Succesfully.
Driver: igdumdx32.dll
Description: Mobile Intel(R) 4 Series Express Chipset Family
Version: 8.15.10.2226

(Nit: "Succesfully" --> "Successfully")

I'm starting to consider "abandoning" this issue, as the likely cause seems found. I've got a few days vacation in the beginning of 2011 and am thinking about sending my machine for reconfiguration with Windows 7 (comment 16). Please reply back if there's some additional information I can extract and/or test I may be able to perform before that. ;-)

Comment 26

[Mr. T]

Hi everybody, I happened to stumble upon this page. I wish to report that I'm experiencing the same issue - can't get Direct2d enabled. Only Directwrite is enabled.

OS: Vista
Display: Intel HD (Intel Core on CPU)

Graphics
Adapter Description: Intel(R) HD Graphics
Vendor ID: 8086
Device ID: 0042
Adapter RAM: Unknown
Adapter Drivers:igdumdx32, igd10umd32
Driver Version: 8.15.10.2202
Driver Date: 8-25-2010
Direct2D Enabled: false
DirectWrite Enabled: true
WebGL Renderer: Intel -- Intel(R) HD Graphics -- 2.1.0 - Build 8.15.10.2202
GPU Accelerated Windows: 1/1 Direct3D 9

I am pretty clueless with regards to coding but if you would kindly let me know what I should run etc I'll provide you with the output, if you are still working on this issue.

Comment 27

[Helder "Lthere" Magalhães]

(In reply to comment #24)
> I'd say this kind of hardware acceleration issues deserved a wiki page, so that
> people could report working/broken hardware and driver versions. ;-)

I've seen something regarding this (a couple tweets, maybe) but, while crawling for content, I was unable to find anything related. Is this somehow in the roadmap for the 4.0 release documentation?


(In reply to comment #24)
> Finally, do we know someone from Intel which can take a look at this? Should
> this issue be marked "invalid" (as it conceptually is, this currently feels
> like a driver issue - other insights would be appreciated!)

Still valid. I have no idea on how to further help (regarding this particular issue nor other potentially interested/equally suffering users)... :-(


(In reply to comment #25)
> FWIW, as already stated D3D device loads successfully. The following is
> displayed in Error Console:
> 
> Direct3D 9 DeviceManager Initialized Succesfully.
> Driver: igdumdx32.dll
> Description: Mobile Intel(R) 4 Series Express Chipset Family
> Version: 8.15.10.2226
> 
> (Nit: "Succesfully" --> "Successfully")

The typo is still in today's nightly build, BTW... ;-)


(In reply to comment #25)
> I'm starting to consider "abandoning" this issue, as the likely cause seems
> found. I've got a few days vacation in the beginning of 2011 and am thinking
> about sending my machine for reconfiguration with Windows 7 (comment 16).

This is still valid. My schedule limit to help debugging this is something like "the first week of February" (if it matters, anyway...), then Windows 7 shall be. :-)

Comment 28

[Helder "Lthere" Magalhães]

(In reply to comment #27)
> I've seen something regarding this (a couple tweets, maybe) but, while crawling
> for content, I was unable to find anything related. Is this somehow in the
> roadmap for the 4.0 release documentation?

Note to self: always remember to review *all* unread bugmail before starting to bug people. :-)

This is already being done in bug 601079, which I'm setting to block this: although that's somehow a meta-bug, an OS-specific driver limitation (therefore far beyond Firefox implementation) should definitely be part of that documentation. ;-)

Comment 29

[Helder "Lthere" Magalhães]

I've hacked my other laptop graphics driver (forcing recent Intel drivers instead of the rotten Toshiba customized ones) and got another environment where to reproduce this issue (as I'm in the process of upgrading my everyday laptop to Windows 7).

This environment has a different graphics chipset (Intel 965 Express) which should be added to the list...

Error console entry:
  Direct3D 9 DeviceManager Initialized Succesfully.
  Driver: igdumdx32.dll
  Description: Mobile Intel(R) 965 Express Chipset Family
  Version: 8.14.10.1930

"about:support" graphics (whitespace reworked):
  Adapter Description: Mobile Intel(R) 965 Express Chipset Family
  Vendor ID: 8086
  Device ID: 2a02
  Adapter RAM: Unknown
  Adapter Drivers: igdumdx32 igd10umd32
  Driver Version: 8.15.10.1930
  Driver Date: 9-23-2009
  Direct2D Enabled: false
  DirectWrite Enabled: true (7.0.6002.18107, font cache n/a)
  WebGL Renderer: (WebGL unavailable)
  GPU Accelerated Windows: 2/2 Direct3D 9

I've also further reworked this issue title (thanks Scoobidiver!) to reflect this.

Comment 30

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #29)
> I've hacked my other laptop graphics driver (forcing recent Intel drivers
> instead of the rotten Toshiba customized ones) and got another environment
> where to reproduce this issue (as I'm in the process of upgrading my everyday
> laptop to Windows 7).
> 
> This environment has a different graphics chipset (Intel 965 Express) which
> should be added to the list...
> 
> Error console entry:
>   Direct3D 9 DeviceManager Initialized Succesfully.
>   Driver: igdumdx32.dll
>   Description: Mobile Intel(R) 965 Express Chipset Family
>   Version: 8.14.10.1930
> 
> "about:support" graphics (whitespace reworked):
>   Adapter Description: Mobile Intel(R) 965 Express Chipset Family
>   Vendor ID: 8086
>   Device ID: 2a02
>   Adapter RAM: Unknown
>   Adapter Drivers: igdumdx32 igd10umd32
>   Driver Version: 8.15.10.1930

Aha, see, your Driver Version here is self-contradictory: 8.14.10.1930 versus 8.15.10.1930.

We already are checking for this (bug 590373), and disabling D3D10 features when this happens, but we're not preventing you from force-enabling. So if you can't force-enable, that confirms that your drivers have a big problem, and it now seems that this problem is correlated with self-contradictory driver versions.

Apparently something went wrong in your driver install/upgrade process. Don't know how to fix it.

Comment 31

[Helder "Lthere" Magalhães]

(In reply to comment #30)
> > I've hacked my other laptop graphics driver (forcing recent Intel drivers
> > instead of the rotten Toshiba customized ones) and got another environment
> > where to reproduce this issue (as I'm in the process of upgrading my everyday
> > laptop to Windows 7).

Oops, I used a Windows 7 driver package on Windows Vista. May that explain the weird inconsistency? (Every piece of information in the release notes pointed at "8.15.10.1930", although the actual file versions were "8.14.10.1930". Could this be the result of another Intel "magic" versioning scheme? (8.15.xx.xxx for Win7, 8.14.xx.xxx for Vista.)


> Aha, see, your Driver Version here is self-contradictory: 8.14.10.1930 versus
> 8.15.10.1930.
> 
> We already are checking for this (bug 590373), and disabling D3D10 features
> when this happens, but we're not preventing you from force-enabling.

Apparently not. I tried force-enabling, spoofing and even driver resource version editing (read "high-jacking") to realize that, even with the "corrected" versions and/or spoofing, D2D always ended up being blacklisted and/or disabled.

After a couple hours of experiments and crawling, I stumbled at an additional blacklisting [1] I was unaware of (which hint at bug 595364 comment 10). Ahhh, now we're talkin'... :-D This basically means my other laptop's hardware (comment 29) is specifically blacklisted. I'm not convinced why, though... :-(


One thing that still stumbles me is the fact that the most updated drivers I found for Windows Vista [2] are version "7.15.10.1666", which makes me wonder if the operating-system specific heuristics are correct. Oh well... ;-)


[1] http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/GfxInfo.cpp#585

Comment 32

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #31)
> (In reply to comment #30)
> > > I've hacked my other laptop graphics driver (forcing recent Intel drivers
> > > instead of the rotten Toshiba customized ones) and got another environment
> > > where to reproduce this issue (as I'm in the process of upgrading my everyday
> > > laptop to Windows 7).
> 
> Oops, I used a Windows 7 driver package on Windows Vista. May that explain the
> weird inconsistency? 

Yes, this could explain it.

> (Every piece of information in the release notes pointed
> at "8.15.10.1930", although the actual file versions were "8.14.10.1930". Could
> this be the result of another Intel "magic" versioning scheme? (8.15.xx.xxx for
> Win7, 8.14.xx.xxx for Vista.)
> 
> 
> > Aha, see, your Driver Version here is self-contradictory: 8.14.10.1930 versus
> > 8.15.10.1930.
> > 
> > We already are checking for this (bug 590373), and disabling D3D10 features
> > when this happens, but we're not preventing you from force-enabling.
> 
> Apparently not. I tried force-enabling, spoofing and even driver resource
> version editing (read "high-jacking") to realize that, even with the
> "corrected" versions and/or spoofing, D2D always ended up being blacklisted
> and/or disabled.
> 
> After a couple hours of experiments and crawling, I stumbled at an additional
> blacklisting [1] I was unaware of (which hint at bug 595364 comment 10). Ahhh,
> now we're talkin'... :-D This basically means my other laptop's hardware
> (comment 29) is specifically blacklisted. I'm not convinced why, though... :-(

We may actually remove that bit of blacklist. I believe (say 80% sure) that it's enough to just blacklist intel drivers that have mismatched versions. But I don't want to break stuff so close to the firefox 4 release, so this will have to wait for the next version.

In addition, this *still* does not prevent you from force-enabling. So if you can't force-enabled, that still means that there is a problem in your driver.

> 
> 
> One thing that still stumbles me is the fact that the most updated drivers I
> found for Windows Vista [2] are version "7.15.10.1666", which makes me wonder
> if the operating-system specific heuristics are correct. Oh well... ;-)

Your link for [2] seems to be missing?

Comment 33

[Helder "Lthere" Magalhães]

(In reply to comment #32)
> > [...] This basically means my other laptop's hardware
> > (comment 29) is specifically blacklisted. I'm not convinced why, though... :-(
> 
> We may actually remove that bit of blacklist. I believe (say 80% sure) that
> it's enough to just blacklist intel drivers that have mismatched versions. But
> I don't want to break stuff so close to the firefox 4 release, so this will
> have to wait for the next version.

Sounds fair. I'll therefore wait until something happens, as my everyday laptop Windows partition will soon become another "Seven" (a.k.a. Vista-killer) instance. :-) I wonder if they got the name from the movie... :-D


> In addition, this *still* does not prevent you from force-enabling. So if you
> can't force-enabled, that still means that there is a problem in your driver.

As we already have somehow concluded (in comment 22 and comment 24), the fact that I cannot even force it is also probably related to lack for some features in the Vista drivers (details in attachment 500002 [details] for hardware of the original report). I'll further investigate as time permits.


> > One thing that still stumbles me is the fact that the most updated drivers I
> > found for Windows Vista [2] are version "7.15.10.1666", which makes me wonder
> > if the operating-system specific heuristics are correct. Oh well... ;-)
> 
> Your link for [2] seems to be missing?

Yup, forgot it, sorry. ;-) Intel site doesn't appear to be very user-friendly, specially when graphics are embedded by another vendor (Toshiba, in my two laptops); their device identification/driver location tool [1] (ran in IE+ActiveX, as Firefox+Java seemed broken) is then almost useless, and finding information becomes hard. I was quickly bouncing between driver versions during my experiments/searches in Intel support site and, after trying out (the apparently latest version) "7.15.10.1624" [2], I finally settled at version "7.15.10.1666" [3].

I just found out that wiki drivers [4] can also be useful at finding the latest driver version, although one needs to know the right hardware identification (in which the detection tool [1] helps a bit).

[1] http://www.intel.com/support/detect.htm
[2] http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=17297
[3] http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=17407
[4] http://wikidrivers.com/wiki/Intel_GMA_15.%E2%80%8B%E2%80%8B12.%E2%80%8B%E2%80%8B4.%E2%80%8B%E2%80%8B1666

Comment 34

[Helder "Lthere" Magalhães]

(In reply to comment #33)
> > > One thing that still stumbles me is the fact that the most updated drivers I
> > > found for Windows Vista [2] are version "7.15.10.1666" [...]

Michal (a.k.a. gader) shared this interesting nit:
The newest build for vista is 2039:
http://downloadcenter.intel.com/Detail_Desc.aspx?ProductID=2784&DwnldID=18685&lang=eng&iid=dc_rss

In fact, I tried that driver version and am now running version "7.15.10.2039" in my other laptop. Thanks, Michael! ;-)

The block list was explicitly [1] leaving my other laptop's HW out in the cold so I tried to circumvent it by simulating another device (using the information in bug 604771), but still no good. :-|

It seems that someone (apparently Intel) really needs to do their homework. Further information on what's happening (kind of like the "D3D DeviceManager" message in the error console), regarding HW initialization failure would be welcome. (Is lack of DX10 support the cause? Did some important API invocation fail? etc.)


[1] http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/GfxInfo.cpp#585

Comment 35

[Ali Juma [:ajuma]]

Helder, does this issue to occur on Nightly, using the latest drivers?

Comment 36

[Helder "Lthere" Magalhães]

(In reply to Ali Juma [:ajuma] from comment #35)
> Helder, does this issue to occur on Nightly, using the latest drivers?

Yes, the issue still occur. Was there a known change anything which should have fixed it?

I even tried to force enable both graphics and font rendering (using gfx.* preferences) but no luck. No matter what, Direct2D doesn't get enabled, while DirectWrite does without any difficulty.

Details follow.

Error Console:
Direct3D 9 DeviceManager Initialized Succesfully.
Driver: igdumdx32.dll
Description: Mobile Intel(R) 965 Express Chipset Family
Version: 7.15.10.2039

about:support (whitespace reworked):
  Application Basics
    Name: Firefox
    Version: 11.0a1
    User Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0a1) Gecko/20111212 Firefox/11.0a1
  Extensions
    Name / Version / Enabled
    AVG Safe Search / 10.0.0.1410 / false
    AVG Security Toolbar / 7.005.030.004 / false
    Microsoft .NET Framework Assistant/ 1.1 / false
  Modified Preferences
      Name = Value
      browser.places.smartBookmarksVersion = 2
      browser.startup.homepage_override.buildID = 20111212031122
      browser.startup.homepage_override.mstone = rv:11.0a1
      extensions.lastAppVersion = 11.0a1
      general.useragent.extra.microsoftdotnet = (.NET CLR 3.5.30729)
      gfx.direct2d.force-enabled = true
      gfx.font_rendering.directwrite.enabled = true
      network.cookie.prefsMigrated = true
      places.history.expiration.transient_current_max_pages = 18717
      privacy.sanitize.migrateFx3Prefs = true
  Graphics
        Adapter Description: Mobile Intel(R) 965 Express Chipset Family
        Vendor ID: 8086
        Device ID: 2a02
        Adapter RAM: Unknown
        Adapter Drivers: igdumdx32 igd10umd32
        Driver Version: 7.15.10.2039
        Driver Date: 1-7-2010
        Direct2D Enabled: false
        DirectWrite Enabled: true (7.0.6002.18409)
        ClearType Parameters: ClearType parameters not found
        WebGL Renderer: Google Inc. -- ANGLE (Mobile Intel(R) 965 Express Chipset Family) -- OpenGL ES 2.0 (ANGLE 1.0.0.901)
        GPU Accelerated Windows: 1/1 Direct3D 9

Comment 37

[Ali Juma [:ajuma]]

(In reply to Helder "Lthere" Magalhães from comment #36)
> Yes, the issue still occur. 

Thanks for the updated details.

> Was there a known change anything which should
> have fixed it?

Not specific to this this bug, but since there have been a lot of changes to the code base over the past 10 months, it's good to bring things up to date.

Comment 38

[gader]

Epilogue. This bug may be closed.

There is no way to fix that without Intel driver team support.
The problem is that the Intel does not support KB971644(KB971512, KB971513, KB971514, KB960362).
After talking with the support they won't give us any updated drivers or support for Vista Platform Update.