I report the same bug on Radeon 9200 and Radeon M9 in Xorg 6.8.2. The Xv clearly
has some problems handling the 1920x1080 overlay (in any screen resolution).
However this is not a hardware limitation, it works in XP with ATI drivers just
fine.

*** Bug 3226 has been marked as a duplicate of this bug. ***

Still there in rc1. 
Can we make this a blocker for the 6.9/7.0-release? 

> Außerdem war die Gewwerkschaft BCE noch nie für einen Atomausstieg.  
> Sowohl in Ahaus als auch in Gronau haben die gegen uns demonstriert, für  
> ihre Arbeitsplätze. Dumm wie Brot. 
 
Ich denke, es ist wichtig, dass wir uns jetzt nicht vor den Karren  
"Atomausstieg rot-grün verteidigen" spannen lassen... 
bis später, markus 

Sorry for that comment above, just saw this, seems to be accidently pasted and 
clicked by me, no idea how. 

I'm not sure this deserves to be a blocker for 6.9/7.0. It's not a regression
over older releases, it's not even clear that it's not at least partly a
hardware limitation. Even ignoring that, it's a pretty exotic use case with a
pretty specific setup, so the affected user base should be fairly small.

just chiming in, I get this bug on my radeon 9250 as well

i'm just a noob, but i notice this bug was reported over a year ago.  any
progress at all?  i would gladly donate my 9250 to someone that would like to
fix this, since it is nearly worthless to me if it can't do high res playback
with XV :P

Michael, I don't think this is an exotic case at all.

It isn't a hardware limitation as I have used the same card (r9250) under Win XP
for 1080i and 1080p content without problems, where x.org and the radeon driver
give the pink band on either. 

Here's why it isn't an exotic case:
-the R92x0 cards are the best-performing (readily available) add-on cards with
open drivers, with full 3D support
-they are fanless, i.e. silent, which makes them perfect for HTPC setups such as
mythtv
-many MANY broadcasts are now in 1080i and more to come

This means this is a serious problem for a significant proportion of users.
Please give this bug some love and care!!

