New acceleration architecture

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Winischhofer wrote:
> Thomas Winischhofer wrote:
> 
>>>Zack Rusin wrote:
>>>
>>>>>Also I added two temporary lines of debugging output to figure out what's 
>>>>>wrong with the 24 bit pixmaps. Could you try it on the problematic card and 
>>>>>let me know what do the lines starting with "Creating a pixmap on" and 
>>>>>"allocating pixmap with pitch" say?
>>>
>>>
>>>OK, with (Support24Bpp | SupportConvert32To24 | PreferConvert32To24) set
>>>(which is normal), I get:
>>>
>>>SIS(0): Depth 24, framebuffer bpp 24
>>>
>>>and as soon as exa starts doing its stuff:
>>>
>>>Creating a pixmap on 1 display, with 1 bpp
>>>Creating a pixmap on 1 display, with 1 bpp
>>>Creating a pixmap on 24 display, with 32 bpp
>>>
>>>and then immediately a sig 11.
>>>
>>>The output of xdpyinfo.txt on this machine is attached.
>>>
>>>[Sidenote: Despite the exa problems, kde behaves really odd here on
>>>24bpp; with all acceleration disabled, icons have wrong colors, and the
>>>desktop icons are at wrong locations. Windows are drawn correctly, though.]
>>>
>>>If you need further info, please let me know.
> 
> 
> PS: If I force the bpp to 24 (thereby overruling the result from the
> BitsPerPixel(depth) macro), it does not crash. Drawing operations such
> as fill and copy work correctly, but text and other stuff is drawn at
> completely wrong positions.
> 
> Especially interesting: When I move the console window, the text in it
> is redrawn in wrong colors, too far to the left, but at the correct y
> position.
> 
> The offset to the left is obviously caused by the x coordinate being
> interpreted for 32bpp, not 24 (somthing is divided by 4 and not 3): If I
> move the console window to the left screen edge, the offset is nearly 0
> (nearly because the window border is still there, which is 4 pixels),
> and it increases when I move the window to the right. It's obvious that
> this offset is also the reason for the wrong colors.
> 
> The problem obviously also leads to some serious memory issue as my
> hardware cursor image gets overwritten constantly. This image is located
> at the top of the video RAM, which is quite at its limits. The card has
> 4MB, I am running at 1280x1024x24....
> 
> To make sure: This does not occure when acceleration is disabled or if
> XAA is used. The composite extension was disabled through all my tests.

To add further to my problem description: I think there is something odd
going on beyond the scope of acceleration: Under XFree86 4.3 (current
debian unstable version), KDE (current debian unstable) shows absolutely
NO drawing errors with XAA or with acceleration disabled. Same box, same
sis driver (apart from the fact that exa isn't compiled in, of course),
same bpp/depth=24. I only renamed my backup /usr/X11R6 back to the old
one where Debian's XFree86 is installed.

Is there something in the fb layer that is broken for 24/24...? Perhaps
something in connection with the changes required for the composite
extension (although this extension was DISABLED during all my tests)...?

Keith, I think this is becoming a little bit your call....

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net          http://www.winischhofer.net/
twini AT xfree86 DOT org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCybs9zydIRAktyUcRArCpAKCKWPfiJMxaX/j2uxI/6YTXTRtkvgCbBLo3
wjVsGOSe45lJPwUPTXv+k6w=
=eVj+
-----END PGP SIGNATURE-----