Corrupted display (radeon_accelfuncs.c)

[Jerome Glisse]

Vladimir Dergachev wrote:

>
>
> On Sun, 26 Dec 2004, Jerome Glisse wrote:
>
>> Vladimir Dergachev wrote:
>>
>>>
>>> Hi Jerome,
>>>
>>>   Keith has reported that specifying Option 
>>> "XaaNoScanlineImageWriteRect"
>>> stops the artifacts - does this work for you ? In any depth ?
>>>
>> Yes browsing the archive i saw that option, this correct the problem 
>> for almost all
>> application, in fact only xemacs still got corrupted font.
>>
>> Anyway we shouldn't have to enable this option to prevent from a 
>> corrupted display,
>> there is a bug somewhere no ? In xaa ?
>
>
> What this option does is tell us which function is the likely culprit.
> Take a look at radeon_accelfuncs.c in
>
>      xc/programs/Xserver/hw/xfree86/drivers/ati
>
> Try to experiment with function RADEONSetupForScanlineImageWrite - 
> there is a section inside that depends on endiannes.
>
> Since the problem manifests only with DRM driver the issues must be in 
> the
> ACCEL_CP section.
>
> For example try replacing
> ------------------------------------------------------------
>     if (bpp == 16)
>     OUT_ACCEL_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_HDW);
>     else
>     OUT_ACCEL_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_NONE);
> ------------------------------------------------------------
> with the following code from MMIO section:
> ------------------------------------------------------------
>     if (bpp == 16)
>     OUT_ACCEL_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_16BIT);
>     else if (bpp == 32)
>     OUT_ACCEL_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_32BIT);
>     else
>     OUT_ACCEL_REG(RADEON_RBBM_GUICNTL,   RADEON_HOST_DATA_SWAP_NONE);
> -------------------------------------------------------------
> If this does not help, simply experiment providing different endianness
> settings. Perhaps one of them will work.
>
hhhmm

I experimented a bit but the problem is still around i am wondering
if the problem did not came from the planemask provided to

    RADEONSetupForScanlineImageWrite

Or the problem is in
    RADEONSubsequentScanlineImageWriteRect

This code (radon_accelfuncs.c) is an Xorg file or it came from DRI ?

I could only test on r300 maybe r200 on ppc did not have this bug.
Anyone can test ?

Maybe we should add a bug to Xorg bugzilla for that.

If anybody get idea on this.

best,
Jerome Glisse