Hide Forgot
Description of problem: Firefox displays a black rectangle for a resized PNG image. Version-Release number of selected component (if applicable): firefox-3.1-0.6.beta2.fc11.x86_64 xorg-x11-drv-ati-6.12.2-5.fc11.x86_64 How reproducible: 100% on the given configuration Steps to Reproduce: 1. Find a reasonably sized PNG image 2. Launch Firefox, open the image 3. Size the Firefox window so that the PNG image is downscaled Actual results: Black rectangle Expected results: Scaled image Additional info: This happened before, coincidentially exactly one year back in April 2008. Sadly, I cannot find a specific bug. The xorg-x11-drv-ati was updated in order to fix bug 493068. Try not to unfix it, because the lockups are much more important than mere black rectangles for some resized images.
Hmm, apparently it comes and goes for various reasons, on different hardware. https://bugzilla.mozilla.org/show_bug.cgi?id=411831
Ha, I seems to be stalking somebody - was going to file a bug or add a comment in bug 493068 . The symptom I see is that some icons on facebook and youtube are black. firefox-3.0.9-1.fc10.x86_64 xorg-x11-drv-ati-6.12.2-5.fc11.x86_64
(In reply to comment #1) > Hmm, apparently it comes and goes for various reasons, on different hardware. > https://bugzilla.mozilla.org/show_bug.cgi?id=411831 But I am using KMS without xorg.conf, so is doing EXA, and confirmed in Xorg.0.log.
Could I get /var/log/Xorg.0.log, /var/log/dmesg, and /etc/X11/xorg.conf (if any exists) from both you attached to this bug as uncompressed separate attachments here, please? Thank you
please try the latest package from koji, hopefully it continues to fix the original problem and also fix the regression.
Created attachment 341208 [details] dmesg
Created attachment 341209 [details] Xorg.0.log
Created attachment 341212 [details] xorg.conf
xorg-x11-drv-ati-6.12.2-6.fc11.x86_64 fails too (currently latest in Koji)
I was wrong about PNG in particular. Resized JPEG fails too. It's just the way Libpr0n draws to X server in such case. BTW, you can see them being loaded gradually, but once complete the image goes black.
xvideo is also broken. Which xvinfo shows some adaptors, trying to run any of the media players (mplayer/gmplayer/totem) gives a green window, while the audio goes on.
thr xvideo issue is new to 6.12.2-6, and reverting to -5 gets it back.
I just wonder if anybody can say how long the png problem has been - is it related to the fix to bug 493068? The fix only clamps texture data, so that must mean the texture data buffer or something like that contains both (1) other data that shouldn't be there, (2) refers to locations that aren't really data (hence the fix). Either way, it seems that one needs to examine what is actually being passed around as texture. I am a little disappointed that Dave had reverted the bug fix both in koji and upstream (I started looking at xf86-video-ati git a few days ago). While the firefox png resize bug is more visible, I myself value stability more than not being able to see *some* (resized) images; and it was the bug fix that drew me from radeonhd (which also is affected by a similiar bug, but less often) and so I am running a mod of 6.12.2-7 (which fixes xvideo-related issue) with with a slightly mod-version of the -5 patch.
Tried 6.12.2-8.fc11 new on koji a few hour ago - sorry to report that it is sh*t, but I appreciate the effort nonetheless, I really do. When it is installed on my system, the screen just go completely black except the mouse pointer when X/gdm starts. The mouse pointer is responsive on the black background and so is ctrl-alt-f2/f3/f4/f5/f6, although the virtual console shows *nothing* (not even pointer) whatsoever. At that point, at least one can do control-alt-del to reboot cleanly. There is no other symptom in the X log, other than just one line at the end: (WW) xf86CloseConsole: VT_WAITACTIVE failed: Interrupted system call (this is probably from the ctrl-alt-del) FWIW, other than the typo (which upstream seems to confirm), I think the first chunk of the older patch should be like this, instead of just the last line - and this is what I am using; doesn't not help the png problem, but it feels correct: + if (unit != 0 || !info->accel_state->need_src_tile_x || !info->accel_state->need_src_tile_y) + txfilter |= R300_TX_CLAMP_R(R300_TX_CLAMP_WRAP); + else + txfilter |= R300_TX_CLAMP_R(R300_TX_CLAMP_CLAMP_GL); + I have the ati rs690 register guide, I just don't quite get the meaning of S,T,R, repeatnormal, repeatpad, etc. Is there an intro somewhere about the 3 co-ordinates and repeat* and texture more generally?
Tried 6.12.2-9.fc11: the resized png problem on firefox web pages is gone, but xvideo is now scaled wrongly. I'll attach the screenshot of mplayer playing a movie with "-vo x11" and "-vo xv" for illustration in the xv to Bug 497755 . (which probably should depend on bug 492685); but others can just trying playing some movie with "-vo x11" (without acceleration) and "-vo xv" (with xvideo) and compare. I looked at the -8 to -9 code change and there is no change in the tx clamp patch, but in the kms gamma patch, so that's probably the reason for the blank screen. The clamp patch seems to cause xvideo to scale movie display wrongly. Hope this helps.
I tried scaling the wrong screenshot to match the right screenshot, and it looks like the wrong one is wrong in the horizontal direction by about 1.5 and in the vertical direction by about 3 (a little less, ~ 2.8) . i.e. if you have a correct screenshot at 1024 x 768, it is as if the code somehow scale it up to 1536 x 1536 then clip to get only the top left corner of the enlargement.
Confirmed problem gone with 6.12.2-9.fc11 (required kernel 2.6.29.1-111.fc11). Xvideo is bust indeed, but that probably needs a new bug.
Created attachment 341797 [details] Unrelated: bizarre artefacts in Xvideo It's not just scaled so that the upper left corner is visible, but also produces strange artefacts when overlayed with menus. Anyway, needs its own bug.
(In reply to comment #17) > Xvideo is bust indeed, but that probably needs a new bug. There are already two xvideo-related reports... one from the initial acceleration change I think, and another for the -5/-6 change... now xvideo is broken in a different way :-). The png and xvideo issue are related..., my own priority is (1) do not crash/hang, (2) xvideo, (3) resized graphics in firefox . So until the hang fix, I was using redeonhd, because it hangs less often (and I also needed nomodeset to have xvideo/dri - see redeonhd bug list); now I am using the ati/radeon driver, but I prefer to stay with 6.12.2-7.fc11 for the rs690 clamp fix plus the rest from -9, because xvideo is more important to me than resized graphics. Ok, if all graphics are gone I'll reconsider - or use seamonkey - which doesn't seem to be affected. I can live without a small amount of (resized) images.
Created attachment 341919 [details] a modified rs690 tx clamp patch that seems to work This patch seems to get both png and xvideo to work - I don't know how/why, but please consider packaging it and/or committing up stream. The way I came to it is this: we know the hang can be fixed by texture clamp; there are two ways of clamping (-5) and (-9), one breaks resized png and one breaks xvideo. (hmm, their breaking are both related to scaling - "resized" png breaks, and xvideo seems to be scaled to a wrong size then clipped?). But the patch itself modifies two files, one mostly to do with display, the only with video. So I took half of one patch and join it with the other half of the other patch. I don't know why this works, but it does.
-12 still broken, with latest mesa/kernel/xserver. kernel-2.6.29.2-129.fc11 Wed 06 May 2009 07:43:51 BST kernel-headers-2.6.29.2-129.fc11 Wed 06 May 2009 07:43:33 BST kernel-devel-2.6.29.2-129.fc11 Wed 06 May 2009 07:39:50 BST kernel-doc-2.6.29.2-129.fc11 Wed 06 May 2009 07:37:31 BST kernel-firmware-2.6.29.2-129.fc11 Wed 06 May 2009 07:36:48 BST mesa-libGLU-7.5-0.14.fc11 Wed 06 May 2009 07:29:33 BST mesa-libGL-7.5-0.14.fc11 Wed 06 May 2009 07:29:32 BST mesa-libGLU-devel-7.5-0.14.fc11 Wed 06 May 2009 07:29:30 BST mesa-libGL-devel-7.5-0.14.fc11 Wed 06 May 2009 07:29:24 BST mesa-dri-drivers-7.5-0.14.fc11 Wed 06 May 2009 07:29:18 BST mesa-libGLU-7.5-0.14.fc11 Wed 06 May 2009 07:29:16 BST mesa-libGL-7.5-0.14.fc11 Wed 06 May 2009 07:29:14 BST mesa-dri-drivers-7.5-0.14.fc11 Wed 06 May 2009 07:29:13 BST xorg-x11-drv-ati-debuginfo-6.12.2-12.fc11 Wed 06 May 2009 07:15:40 BST xorg-x11-drv-ati-6.12.2-12.fc11 Wed 06 May 2009 07:15:38 BST xorg-x11-server-Xvfb-1.6.1-11.fc10 Wed 06 May 2009 07:13:29 BST xorg-x11-server-Xorg-1.6.1-11.fc10 Wed 06 May 2009 07:13:22 BST xorg-x11-server-devel-1.6.1-11.fc10 Wed 06 May 2009 07:13:12 BST xorg-x11-server-debuginfo-1.6.1-11.fc10 Wed 06 May 2009 07:12:35 BST xorg-x11-server-common-1.6.1-11.fc10 Wed 06 May 2009 07:12:18 BST
replacing the rs690 patch in -12 with my mod patch (comment 20) seems to work fine. Consider taking it? Please?
I cannot install -12 on my Rawhide system: there's an ABI conflict with exa module and X fails to start (rpm -i completes fine, so there's some missing Requires: somewhere). I don't know where Hin-Tak gets the packages listed in comment #21, they aren't in Koji (let alone Rawhide). So I'm on 6.12.2-9 for now. There are no black rectangles.
-12 requires newer X server, works for me with xorg-x11-server-Xorg-1.6.1-11.fc11 http://koji.fedoraproject.org/koji/buildinfo?buildID=100806
(In reply to comment #23) > I cannot install -12 on my Rawhide system: there's an ABI conflict with exa > module and X fails to start (rpm -i completes fine, so there's some missing > Requires: somewhere). I don't know where Hin-Tak gets the packages > listed in comment #21, they aren't in Koji (let alone Rawhide). > So I'm on 6.12.2-9 for now. There are no black rectangles. The rest are from koji, but I did rpmbuild --rebuild http://kojipkgs.fedoraproject.org/packages/xorg-x11-server/1.6.1/11.fc11/src/xorg-x11-server-1.6.1-11.fc11.src.rpm to put it on F10. It is as somebody else commented, due to additional dependencies, I need to do rpmbuild --rebuild the server, but the rest of F11 bits seems to go onto F10 quite happily. If you want to try out comment 20, what I did was to rpm -i the src rpm (which puts the bits under /root/rpmbuild/{SOURCES,SPECS}), replace the patch, then run rpm -bb xorg-x11-drv-ati.spec
Created attachment 342835 [details] src rpm - xorg-x11-drv-ati-6.12.2-12a.fc10.src.rpm Just -12 with the rs690 patch replaced with https://bugzilla.redhat.com/attachment.cgi?id=341919 - this is a src rpm and you are supposed to run rpmbuild --rebuild to generate the x86/x86_64 rpms for install. so it is called -12a . Hope this is useful to sombody else. you can compare src rpm contents by extract it all (in a new empty dir): rpm2cpio src.rpm | cpio --extract -m
I wonder if Bug 499930 ( firefox tooltips corruption https://bugzilla.redhat.com/attachment.cgi?id=343194) and some font encoding issue ( https://bugzilla.redhat.com/attachment.cgi?id=342629 ) are related - the two kind of corruptions seems to be affected by setting MOZ_DISABLE_IMAGE_OPTIMIZE=1 in opposite way - one is caused by it and the other is cured/worked-around by it, I think.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I put -18 from koji on, and the problem persists. just replacing the 690-hack patch with attachment 341919 [details] works. Also, there is a small bug with the acceleration code that has been around for a while, and this is the fix: --- xf86-video-ati-6.12.2/src/radeon_textured_videofuncs.c~ 2009-05-23 06:48:26.000000000 +0100 +++ xf86-video-ati-6.12.2/src/radeon_textured_videofuncs.c 2009-05-26 10:59:18.000000000 +0100 @@ -1604,7 +1604,7 @@ } } - qwords = info->new_cs ? 8 : 6; + qwords = info->new_cs ? 7 : 6; BEGIN_ACCEL(qwords); OUT_ACCEL_REG(R300_TX_INVALTAGS, 0); OUT_ACCEL_REG(R300_TX_ENABLE, txenable); ------------ the png black rectangles can be seen on youtube or facebook; the acceleration code bug is faily harmless - without the fix, it just pumps lots of warning messages about some number being 14 and not 16 into Xorg.0.log, if one plays movies with mplayer.
I don't know about Hin-Tak's system, but I did not see the black rectangles in a while (currently xorg-x11-drv-ati-6.12.2-19.fc12.x86_64).
(In reply to comment #30) > I don't know about Hin-Tak's system, but I did not see the black rectangles > in a while (currently xorg-x11-drv-ati-6.12.2-19.fc12.x86_64). As I said, -18.fc11 still show black rectangles. There is a solution to my problem - the patch I attached to replace the latest rs690 tx clamp D Airlie includes in -18.fc11 ; I just don't know why it works. (I looked at 19.fc12, but it requires the newer bleeding edge X server headers). There are a couple of black rectangles at the front of youtube (as guest, no account required), and a lot on facebook (account required). if it helps, here is the relevant part of lspci -vvv: ----------- 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] (prog-if 00 [VGA controller]) Subsystem: Toshiba America Info Systems Device ff1a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at f0000000 (64-bit, prefetchable) [size=128M] Region 2: Memory at f8100000 (64-bit, non-prefetchable) [size=64K] Region 4: I/O ports at 9000 [size=256] Region 5: Memory at f8000000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at <unassigned> [disabled] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] MSI: Mask- 64bit+ Count=1/1 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: radeon Kernel modules: radeon ----------------
I recently upgraded Fedora 10 to 11 and got black rectangles instead of scaled images. Until accelration code for ATI driver gets fixed my workaround is to put in xorg.conf section "Device" section: Option "RenderAccel" "off" ------------ package versions ----------------------- xorg-x11-drv-ati.i586.6.12.2-14.fc11 xorg-x11-drv-radeonhd.i586.1.2.5-2.8.20090411git.fc11 radeontool.i586.1.5-5.fc11 ------------ lspci -vvv output ----------------------- 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] (prog-if 00 [VGA controller]) Subsystem: Dell Device 0230 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 19 Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at fe9f0000 (64-bit, non-prefetchable) [size=64K] Region 4: I/O ports at ee00 [size=256] Region 5: Memory at fea00000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at <unassigned> [disabled] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] MSI: Mask- 64bit+ Count=1/1 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: radeon Kernel modules: radeon
Quote from one old Radeon driver manpage: http://ftp.x.org/pub/X11R6.9.0/doc/html/radeon.4.html Option "RenderAccel" "boolean" Enables or disables hardware Render acceleration. This driver does not support component alpha (subpixel) rendering. It is only supported on Radeon series up to and including 9200 (9500/9700 and newer unsupported). The default is to enable Render acceleration. This bug manifests only on downscaled images and i guess it's about subpixel rendering hardware acceleration.
(In reply to comment #29) > I put -18 from koji on, and the problem persists. just replacing the 690-hack > patch with attachment 341919 [details] works. I wanted to add that this patch seems to have resolved my black resized image issues. Thanks for posting! DPMS still doesn't turn off my lcd unless I use the nomodeset kernel option but then X is unstable and will lock up at certain (frequent) times if I make use of that. Also I wanted to add that the problem with the X display becoming a completely garbled mess still persists. A good way to make this happen is to go to google maps and do some zooming in and zooming out with the mouse scroll wheel. ----------------------------------------------------------------------------- $lspci -v 01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] Device 028c Flags: bus master, fast devsel, latency 64, IRQ 18 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at f0100000 (64-bit, non-prefetchable) [size=64K] I/O ports at 9000 [size=256] Kernel driver in use: radeon Kernel modules: radeon $uname -r 2.6.29.6-217.2.3.fc11.x86_64
I'm still seeing this problem in fully updated F11, ATI RS690M. It's trivially reproducible by zooming out a web page containing images in Firefox. Dave, several people had success with the clamping patch modified by Hin-Tak Leung. Could you comment on the patch?
I should add that switching to the radeonhd driver solved all of my X issues with RS690M. (package: xorg-x11-drv-radeonhd)
Created attachment 360808 [details] gromobir's dmesg output
This is still a problem on Fedora 11. Please check my dmesg output above and let me know if you need any more information.
I have modifed the clamp patch and see which values are shown in normal course of operation, so this is a typical usage: 6926 VTX_OUT srcX > 1 9148 VTX_OUT srcY > 1 526144 VTX_OUT_MASK srcX > 1 86 VTX_OUT_MASK srcX < 0 556356 VTX_OUT_MASK srcY > 1 84 VTX_OUT_MASK srcY < 0 1500 VTX_OUT_MASK maskX > 1 1518 VTX_OUT_MASK maskY > 1 I think I have also seen VTX_OUT srcX < 0 a few times; I am wondering about the maskX <0 and maskY < 0 case - is it possible to try these cases explicitly? (i.e. what kind of operation can exercise negative mask values for this code path?) Also I wonder about signed negative zero at floating point - the specific code converts numbers from float to double-word before byte-outputing to the hardware. Presumably negative zeros are sent as negative zeros. For those who wants to experiment, to build -18 with recent x-server/libdrm, most of a commit 'radeon: Fix DRI2BufferPtr to be DRI2Buffer2Ptr for xserver 1.6.' is needed. I am mostly thinking that the RS690 doesn't like maskX/maskY negative, but I don't know how to make it happen...
Did you try lastest fedora 12 (test livecd for instance) ? If so does it works properly with it ?
I don't see this problem with rawhide, on the same hardware that has the problem with F11+updates
F12 works fine for me too, no black rectangles.
Ok closing the bug.