Since 2.6.37-rc1, I see graphical glitches on various UI widgets. This can show as any of the following:
- a black rectangle around the URL bar in Firefox
- slightly glitchy scrollbars in various programs (most noticeably Konsole)
- a lot of graphical corruption occasionally covers the document list and toolbar in Kate
None of these effects are always there. They come and go. Overall, KDE applications seem to be more affected, and the problem is only severe with Compiz running. Without Compiz, the glitches are rarer and less obvious. Stability seems unaffected by the glitches, and 3D works without problems or glitches.
This problem doesn't exist with 2.6.36.
Observed on both Ubuntu Maverick and Ubuntu Natty (with xf86-video-intel 2.13.0-1ubuntu1) with a 2.6.37-rc1 kernel. On Natty, I verified that this bug is still present on a mainline kernel with the 2010-11-19 drm-intel-fixes merge.
System info provided by apport is available in the downstream bug I filed.
You probably forgot to post the link to the mentioned bugreport.
This is likely fixed by
Author: Daniel Vetter <firstname.lastname@example.org>
Date: Sat Nov 27 22:30:41 2010 +0100
drm/i915: fix regression due to ba3d8d749b01548b9
We don't track gpu flush request in any special way. So even with
obj->write_domain == 0, a gpu flush might be outstanding but no
yet executed. Even worse, the latest request might use the object
only for reading. So and unconditional call to object_wait_rendering
is needed for !pipelined.
Hence revert that patch fully and untangle the flushing from the
Reported-by: Keith Packard <email@example.com>
Tested-by: Keith Packard <firstname.lastname@example.org>
Signed-off-by: Daniel Vetter <email@example.com>
Signed-off-by: Chris Wilson <firstname.lastname@example.org>
which is working its way upstream, and is currently available from drm-intel-fixes.
Running a kernel with that, it looks good so far. I'll correct myself if I see a glitch pop up.
The downstream report is here, BTW:
I have it in the URL field of this bug report, but I guess it isn't very obvious there.
Ah, indeed you have. I overlooked it.
Chris, I just wanted to add a link to the patch, but I don't seem to find it on intel-gfx or dri-devel. (I did look only superficial for the subject line and mails from Daniel.)
Where do patches usually get posted?
Usually intel-gfx@. This particular regression was raised and debugged on irc and no patch made its way to the list. Hmm, I think I will try and enforce a cooling off period such that all patches must first be staged and to email all patches pushed to -staging to the list for review.
I don't know what's the recommended workflow, but for tracking purposes a link to a mailinglist posted patch is more helpful then a link to a git repository. With a mailinglist posted patch, issues have a chance of being reported in that same thread and are then automatically visible from the bugreport. Whereas for patches where google does not find a post, you have very few ways to find issues or discussion about it,...
*** Bug 22542 has been marked as a duplicate of this bug. ***
Fixed by commit de18a29 drm/i915: fix regression due to ba3d8d749b01548b9 .