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
* Copy bits from the parent into the new pixmap so that it will
* have "reasonable" contents in case for background None areas.
XID val = IncludeInferiors;
@@ -492,6 +493,7 @@ compNewPixmap (WindowPtr pWin, int x, int y, int w, int
w, h, 0, 0);
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
To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-xorg+help(a)opensuse.org