Closed Bug 604771 Opened 11 years ago Closed 11 years ago
Allow spoofing Gfx
Info and circumventing the blocklist on Windows
This patch makes it possible to spoof GfxInfo on Windows by defining environment variables. The motivation is to be able to reproduce possible GfxInfo/blocklist bugs, and to allow people to circumvent the blocklist by spoofing their vendor ID as one not present in the bloclist, e.g. 0 (see below). Environment variables: MOZ_GFX_SPOOF_WINDOWS_VERSION hex value, see gfxWindowsPlatform.h example: 60001 for Win 7 MOZ_GFX_SPOOF_VENDOR_ID hex value, for example 8086 for Intel MOZ_GFX_SPOOF_DEVICE_ID hex value, for example 2a42 MOZ_GFX_SPOOF_DRIVER_VERSION string, for example 188.8.131.522 Sample command line: ( \ means continued on newline ) MOZ_GFX_SPOOF_VENDOR_ID=8086 \ MOZ_GFX_SPOOF_DEVICE_ID=2a42 \ MOZ_GFX_SPOOF_DRIVER_VERSION=184.108.40.2062 \ dist/bin/firefox -P test -no-remote If you want to circumvent the blocklist, do e.g.: MOZ_GFX_SPOOF_VENDOR_ID=0 firefox
Attachment #483610 - Flags: review?
Attachment #483610 - Flags: review? → review?(jmuizelaar)
Forgot to override one WindowsOSVersion() call.
Attachment #483620 - Flags: review? → review?(jmuizelaar)
Comment on attachment 483620 [details] [diff] [review] Spoof GfxInfo Just fall through if scanf fails instead of returning an error
Attachment #483620 - Flags: review?(jmuizelaar) → review+
Severity: normal → enhancement
Status: NEW → ASSIGNED
Component: Canvas: WebGL → Graphics
QA Contact: canvas.webgl → thebes
Version: unspecified → Trunk
Assignee: nobody → bjacob
Attachment #488539 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Is there a way to have the patch tell FF the RAM of GPU? Also, without RTFMing me too much, how do I use the patch? Thanks
Usage of the present spoofing facility is explained above, in comment 0. Why would you want to spoof the GPU RAM size? I don't even know that Firefox uses that at all.
I can't get this to work on Intel cards. Particularly, I'm using a Mobile 945 chipset. I'm wanting to test the new drivers in Windows 8 to see if they resolve the issue, but those drivers are still blacklisted for some reason. I tried spoofing the vender ID, and I get the even worse "Blocked for your graphics card because of unresolved driver issues." I have everything in about:config forced on. If the driver doesn't work, that's fine. But I want to see it not work, not constantly have it blocked on me. I can't tell if it really doesn't work if it won't even try to work. I do also wonder why you don't fall back to Direct3D9 layers, or, if you do, why you don't report that in the about:support at all.
Also, your instructions are incorrect. That is not the proper way to set an environment variable on the command line. Each setting needs to be preceded with "SET " and be on its own line. Firefox must then be started separately.
You can force-enable features just by going to about:config and setting all the force-enabled preferences to true. No need for env vars for that. The instructions I gave were for Bash (e.g. MSYS on Windows) as that's what everyone around here uses. Maybe the default Windows command line interpreter doesn't support that, I dont know. These env vars are only useful to mozilla devs, who are using MSYS.
No, I can't. That's been the problem since day 1. Despite everything saying that my graphics card is supported, force enabling doesn't work. So I try spoofing, but then I get an error that should be impossible while spoofing. My guess is that it's the fix that blocks Intel cards if the registry and driver data is different. Also, this is an open source project. This is not Microsoft where certain things are closed off to anyone who isn't a programmer. The fact that I'm not a dev but have noticed a potential problem should be a boon to you, not someone who doesn't matter because you think you have the right to tell me what features of the software I can and cannot use.
The fact that force-enabling doesn't work means that the problem is *not* a problem with the blacklisting. So, spoofing won't make any difference. Reasons why things may not work even with force-enabled=true (and disabled=false) include: - driver bugs - DirectX bugs - insufficient hardware - broken hardware In your case in comment 7 you mention using a Intel 945 chipset. These don't accelerate half of D3D9 in hardware, so the D3D9 implementation does the rest in software. As a result, 1) it's not too surprising that this case is particularly sensitive to driver and/or DirectX issues, so try reinstalling both; 2) even if it works, the acceleration benefits is lesser than on more modern hardware as a significant amount of work (at least the vertex shaders) is still run on the CPU. Though for basic web pages without too many small layers, vertex shader performance shouldn't matter much.
Also, I am not aware of the status of Direct3D 9 support in Windows 8 metro-style-enabled-browsers.
Sorry, I apologize for that outburst. I'm going through some bad **** right now, and I took it out on you. I do think I'm right to be frustrated by people telling me that I have no use of something when I clearly do, but my response was out of line. The only reason I didn't say this sooner is that I was beating myself up over getting that upset. There's still a potential problem here if you'll read through the emotions, though. Overriding the vendor ID is causing everything to be blocked. Plus, I have the correct card and drivers (I even downgraded to see if they had to be the exact ones mentioned at https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#Intel_cards. I even tried spoofing a non-mobile card. Nothing works. Direct2D keeps on saying it isn't active. DirectWrite is active. WebGL is active. But Direct2D says I need new drivers.
Terrell, this bug is closed. Please comment in bug 604974.
That bug is great for one of my issues, but it doesn't deal with the fact that setting Vender ID to 0 no longer seems to be working. It results in all acceleration being blocked, even if it worked without spoofing. But I'll take the advice and file a separate bug. Bug 773978 has now been filed.
You need to log in before you can comment on or make changes to this bug.