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
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
to a 8x8 mono pattern, and if so, puts this stipple/tile to two dwords and
passes it to hw driver. And it looks like the stipple code works fine,
is an endianity problem in the "tile" case:
pPriv->pattern0 = bits | SHIFT_L(bits,8) | SHIFT_L(bits,16) |
pPriv->pattern1 = bits | SHIFT_L(bits,8) | SHIFT_L(bits,16) |
where SHIFT_L(value, shift) is defined as ((value) >> (shift)) for Big
XAACheckTileReducibility(PixmapPtr pPixmap, Bool checkMono)
pPriv->pattern0 = bits | (bits<<8) | (bits<<16) | (bits<<24);
pPriv->pattern1 = bits | (bits<<8) | (bits<<16) | (bits<<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
Did anybody see something similar on Mips EB with XFree + XAA?