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(a)opensuse.org
For additional commands, e-mail: opensuse-xorg+help(a)opensuse.org
Hello,
can any tell me the procedure to start Xorg / KDE4.3 on a 11.1 with the new
xorg packets from repository ?
Xorg is starting (manual) but no KDE4
have I to change any config or install a extra packet ?
--
mit freundlichen Grüßen / best Regards,
Günther J. Niederwimmer
--
To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-xorg+help(a)opensuse.org
Hi List,
since a upgrade two days ago, I have a problem with the radeon drivers from
the X11:XOrg repositories on openSUSE 11.1 (32bit). Everytime I start KDE from
KDM when DRI/desktop effects are enabled, X crashes after some seconds. If I
set DRI to off in Xorg.conf the server works (but of course unusable slow with
EXA and not much better with XAA). This only happens since one of the last
upgrades (I suspect the new Mesa somehow but are not really sure). Before the
driver was working "like a charm" for the last couple of months with
radeon+DRI+EXA+desktop effects. To be sure, I tested it with the radeonhd
driver to, but this lead - like expected - to the same result.
Checking Xorg.0.log doesn't seem to result in anything useful as well as the
other usual places. But interestingly /var/log/kdm.log seems to tell me
something that could be helpful. When the server is crashing, it ends with:
*********************************WARN_ONCE*********************************
File radeon_dma.c function radeonReleaseDmaRegions line 348
Leaking dma buffer object!
***************************************************************************
Xorg: radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy-
>is_pending <= bo->cref' failed.
I don't really know what it means but it seams like some assertion is failing
;-)Hope that helps you somehow.
Kind regards,
Steffen Schloenvoigt
--
To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-xorg+help(a)opensuse.org
Henne Vogelsang writes:
> Hi,
>
> Dominik Grafenhofer wrote:
> >> Why don't we fix the patch? Egbert can you do this?
> > The problem is that afaik even core xorg developers, fglrx and
> > compiz/kde4 developers cannot agree on how to fix it.
>
> Matthias said that if we contain the code-path in a check for the
> drivername it might be acceptable for our xorg. Thats what i think is
> the better idea.
>
No, this is not acceptable. We don't fix driver issues in the server.
The point is that this code gets called way too often. Every time a
window is resized it's called. Even if the Window background is not
None as this could be changed later by the client.
Once could try to use the background color if background is set to
Solid making the assumption the background color has been set
correctly. But i doubt that this will bring much as I believe that
most apps today don't bother about the background as they display
the entire window content as an image anyway.
Still it gets me why doing a simple in framebuffer copy using the GPU
slows things down so much.
Cheers,
Egbert.
--
To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-xorg+help(a)opensuse.org
Hi,
Dominik Grafenhofer wrote:
>> Why don't we fix the patch? Egbert can you do this?
> The problem is that afaik even core xorg developers, fglrx and
> compiz/kde4 developers cannot agree on how to fix it.
Matthias said that if we contain the code-path in a check for the
drivername it might be acceptable for our xorg. Thats what i think is
the better idea.
Henne
--
Henne Vogelsang, openSUSE.
Everybody has a plan, until they get hit.
- Mike Tyson
--
To unsubscribe, e-mail: opensuse-xorg+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-xorg+help(a)opensuse.org