This is email regards the hw cursor garbling in mach64 based cards when
DRI is enabled.
The relevant parts of XFree86.0.log are:
(II) ATI(0): VESA VBE Total Mem: 4096 kB
...
(II) ATI(0): Storing hardware cursor image at 0xFD3FFC00.
(II) ATI(0): Using 8 MB linear aperture at 0xFD000000.
(!!) ATI(0): Virtual resolutions will be limited to 4095 kB
due to linear aperture size and/or placement of hardware cursor image
area.
(II) ATI(0): Using Block 0 MMIO aperture at 0xFC100400.
(II) ATI(0): Using Block 1 MMIO aperture at 0xFC100000.
(==) ATI(0): Write-combining range (0xfd000000,0x400000)
(II) ATI(0): MMIO write caching enabled.
(--) ATI(0): 4096 kB of SGRAM (2:1) 32-bit detected (using 4095 kB).
...
(II) ATI(0): [drm] framebuffer handle = 0xfd000000
...
(II) ATI(0): Visual configs initialized
(II) ATI(0): Block 0 base at 0xfc100400
(II) ATI(0): Memory manager initialized to (0,0) (640,1587)
(II) ATI(0): Reserved back buffer from (0,480) to (640,960)
(II) ATI(0): Reserved depth buffer from (0,960) to (640,1440)
(II) ATI(0): Reserved 2112 kb for textures at offset 0x1eff00
After some calculations we have that:
start end
textures: 0x1eff00 0x3fff00
hw cursor: 0x3ffc00 0x400000
Notice the overlap.
The relevant piece of code is from atiscreen.c:
int fbSize = pATI->VideoRAM * 1024;
> Here is the problem! It should be pScreenInfo->videoRam and not
pATI->VideoRAM. See below.
/* Try for front, back, depth, and one viewport's worth of
* pixmap cache. Should be enough for at least a fullscreen
* background image.
*/
pATIDRIServer->textureSize = fbSize - (3 * bufferSize +
ATI_DRI_XAA_LINES * widthBytes);
l = ATIMinBits((pATIDRIServer->textureSize-1) / MACH64_NR_TEX_REGIONS);
if (l < MACH64_LOG_TEX_GRANULARITY) l = MACH64_LOG_TEX_GRANULARITY;
/* Round the texture size up to the nearest whole number of
* texture regions. Again, be greedy about this, don't round
* down.
*/
pATIDRIServer->logTextureGranularity = l;
pATIDRIServer->textureSize =
(pATIDRIServer->textureSize >> l) << l;
> NOTE: Why round up if there's no memory for that? Anyway this code is
rounding down and not up...
total = fbSize - pATIDRIServer->textureSize;
scanlines = total / widthBytes;
if (scanlines > ATIMach64MaxY) scanlines = ATIMach64MaxY;
/* Recalculate the texture offset and size to accomodate any
* rounding to a whole number of scanlines.
* FIXME: Is this actually needed?
*/
pATIDRIServer->textureOffset = scanlines * widthBytes;
pATIDRIServer->textureSize = fbSize - pATIDRIServer->textureOffset;
...
else
#endif /* XF86DRI */
{
ScreenArea.x1 = ScreenArea.y1 = 0;
ScreenArea.x2 = pATI->displayWidth;
ScreenArea.y2 = pScreenInfo->videoRam * 1024 * 8 / pATI->displayWidth /
> The non-DRI code ^^^^^^^^^^^^^^^^^^^^^
pATI->bitsPerPixel;
if ((unsigned)ScreenArea.y2 > ATIMach64MaxY)
ScreenArea.y2 = ATIMach64MaxY;
xf86InitFBManager(pScreen, &ScreenArea);
}
And from atipreinit.c we have:
if (ServerVideoRAM < pATI->VideoRAM)
{
pScreenInfo->videoRam = ServerVideoRAM;
> ^^^^^^^^^^^^^^^^^^^^^
xf86DrvMsg(pScreenInfo->scrnIndex, X_NOTICE,
"Virtual resolutions will be limited to %d kB\n
due to"
" linear aperture size and/or placement of
hardware"
" cursor image area.\n",
ServerVideoRAM);
}
So the fix is rather simple. My question is why having different
variables with apparent same meaning and with different values?
In xf86str.h says:
/* Some of these may be moved out of here into the driver private
area */
...
int videoRam; /* amount of video ram (kb) */
Regards,
Jose Fonseca
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
