| Summary: | Radeon 9200 PRO (RV280) with EXA acceleration displays random colour patterns for Xv overlays | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Tom Hughes <tom> | ||||||||||||||||||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||||
| Priority: | medium | CC: | bugzi11.fdo.tormod | ||||||||||||||||||||
| Version: | unspecified | ||||||||||||||||||||||
| Hardware: | x86 (IA32) | ||||||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
Created attachment 17880 [details]
Photo of corrupt display
please attach your xorg log and config. Created attachment 17891 [details]
xorg.conf configuration file
Created attachment 17893 [details]
Xorg log file
This log covers X startup and an attempt to play video with mplayer (though I don't believe that produced any extra messages).
Created attachment 17894 [details]
updated xorg.conf configuration file with cruft removed
Created attachment 17895 [details]
updated Xorg log file
Updated log file - the previous one was done without the TV turned on so didn't have the monitor being detected properly.
What should the original image look like? what format is the src image? Does this option help: Option "ColorTiling" "FALSE" Setting ColorTiling to false doesn't appear to help, no. The image is a TV program - an MPEG-2 stream recorded from a DVB-T card. This is what mplayer says about the format when playing: Starting playback... VDec: vo config request - 720 x 576 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 720x576 => 1024x576 Planar YV12 Is there anything more I can do to try and debug this? Any extra debugging I can turn on when compiling the driver perhaps? Does the following option help? Option "DMAForXv" "FALSE" No, that doesn't make any difference I'm afraid. Does disabling the DRI help? Option "DRI" "FALSE" No, I'm afraid that doesn't seem to help either. Can you try another video app or video format and see if you get similar behavior? I have now tried totem, xine, mplayer and MythTV and all have the same problem. Pretty much every video I tried uses YV12 as the image format though. I have also tried using xvtest to display a fixed test pattern, which is YUYV by default, and that fails. I also tried modifying it to use YV12 and a 24 bit RGB format and both of those fails. You get various different patterns depending on exactly why format you use and what colour pattern you try and display, but it goes wrong with all three formats I have tried. Does limiting the amount of video RAM with
VideoRam 131072
(or halving further) work around the problem? Unless I'm missing something, the OV0_VID_BUFx_BASE_ADRS registers only take 27 bits for the offset, and the EXA offscreen memory area starts beyond that for you...
Bingo! That fixes it. Created attachment 18164 [details] [review] check offset fix The attached patch checks the offset of the allocation and returns BadAlloc if it's beyond the range of the overlay. This doesn't really help though other than providing an error message. I suppose the proper fix would be to adjust OV0_BASE_ADDR to start wherever your offscreen mem pool is. However, you'd then have to subtract out the offset when setting up the overlay. Created attachment 18171 [details] [review] Possible fix How about this one instead? Description inside. Forgot to mention I've verified it doesn't break the overlay here... I'm just building with that patch now and I'll test it this evening. We should probably wait for the MC to be idle before updating OV0_BASE_ADDR. I'm not sure how sensitive that register is. That patch almost works - sometimes I get a good picture and sometimes a (variably sized) chunk of the bottom of the picture is covered with flickery vertical lines. How do I modify the code to wait for MC to be idle before setting that register? Created attachment 18181 [details] [review] Possible fix, take 2 Does this patch work better? If not, apparently the base address is changing while playing a video clip, so disabling the overlay or even waiting for MC idle before updating the base address register would probably cause overlay/display blinking, making this approach infeasible. In that case, another possibility would be to statically move the base address as close as possible to the beginning of the EXA offscreen area and to limit its size to 128 MB on cards which have an overlay. That patch seems to work, yes. Fix pushed: a55e85f742d1334bf88e4681e553f025d2de38df The commit has the opposite effect when using XAA: without the commit it works fine, with the commit I see coloured stripes/flashing. This is when watching DVB-T with the "me-tv" program. You might ask why I use XAA, but I would like to ask why is EXA not default yet? (In reply to comment #28) > The commit has the opposite effect when using XAA: without the commit it works > fine, with the commit I see coloured stripes/flashing. See bug 17254. Please try the patch attached there. Thanks, the patch in that bug seems to fix it. BTW, I did the testing against 1cf7a5494fa94e8d9f30f9b2905dfbe6d4faa445, before the commit flow a week ago. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 17879 [details] Photo of corrupt display I have a Radeon 9200 PRO card (RV280 based) and used with EXA acceleration it fails to display video using Xv. This has been observed both with MythTV and with mplayer (using "-vo xv" as the output driver). The card is: 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) I have tried both the Fedora 8 build of version 6.8.0 of the radeon driver and a build of version 6.9.0 from the source and both give the same results. Using XAA acceleration makes Xv works but unfortunately MythTV's menus are very slow when using XAA acceleration which is why I would like to get EXA acceleration working. I have attached a couple of photos of the random colour pattern that appears in place of the video - one of the whole screen and one close up of a corner of the screen.