Henne Vogelsang writes:

Dominik Grafenhofer wrote:

...

...

We cannot and will not support the fglrx driver from the SuSE side (lack of manpower, lack of interest by ATI, you name it). That said, having a repo with adapted packages is certainly interesting to users.

I will keep the packages updated on my buildserver project, but could the packages be put in some other "semi-official" repository? E.g. somewhere under /repositories/X11:/

Why don't we fix the patch? Egbert can you do this?

The patch itself is dangerous and not valid: @@ -478,6 +478,7 @@ compNewPixmap (WindowPtr pWin, int x, int y, int w, int h) * Copy bits from the parent into the new pixmap so that it will * have "reasonable" contents in case for background None areas. */ +#if 0 if (pGC) { XID val = IncludeInferiors; @@ -492,6 +493,7 @@ compNewPixmap (WindowPtr pWin, int x, int y, int w, int h) w, h, 0, 0); FreeScratchGC (pGC); } +#endif } else { What comes before this is: GCPtr pGC = GetScratchGC (pWin->drawable.depth, pScreen); Thus FreeScratchGC (pGC) needs to be called in any case. Not doing this may result in a mem leak :( The idea of the original code is to fill the background of windows with their parent's background in case a window has no background defined itself. This is a reasonable but slightly expensive approach for redirected windows (it requires copying as those windows don't reside on top of each other). Leaving the background empty will most likely leave 'junk' that had been in the memory buffer before as window background. Most of the time this will show as annoying random garbage, however in some (rare) cases may be a meaningful image possibly with some content the user didn't expect ever to see again in the screen. As such it could be a security issue. However since according to the X Protocol the background content of bg == None is undefined we could also fill it with a solid color - an operation which might actually be faster (but may create an annoying black flicker). I've now made a patch to address this issue which still needs to be tested, but thinking about it some more I'm really reluctant to include this: The 1:1 copy operation that takes place here should not create a high burdeon if acceleration is good. I'd have to do a few tests to see why this operation slows down the Xserver that much. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-xorg+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-xorg+help@opensuse.org