(In reply to comment #7)
> Michael, I don't think this is an exotic case at all.
> 
> It isn't a hardware limitation as I have used the same card (r9250) under Win XP
> for 1080i and 1080p content without problems, where x.org and the radeon driver
> give the pink band on either. 

windows may not be using the video overlay.  it may be using a blitter interface
or YUV textured rectangles.  It's still possible that this is at least partly a
hardware limitation.

(In reply to comment #8)
> (In reply to comment #7)
> > Michael, I don't think this is an exotic case at all.
> > 
> > It isn't a hardware limitation as I have used the same card (r9250) under Win XP
> > for 1080i and 1080p content without problems, where x.org and the radeon driver
> > give the pink band on either. 
> 
> windows may not be using the video overlay.  it may be using a blitter interface
> or YUV textured rectangles.  It's still possible that this is at least partly a
> hardware limitation.
> 

Is there anything that makes you think that this is a hardware limitation
though? It seems like an easy way to ignore the bug, and this is not an old
card. It has what should be enough RAM (128Mb), and like Bernhard said in the
first place, FWIW xvinfo suggests it's capable of 2048x2048.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Michael, I don't think this is an exotic case at all.
> > > 
> > > It isn't a hardware limitation as I have used the same card (r9250) under
Win XP
> > > for 1080i and 1080p content without problems, where x.org and the radeon
driver
> > > give the pink band on either. 
> > 
> > windows may not be using the video overlay.  it may be using a blitter interface
> > or YUV textured rectangles.  It's still possible that this is at least partly a
> > hardware limitation.
> > 
> 
> Is there anything that makes you think that this is a hardware limitation
> though? It seems like an easy way to ignore the bug, and this is not an old
> card. It has what should be enough RAM (128Mb), and like Bernhard said in the
> first place, FWIW xvinfo suggests it's capable of 2048x2048.

I'm not sure what the limits of the overlay are off hand, but as you and others
have noted, it doesn't seem to work for especially large videos.  I don't see
anything off hand in the source or the radeon documentation indicating that
anything special needs to be done for very large overlays, hence it seems like a
hardware issue.  The texture engine should be able to handle it, so that may be
what windows does.

I have the same problem on my radeon VE and 9250 with 64 bit chip to memory  
bus. Has anyone verified that this bug shows up on the more expensive cards  
with 128 bit buswidth. Maybe xvinfo is indicating the chips capabilities 
correctly only if fast-wide ram is attached.  

I have the sam problem on the X800 the fglrx driver from ATI does this ok.

(In reply to comment #12)
> I have the sam problem on the X800 the fglrx driver from ATI does this ok.

(must be late)

I have the same problem on the RADEON X600,  the fglrx driver from ATI does 
this ok (but has worse problems).

Ok, there seem to be some dodgy code in there indeed. Can you guys try    
changing those few bits and tell me if that helps ? Try both changes    
separately then together and tell me if anything helps.    
    
In radeon_video.c, find RADEONAllocAdaptor() function. The first bit to change    
looks like that:    
    
     /* overlay scaler line length differs for different revisions    
       this needs to be maintained by hand  */   
    switch(info->ChipFamily){   
    	case CHIP_FAMILY_R200:   
	case CHIP_FAMILY_R300:   
		pPriv->overlay_scaler_buffer_width=1920;   
		break;   
	default:   
		pPriv->overlay_scaler_buffer_width=1536;   
    	}   
   
As an experiment, can you try removing it and forcing that:   
   
	pPriv->overlay_scaler_buffer_width=1920;   
   
I suspect the list of chip families in that list is very incomplete.   
   
Another one that might help the 92xx is this bit:   
   
    if (IS_R300_VARIANT ||   
        (info->ChipFamily == CHIP_FAMILY_R200))   
	x_off = 0;   
   
Try changing it to:   
   
   
    if (IS_R300_VARIANT ||   
        info->ChipFamily == CHIP_FAMILY_R200 ||  
        info->ChipFamily == CHIP_FAMILY_RV280)  
	x_off = 0;   
   
Then let me know the results. 
 
 

Tried both separately and together, no change at all. 

FWIW, fglrx can't handle that neither (8.23.7, rv250). Exactly the same pink
line (which is just the colorkey) is seen.

Some more tests. Interestingly, this actually works on my old radeon (7200).
I've also increased the buffer_width there to 1920 and it STILL worked (I can
output it only downscaled, but the resulting step_by values were indeed
different (1 instead of 2) when doing that).
I have no idea why it doesn't work with the rv250, ati's spec page even mentions
it should be possible to do 1920 (mentioned under video features, along with
deinterlacing and such). Maybe that's a misprint, or it's a chip bug, or it
needs some different setup (is the overlay setup really 100% identical between
r100 and r200 chips?).

Just to chime in with an AOL, I also see this bug on a Radeon 9000M, with X.org
7.0.0 (Ubuntu Dapper)

Here's an easy way to reproduce it:

gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=1536 ! xvimagesink

Change the width to anything larger to see the pink (which doesn't actually
appear to be the color key here)

(In reply to comment #18)

Thanks for the easy way to reproduce. I don't see the pink line, running on an
M9 as well, but I'm running more or less current CVS, maybe Roland's Xv fixes
fixed this? 

(In reply to comment #19)
> (In reply to comment #18)
> 
> Thanks for the easy way to reproduce. I don't see the pink line, running on an
> M9 as well, but I'm running more or less current CVS, maybe Roland's Xv fixes
> fixed this? 

Is it possible for me to build that module and expect it to run against the
installed dapper Xorg I have, or will I need to build a whole stack?

The CVS ati-1-0-branch should build on dapper.

(In reply to comment #21)
> The CVS ati-1-0-branch should build on dapper.
A snapshot should do too. That said, I still get that pink line, the xv fixes
didn't change that. Using native yuv9 planar hw overlay format instead of
converting to packed yv12 (not in cvs as it's a bit broken) doesn't help neither.
btw, that easy to reproduce way doesn't work for me at all, dunno if that's a
problem with the gstreamer build (0.10.4)
gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=1536 ! xvimagesink
FEHLER: Leitung konnte nicht konstruiert werden: Kein Element »videotestsrc«.

(In reply to comment #22)
> (In reply to comment #21)
> > The CVS ati-1-0-branch should build on dapper.
> A snapshot should do too. That said, I still get that pink line, the xv fixes
> didn't change that. Using native yuv9 planar hw overlay format instead of
> converting to packed yv12 (not in cvs as it's a bit broken) doesn't help neither.

It turns out that the current dapper package has current CVS of the
ati-1-0-branch anyway.

> btw, that easy to reproduce way doesn't work for me at all, dunno if that's a
> problem with the gstreamer build (0.10.4)
> gst-launch-0.10 videotestsrc ! video/x-raw-yuv,width=1536 ! xvimagesink
> FEHLER: Leitung konnte nicht konstruiert werden: Kein Element »videotestsrc«.

You're missing the videotestsrc GStreamer element, which probably means you
don't have most of GStreamer installed. On dapper, that element (as well as
xvimagesink) is in the gstreamer0.10-plugins-base package.

Oh and while I remember, atipciids.h seems to have been added recently, but
isn't yet disted in the Makefile.am. Doesn't seem worth filing an extra bug over:

Index: src/Makefile.am
===================================================================
RCS file: /cvs/xorg/driver/xf86-video-ati/src/Makefile.am,v
retrieving revision 1.10
diff -r1.10 Makefile.am
125a126
>       atipciids.h \

Could this be a similar problem as bug 6548, i.e. an integer overflow of some kind?

I am also getting a big pink bar on the right side at 1080I. My hardware and
software is a bit different though. The hardware is a Dell Latitude C640 with

>Device "ATI Technologies, Inc. Radeon Mobility M7 LW [Radeon Mobility 9000]"

I'm running on Ubuntu Edgy with

X Window System Version 7.1.1
 ATI: ATI driver (version 6.6.2) for chipsets: ati, ativga 
 R128: Driver for ATI Rage 128 chipsets:
 RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP)
Module radeon: vendor="X.Org Foundation"
        compiled for 7.1.1, module version = 4.2.0
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 1.0

The Bios shows 32MB of video memory and xvinfo shows 2048x2048.

All of vlc,xine and mplayer show the big pink bar covering the right 1/3 of the
image. Mythtv shows nothing, just a blue screen with sound.

At 720P its ok,

Any suggestions?

(In reply to comment #25)
> Could this be a similar problem as bug 6548, i.e. an integer overflow of some
kind?
Considering the same code works on r100, I don't think so. Looks more like a hw
limitation to me (too small buffer for the overlay scaler), it may be possible
to handle this by configuring the overlay differently, though last time I
checked fglrx couldn't handle it neither (on rv250). Textured video would avoid
that problem for sure.

(In reply to comment #26)
> I am also getting a big pink bar on the right side at 1080I. My hardware and
> software is a bit different though. The hardware is a Dell Latitude C640 with
> 
> >Device "ATI Technologies, Inc. Radeon Mobility M7 LW [Radeon Mobility 9000]"
Where the heck did you get that device string? Would be good to know if it'a M7
LW (aka mobility 7500) or a m9 (mobility 9000).

> The Bios shows 32MB of video memory and xvinfo shows 2048x2048.
the driver will always report this resolution regardless of the chip capabilities.

> All of vlc,xine and mplayer show the big pink bar covering the right 1/3 of the
> image.
This looks like exactly this issue - I think the pink line starts at video pixel
1536.

> Mythtv shows nothing, just a blue screen with sound.
Looks like a different bug to me. Maybe a problem with your mythtv version.

Created attachment 7847 [details] [review]
quick workaround

Here's a quick patch which fixes the problem for me. However, this will result
in sub-optimal quality, as you'd basically get scaled 960x1080 content instead
of the full scaled 1920x1080 (though I'm not exactly sure how the chip
pre-downscales). Not sure if it's possible to do any better with these chips?
btw, the list which chips support overlay width 1920 and which 1536 is likely
very bogus, someone knows which chip supports what? At least original r100
apparently seems to do 1920 just fine.

(In reply to comment #29)
> quick workaround
> 
> Here's a quick patch which fixes the problem for me. However, this will result
> in sub-optimal quality, as you'd basically get scaled 960x1080 content instead
> of the full scaled 1920x1080 (though I'm not exactly sure how the chip
> pre-downscales).
Any comment on this? If nobody thinks the chips really can do this better I'm
going to check in something along these lines. It would be good if someone from
ATI could at least tell which chips have a scale buffer good enough for 1536 and
which for 1920 pixels, but in absence of that maybe we should make it possible
to override that setting in xorg.conf.

Ok, fixed in git. It definitely reduces quality (but so would the non-working
previous code for dealing with videos which don't fit into the scaler) if you
compare it directly (at least if you don't downscale anyway). Scalar buffer
width is even user-configurable so you can override it if the driver gets it
wrong (which is probably likely for r350 at least). I do not think it's possible
to do better (unless you use textured video).

If I'm not experiencing the pink area in a 1920x816 video with xf86-video-ati 6.6.3 does this mean that my video card (Radeon X550 RV370 5B63 PCIE) has a scalar buffer width >= 1920?

*** Bug 12743 has been marked as a duplicate of this bug. ***

Shouldn't have this been included in 7.2?  (I'm still seeing the problem in suse 10.3 running xorg 7.2, but it's with 'radeonold').

Or, is #12744 preventing me from seeing this fix?

Also, any plans to have textured video?  If so, will this interface be available as an xvideo interface?

(In reply to comment #34)
> Shouldn't have this been included in 7.2?  (I'm still seeing the problem in
> suse 10.3 running xorg 7.2, but it's with 'radeonold').
Well, 6.6.3 is a year old - just very slightly older than that fix...

> Or, is #12744 preventing me from seeing this fix?
Yes, the fix would be in 6.6.193. #12744 looks unrelated (unless it would only happen with hd video - there's always the possibility some bits change from chip to chip).

> Also, any plans to have textured video?
I don't think anyone is currently working on it. It will be required for the avivo-based chips (r5xx and newer), but certainly someone could implement it for the older chips.

> If so, will this interface be
> available as an xvideo interface?
Yes, should be (same as the intel driver handles this).