[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: Corrupted display (radeon_accelfuncs.c)
From:       Michel =?ISO-8859-1?Q?D=E4nzer?= <michel () daenzer ! net>
Date:       2004-12-27 7:32:18
Message-ID: 1104132739.5369.113.camel () thor ! asgaard ! local
[Download RAW message or body]

On Sun, 2004-12-26 at 23:11 +0100, Jerome Glisse wrote:
> I am not sure but i think there is a typo bug
> 
> in radeon_accel.c line 657 this should be
>     if (bpp == 2)
>     OUT_RING_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_16BIT);
>     else if (bpp == 4)
>     OUT_RING_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_32BIT);
>     else
>     OUT_RING_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_NONE);
>     ADVANCE_RING();
> 
> Instead of
>     if (bpp == 2)
>     OUT_RING_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_16BIT);
>     else if (bpp == 1)
>     OUT_RING_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_32BIT);
>     else
>     OUT_RING_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_NONE);
>     ADVANCE_RING();

The output of diff -u would be easier to parse...

> Or did i misunderstood bpp magic :) ?

There are several transfers to take into account:

      * CPU -> ring buffer: no change
      * ring buffer -> host data registers: converts to little endian
      * host data registers -> video RAM: no change

The idea is to swizzle the bytes in the host data registers such that
the byte order of the image data ends up being little endian in video
RAM. Either think it through or experiment. :)


> Anyway this does not fix the problem of corrupted display.

Sure, this code is only used for R[12]00 Render acceleration and XVideo
so far, hence my (still unanswered) question about whether the latter
works correctly on R300...


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

[prev in list] [next in list] [prev in thread] [next in thread]