set of patches from the last 3 weeks

[eric anholt]

>From: Ginokas <ginokas@free.fr>
>To: eric anholt <ericanholt@hotmail.com>
>Subject: Re: set of patches from the last 3 weeks
>Date: Fri, 20 Feb 2004 02:11:34 +0100
>
>Hello!
>
>I am working on a trident driver for cyberblade/i1(epia) too.
>We may merge our work in one driver ?
>
>My driver is still an ugly hack on Keith Packard 's but it accels 
>solid,copy and partial blend for now.
>Yours seems pretty (But I don't understand all your implementation of blade 
>yet) and I haven't test it (yet).
>
>While working with offscreen, i saw something strange:
>kaaMoveInPixmap happens to be called with main screen pixmap and copy it to 
>offscreen :-(.
>Then nothing move on main screen anymore (hang look)!
>I just add a filter on pixmap id 0 but maybe something clever may be found.
>
>I hope you contact when you come back !
>
>Regards,
>Gilles.
>
>PS: Sorry for my bad english writing.
>PS2: I don't have a cvs access but I'll test your offscreen patch!


Good catch on the kaaMoveInPixmap thing.  I changed the !pKaaPixmap->area 
check in UseScreen to a !kaaPixmapIsOffscreen(pPixmap) check, and all my 
hangs now appear to be solved, including one I'd been seeing before when 
dragging a window in Xati without xcompmgr running.  Someone should commit 
that.

You've got acceleration on cyberblade/i1 going fine?  Great!  I'd love to 
see that merged into the driver I wrote, if you were interested in using 
that as a base.  I first started playing with trident to make a driver for 
my epia box, but got stuck because I wasn't doing all the setup that it 
needed, which the other trident driver looks like it did.  The blade code I 
included is just leftover stuff from my cyberblade attempt, so I wouldn't 
expect it to actually work yet..

Is your blend acceleration using the PrepareBlend/Blend/DoneBlend hook, or 
is it overriding the Composite function from kdrive like the other trident 
driver did?

We'll want to do quite a bit of testing before including blend hooks.  I've 
found that the r128 blend code is broken (someone should disable it), and 
haven't fixed it yet.  I'm guessing it's something to do with source 
coordinates, but I don't really have anything to go on.  It manifests as 
corruption of fonts when using subpixel rendering.  I'm going to keep 
working on new rendercheck tests to try to track it down..  I'm not sure if 
I'm actually hitting hardware acceleration with rendercheck, yet, though. 
I'll sabotage my r128 blend code today to see if I see errors when it's 
meant to be broken.  Unfortunately at this point I don't have any simple way 
to watch logs of the ATI server, since I can't enter any commands on the 
trident box directly, so debugging has been a pain.

I've got rendercheck to the point now that it tests whether the math is 
right for all of the supported composite operations with or without a mask, 
with or without component alpha, using 1x1 repeat sources.  The fb code 
appears fine as far as those operations with the exception of the saturate 
issue I sent the patch for before.  I've got a test for whether the 
destination coordinates are correct, but that's not working until I can fix 
the get_pixel to be able to fetch pixels besides (0,0).  Next will probably 
be something to check whether pixels are being chosen correctly from the 
source and mask.  I also need to check formats besides ARGB8888 IN ARGB8888 
OP RGB565, which is what I've been doing so far on my desktop.

_________________________________________________________________
Stay informed on Election 2004 and the race to Super Tuesday. 
http://special.msn.com/msn/election2004.armx