Re: Endianity problems in XFree86-4.2 XAA on MIPSEB

Re: Endianity problems in XFree86-4.2 XAA on MIPSEB

[Geert Uytterhoeven]

On Fri, 7 Feb 2003, Alexandr Andreev wrote:
> 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.

> Did anybody see something similar on Mips EB with XFree + XAA?

Have you asked this on xfree86-devel? Some PPC people may be able to help you.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Endianity problems in XFree86-4.2 XAA on MIPSEB

[Guido Guenther]

On Fri, Feb 07, 2003 at 05:28:38PM +0000, Alexandr Andreev wrote:
> We have a MipsEB machine and a video card which has a 2D BitBLT engine.
It would help a lot if you'd tell us what card you're using. Some of the
drivers are more endian clean then others.
> 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.
Did you have a look at the XAA.HOWTO at:
 xc/programs/Xserver/hw/xfree86/xaa
especially the
  BIT_ORDER_IN_BYTE_MSBFIRST
  BIT_ORDER_IN_BYTE_LSBFIRST
flags?
 --Guido

Endianity problems in XFree86-4.2 XAA on MIPSEB

[Alexandr Andreev]

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 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:

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 Mips EB with XFree + XAA?

Re: Endianity problems in XFree86-4.2 XAA on MIPSEB

[Alexandr Andreev]

Guido Guenther wrote:
> On Fri, Feb 07, 2003 at 05:28:38PM +0000, Alexandr Andreev wrote:
> 
>>We have a MipsEB machine and a video card which has a 2D BitBLT engine.
> 
> It would help a lot if you'd tell us what card you're using. Some of the
> drivers are more endian clean then others.

We have got our own card and our own driver, but it looks like this problem
is driver independant, because patterns are maked up in different ways 
for BE.


> Did you have a look at the XAA.HOWTO at:
>  xc/programs/Xserver/hw/xfree86/xaa
> especially the
>   BIT_ORDER_IN_BYTE_MSBFIRST
>   BIT_ORDER_IN_BYTE_LSBFIRST
> flags?
>  --Guido

Yes, but these flags specify bit ordering, not byte. And these flags 
work fine for
MipsEB.