Re: Endianity problems in XFree86-4 XAA on MipsEB
Michel Dänzer wrote:
Yes of course, but In the first case the __most__ significant byte of
the bits[0] contains data and in the second case the __last__ significant
byte of the bits[0] contains data. So, you obtain swapped pattern0 and
pattern1 in the tile case.
I see where you're getting at, but does bits[0] really have the same
meaning in both cases?
Yes, I think so.
Let's assume that:
1. bpp = 8, pPixmap-drawable.width = pPixmap-drawable.height = 8;
2. our tile can be reduced to __mono__ 8x8 pattern.
1. stipple case
XAACheckStippleReducibility(PixmapPtr pPixmap)
{
...
CARD32 *IntPtr = (CARD32*)pPixmap-devPrivate.ptr;
CARD32 bits[8];
...
/* for our case i = 8*/
while(i--)
bits[i] = IntPtr[i] mask; /* where mask = 0xFF00 */
break;
...
}
intPtr[0] contains valid data in the most significant byte for BE
machines, so you
need 0xFF00 mask to get vaild data from intPtr[0] and put it to
bits[0]. So, the MSB of bits[0] contains first string bitmask of 8x8
pattern.
And I guess there is no any endianity problems here.
2. tile case
XAACheckTileReducibility(PixmapPtr pPixmap, Bool checkMono)
{
CARD32 *IntPtr;
...
if(checkMono) {
...
if(pPixmap-drawable.bitsPerPixel == 8) {
/* this is our case */
unsigned char *srcp = pPixmap-devPrivate.ptr;
...
/* i = j = 8 for our case */
for(y = 0; y i; y++) {
bits[y] = 0;
for(x = 0; x j; x++) {
if(srcp[x] != fg) {
/* return if there is more then to colors in tile */
if(bg == -1) bg = srcp[x];
else if(bg != srcp[x]) return TRUE;
} else bits[y] |= 1 x;
}
srcp += pitch;
}
...
In this case bits[0] also contains the first string of 8x8 pattern
(as I understand), but in the last significant byte (bits[0] 0x00FF).
... but maybe there is a problem in code were pPixmap-devPrivate.ptr
is filled.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Endianity problems in XFree86-4 XAA on MipsEB
On Mon, 2003-02-10 at 18:55, Alexandr Andreev wrote:
Michel Dänzer wrote:
On Fre, 2003-02-07 at 21:36, Alexandr Andreev wrote:
Bool
XAACheckStippleReducibility(PixmapPtr pPixmap)
{
...
pPriv-pattern0 = bits[0] | SHIFT_L(bits[1],8) | SHIFT_L(bits[2],16) |
SHIFT_L(bits[3],24);
pPriv-pattern1 = bits[4] | SHIFT_L(bits[5],8) | SHIFT_L(bits[6],16) |
SHIFT_L(bits[7],24);
...
}
where SHIFT_L(value, shift) is defined as ((value) (shift)) for Big
Endian.
SHIFT_L really means shift right for big endian machines!
Bool
XAACheckTileReducibility(PixmapPtr pPixmap, Bool checkMono)
{
...
pPriv-pattern0 = bits[0] | (bits[1]8) | (bits[2]16) | (bits[3]24);
pPriv-pattern1 = bits[4] | (bits[5]8) | (bits[6]16) | (bits[7]24);
...
}
Here is the true shift left.
In both cases the unsigned int bits[] array contains bytes!
No, in XAACheckStippleReducibility() it's declared as CARD32.
Yes of course, but In the first case the __most__ significant byte of
the bits[0] contains data and in the second case the __last__ significant
byte of the bits[0] contains data. So, you obtain swapped pattern0 and
pattern1 in the tile case.
I see where you're getting at, but does bits[0] really have the same
meaning in both cases?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Endianity problems in XFree86-4 XAA on MipsEB
We have a MipsEB machine and a video card which has a 2D BitBLT engine.
It looks like we found a problem in XAA when we tried to use our hardware
8x8 Mono Pattern Fills. The problem appears when an application uses
pixmaps.
Stipple and tile with the same pixmap are drawing in the different ways
(bytes in video memory are swapped). We looked through the XAA source tree
and found a dubious code in xaaPCache.c.
In two words... XAA tries to check that a pixmap (stipple/tile) can be
reduced
to a 8x8 mono pattern, and if so, puts this stipple/tile to two dwords
(patterns0,1)
and passes it to hw driver. And it looks like the stipple code works
fine, but there
is an endianity problem in the tile case... or maybe vise versa, but
in any case
patterns are maked up in different ways for BE.
Bool
XAACheckStippleReducibility(PixmapPtr pPixmap)
{
...
pPriv-pattern0 = bits[0] | SHIFT_L(bits[1],8) | SHIFT_L(bits[2],16) |
SHIFT_L(bits[3],24);
pPriv-pattern1 = bits[4] | SHIFT_L(bits[5],8) | SHIFT_L(bits[6],16) |
SHIFT_L(bits[7],24);
...
}
where SHIFT_L(value, shift) is defined as ((value) (shift)) for Big
Endian.
Bool
XAACheckTileReducibility(PixmapPtr pPixmap, Bool checkMono)
{
...
pPriv-pattern0 = bits[0] | (bits[1]8) | (bits[2]16) | (bits[3]24);
pPriv-pattern1 = bits[4] | (bits[5]8) | (bits[6]16) | (bits[7]24);
...
}
In both cases the unsigned int bits[] array contains bytes! with the
bitmask to be
passed to a driver via pPriv-pattern0, pPriv-pattern1.
When we tried to use the fbdev driver which is not using XAA, the problem
is gone.
Did anybody see something similar on Big Endian machines?
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
