Matrox g400 patch for hw blends / compositions

[Damien Ciabrini]

Hi Jaymz,

On Friday 30 April 2004 09:17, Jaymz Julian wrote:
> Hi.  I updated my system to 2.6, and the mga driver stopped crashing, and
> so I tried your patch.  Unfortunatnly, I couldn't get it to function
> correctly in any state.
>
> All of these tests are on a g400max, and probably may or may not be your
> fault.
They are probably mistakes of mine, indeed :)

> In 32bpp mode, the screen gets horrifically corrupted when you start the
> composite manager.  I suppose this is expected by your 16bpp comment
> belone, but it would nice if it worked in that mode :).
The original driver never worked properly for me anyway. So i decided to focus 
on the 16bpp which seemed to be OK, apart from the solid fill acceleration 
problems which I believe I've corrected in my patch.
We should ask to the original driver maintainer if those problem arose for him 
too.

> In 16bpp mode, things somewhat work, at least a pure xterm does.  Starting
> KDE exposed a whole pile of problems tho, specifically relating to colour
> corruption 
huhu.... Well I admit I didn't test my patch with KDE :-/ . I tested with 
fvwm2 and xterm with Xft rendered fonts (started with 'xterm -fa'). 
I experienced no problem in this configuration.
However, I tested my patch within the gnome desktop, and there were bugs with 
the rendering of icons. I've been unable to understand the problem, as it 
seems to occur even with the original mga driver.
Interistingly enough, I doubt it is a hardware related problem, because if one 
bypasses every mga accels (the prepareXXX funcs in the drivers), the bug 
still occurs...
Again, we should ask other driver developpers on this ML to see if someone 
have a clue about the origin of the bug (anyone out there ??)

> (my black menu items and konsole turned flouresent green. for 
> example. interesting, white text on black works fine, but black text on
> white came out in various shades of green).
This problem might comes for the blending operation used inside 
mgaComposite(). I've tested the composition for the classic "Over" blending 
func (SRC_ALPHA | DST_ONE_MINUS_SRC_ALPHA), but other blending funcs might be 
incorrect.

> transparent windows did seem to work well, except for the aforementioned
> turning some colours green, but that was expected from the above :).
I strongly suspect this is the same problem...

> fdclock in RGBA mode came out as a horrific corrupted mess, did it work for
> you?
The one shown in Keith's screenshots ? No, I didn't know the code was 
available... I'm going to install it and try this ASAP

Best regards,

--
Damien