27.8.2010 10.45, Michel Dänzer kirjoitti:
On Fre, 2010-08-27 at 10:29 +0300, Heikki Lindholm wrote:
27.8.2010 10.07, Michel Dänzer kirjoitti:
On Fre, 2010-08-27 at 09:58 +0300, Heikki Lindholm wrote:
27.8.2010 9.38, Michel Dänzer kirjoitti:
On Mon, 2010-08-23 at 09:52 +0300, Heikki Lindholm wrote:
Column order is wrong on big endian systems, primarly because of a
bits / bytes mix up with the bpp variable. Fix tested with r100 and
r300, screen depth 16 and 32 with YV12 and YUY2 (overlay, textured video),
RGBA and RGBT (overlay).
Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=29041
Signed-off-by: Heikki Lindholm<[email protected]>
---
src/radeon_video.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/radeon_video.c b/src/radeon_video.c
index dc75279..1a42951 100644
--- a/src/radeon_video.c
+++ b/src/radeon_video.c
@@ -2216,11 +2216,15 @@ RADEONCopyData(
swap = RADEON_HOST_DATA_SWAP_32BIT;
break;
}
- } else if (bpp != pScrn->bitsPerPixel) {
- if (bpp == 8)
+ } else {
+ switch (pScrn->bitsPerPixel) {
+ case 16:
+ swap = RADEON_HOST_DATA_SWAP_16BIT;
+ break;
+ case 32:
swap = RADEON_HOST_DATA_SWAP_32BIT;
- else
- swap = RADEON_HOST_DATA_SWAP_HDW;
+ break;
+ }
}
#endif
I'm also not sure why this path shouldn't need to take bpp into account,
at least in addition to pScrn->bitsPerPixel. Did you make sure you
tested this function being called with bpp=1,2,4 in both depth 24 and
16?
Once again, have you tested in depth 16 as well as 24?
Yes, like I said in my orig. mail. All listed bpps tested with depth 16
and 24, and some with depth 15 even.
Sorry I missed / forgot about that, thanks for confirming.
I know of no real application that uses the RGB modes though, [...]
How did you test it? I think some emulators (can) use it.
Modified the testxv (writes its image bytewise, so it shouldn't have
endian problems)
Depends how XVideo defines these formats. E.g. snes9x has an option to
byte-swap the XVideo data, so there may have been some uncertainty or at
least confusion about that.
D'oh. Some of the RGB modes are actually native endian. I'll have to fix
those. Shall we have it on top of the already committed patch or revert
that and do a new one?
-- Heikki Lindholm
_______________________________________________
xorg-driver-ati mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-driver-ati
