| Summary: | XvShmCreateImage returns incorrect data_size | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Pat Suwalski <pat> | ||||
| Component: | Driver/Radeon | Assignee: | Xorg Project Team <xorg-team> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | high | CC: | alexdeucher, arne, thaytan | ||||
| Version: | 7.0.0 | ||||||
| Hardware: | x86 (IA32) | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 5041 | ||||||
| Attachments: |
|
||||||
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-6.5.7.3), 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 colours issue. (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. |
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.
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: http://bugzilla.gnome.org/show_bug.cgi?id=315312 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."