This bug was discovered when running gstreamer's Xv output on a Radeon 9000M9.
gstreamer would crash because of an incorrect value returned from the radeon
driver. A patch was submitted to gstreamer to avoid crashing, though the video
output is heavily corrupt as a result of the incorrect allocation.
The gstreamer bug has many details:
In a nutshell, "XvShmCreateImage returns an xvimage structure with a data_size
set to half what it should be for the 32bit format that was negotiated."
Just to update, this bug still exists with Radeon 9000M9 on Xorg 7.0.0
Can an X/Radeon hacker please comment on this bug?
Looks like radeon_video.c may be missing some code for FOURCC_RGB*, in
particular in RADEONQueryImageAttributes().
Created attachment 5273 [details] [review]
add handling for FOURCC_RGB*
(In reply to comment #3)
> Looks like radeon_video.c may be missing some code for FOURCC_RGB*, in
> particular in RADEONQueryImageAttributes().
Indeed. Patch attached which improves the situation. Not sure if it will apply
cleanly to HEAD, there have been some other changes made.
On the release I have (xserver-xorg-driver-ati-126.96.36.199), with the patch, I get
wrong colours (wrong endianness maybe), but at least it's allocating a buffer of
the right size now.
I need to test CVS - the other Xv related changes may have already fixed the
(In reply to comment #5)
> I need to test CVS - the other Xv related changes may have already fixed the
> colours issue.
Turns out that the Dapper package I'm running already has CVS, so that doesn't
help. It's also possible that this is an endianness issue in the GStreamer Xv
element, since RGB Xv output has never been tested before. I'll look into that.
*** Bug 6614 has been marked as a duplicate of this bug. ***
If there is no good solution, X.Org 7.1 should ship with RGB Xv overlays
disabled in the ati video driver.
Adding to 7.1 Release Tracker
Patch committed to xf86-video-ati HEAD, thanks.
I see the byte order breakage as well, I guess you're also running on a big
endian machine Jan? :) For that, it should be checked if/how the byte order of
the data on the wire is defined, and another bug should be filed if necessary.
(In reply to comment #10)
> I see the byte order breakage as well, I guess you're also running on a big
> endian machine Jan? :) For that, it should be checked if/how the byte order of
> the data on the wire is defined, and another bug should be filed if necessary.
No, I'm on Pentium-M laptop. Sorry - I haven't gotten back to figure out whether
it's a server or client problem yet.