It almost looks like a kalidescope. I'll attach a picture and my X.org log. lspci: 01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M] (prog-if 00 [VGA]) Subsystem: Gateway 2000 Unknown device 0318 Flags: bus master, 66MHz, medium devsel, latency 66, IRQ 10 Memory at d0000000 (32-bit, prefetchable) [size=256M] I/O ports at 9000 [size=256] Memory at c0000000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at c0020000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
Created attachment 11943 [details] Xorg.0.log This is on suse 10.3 (amd64) xorg 7.2. Gateway ml3109 laptop.
Created attachment 11944 [details] camera snapshot of corrupted xvideo output
I end up using the 'radeonold' driver so that xvideo works. ('radeonrandr12' also has this same problem reported above). Although, using radeonold has the problem reported in #12743 .
The overlay on the XPRESS chips may have additional limitations we don't know about (no documentation). The fix for bug 1462 may be what's causing this bug. If you revert that code, it may fix this bug.
(In reply to comment #4) > The overlay on the XPRESS chips may have additional limitations we don't know > about (no documentation). The fix for bug 1462 may be what's causing this bug. > If you revert that code, it may fix this bug. That code can only be an issue if the video in question has more than the maximum supported width (i.e. 1536). You also could get back the old behaviour by setting "OverlayWidth" option to 1920 in your xorg.conf (you can override it because we don't know the supported width for each chip - we DO know it for those rs480 chips though, apparently). Maybe the chips have an issue with planar video though, which wasn't supported in 6.6.3 neither natively (was converted to packed). If that's the case, something like mplayer -vf format yuy2 should show a correct picture.
I get the same effect on frame sizes smaller than hd... so it's probably not the pink bar issue. I'll try the mplayer suggestion to see if that works.
mplayer -vf yuy2 worked wonderfully. I even tried a 1080 clip and it looked great. I'm assuming it does the scaling as talked about in #1462 , but it still looked quite good.
(In reply to comment #7) > mplayer -vf yuy2 worked wonderfully. Hmm. Could you try with a newer driver? Not that I'd think there are any fixes which could affect it, but you never know... Otherwise, it looks like either xpress 200 chips (all of them?) don't support planar yuv, or need a somewhat different setup - both of those seem a bit strange considering the overlay is pretty much the same for r100-r4xx (and even older ati chips, actually). We'd need some input from ati to confirm, or someone could spy on the overlay regs while running fglrx (and using overlay-based xv). Of course, the old code to convert it to packed yuv in the driver could be readded (removed it as all radeon chips I knew of supported planar yuv just the same) for those chips, but it's certainly not as efficient as using planar yuv directly. > I even tried a 1080 clip and it looked great. I'm assuming it does the scaling > as talked about in #1462 , but it still looked quite good. If you're using a monitor with a horizontal resolution lower than 1920 you're unlikely to ever notice. I've tried with 1920 and it still looked great - I'd guess you'd need direct comparison side-by-side to really see it with normal video source material.
Created attachment 11980 [details] Xorg.0.log I built the latest from git without any changes or improvements. (My checkout ended in c9264aa53bf1470ad9104d1e7c4a8ce13c49c270) Attaching Xorg.0.log...
Created attachment 12159 [details] xvinfo output
Bug has also been noted at https://bugzilla.redhat.com/show_bug.cgi?id=427450
(In reply to comment #8) > Of course, the old code to convert it to packed yuv in the driver could be > readded (removed it as all radeon chips I knew of supported planar yuv just the > same) for those chips, but it's certainly not as efficient as using planar yuv > directly. Still, we should probably do that or just disable planar YUV for these chipsets for now?
(In reply to comment #12) > (In reply to comment #8) > > Of course, the old code to convert it to packed yuv in the driver could be > > readded (removed it as all radeon chips I knew of supported planar yuv just the > > same) for those chips, but it's certainly not as efficient as using planar yuv > > directly. > > Still, we should probably do that or just disable planar YUV for these chipsets > for now? Some video players though AFAIK really need this format, so adding back the planar-to-packed conversion is probably needed. I was hoping maybe we could avoid it if those chips would support planar yuv but needed different setup, but I guess I'll have to fix it now...
Created attachment 14335 [details] [review] bring back to life planar-to-packed conversion for rs4xx Here's a patch to bring back the code for converting planar yuv to packed yuv, if a RS400 family chip is used (though I've no idea if they really all fail with planar yuv). I'm currently unable to test this, so YMMV.
(In reply to comment #14) > Created an attachment (id=14335) [details] > bring back to life planar-to-packed conversion for rs4xx > > Here's a patch to bring back the code for converting planar yuv to packed yuv, > if a RS400 family chip is used (though I've no idea if they really all fail > with planar yuv). I'm currently unable to test this, so YMMV. > I'd say go ahead an commit it. I took at look at the RS4xx registers and they should be able to support the planar formats, but in practice they don't seem to.
(In reply to comment #14) > Created an attachment (id=14335) [details] > bring back to life planar-to-packed conversion for rs4xx > > Here's a patch to bring back the code for converting planar yuv to packed yuv, > if a RS400 family chip is used (though I've no idea if they really all fail > with planar yuv). I'm currently unable to test this, so YMMV. > I tested this patch and the planar to packed conversion path works fine.
I went ahead and committed Roland's patch: 03aa4cc6d6e8c715a1c1d677cc1845223505b358
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.