Commit e9aa61e9f0d663d5b34a397b943b4d1df44e873d added code to copy the contents of source windows into temporary scratch pixmaps before performing software compositing, in case that rendering reads outside the bounds of the source window's backing storage. However, it's not safe to call the top-level CreatePixmap and corresponding rendering routines from inside an fb fallback because the driver doesn't get the appropriate opportunity to sync the GPU or set up the appropriate software access. There's a Fedora patch to resolve that particular issue by replacing the accelerated calls with their software equivalents:
However, that patch causes a severe performance regression on KDE because kwin maps a 1x1 InputOutput at (0,0). The backfill code does a 1x1 composite from the root window to fill that window's backing pixmap, but copy_drawable doesn't check the sizes at all and reads the entire 1600x1200 root window back to malloc memory in software.
libfb should not bother with the copy if the source window is entirely contained within its bounding pixmap. It should probably also determine exactly which pixels it needs to read back, but that can be a separate optimization.
For those watching the bug but not the mailing list, I sent out a hotfix for this: http://lists.x.org/archives/xorg-devel/2009-November/003571.html
It has yet to be pulled into git.
A reporter from one of the Fedora bugs on this topic suggests that the patch may cause a regression in a different area (much less serious, but still):
"After testing the build from comment 12 further it appears that it introduces
graphical corruption of the mouse pointer in some circumstances, the mouse
pointer turns into a random looking (32x32?) square on one monitor. This
problem only seems to occur on one monitor at a time, ie when the problem is
present sometimes the pointer is fine on the left monitor but corrupt on the
right, other times the situation is reversed, I've never seen the pointer
corrupted on both monitors at any one time.
I've rolled back to the build excluding the window-pictures patch to try to
confirm that the problem is actually introduced by the new build."
false alarm: "The mouse pointer corruption eventually showed up with the old build, so I don't think it's related to this bug."
The commit in question was reverted out of server-1.7-branch, but debate is still ongoing as to what the right fix is for master. Reassigning to Soeren.
This "fix" in the server-1.7 branch causes crashes as soon as I login to GNOME. The crash is reported in the archlinux bugtracker by someone using xf86-video-ati, I have exactly the same crash with xf86-video-intel:
When I login to GNOME, I see the gdm background wallpaper fading into a grey color, after which X crashes or locks up. I think GNOME does some xrandr magic as I'm running dual screen.
Reverting the reverted commit makes it work again, though I applied the fedora patch and suggested band-aid to make it work for everyone.
I posted a patch for review that should fix this bug, but haven't heard anything back about it.
This avoids all copying while also ensuring that access from pixman never steps outside the bounds of the pixmap
I am going to comment on it, probably tomorrow.
(In reply to comment #7)
> I am going to comment on it, probably tomorrow.
Half year later - patches seems to be in xserver master, but bug still here? How it manifest itself, visually? I have strange corruption with fbdev and xserver master, my bug show itself on unaccelerated operations, it seems (fallbacks, pure software rendering)
i'll open another bug report if this bug is not about corruption like you see on above screenshot, in any case sorry for noise.
(In reply to comment #8)
> (In reply to comment #7)
> > I am going to comment on it, probably tomorrow.
> Half year later - patches seems to be in xserver master, but bug still here?
> How it manifest itself, visually? I have strange corruption with fbdev and
> xserver master, my bug show itself on unaccelerated operations, it seems
> (fallbacks, pure software rendering)
> i'll open another bug report if this bug is not about corruption like you see
> on above screenshot, in any case sorry for noise.
It seems to be separate problem, introduced much more recently.
Fedora and Arch bugs seems to be closed as FIXED, not sure what to do with this bug ..... Ping?
on Sep 29, 2016 at 15:22:50.
(provided by the Example extension).