Created attachment 55582 [details]
xorg log

The Debian bug report also contains some more information like udev devices…

Created attachment 55583 [details]
this is a screenshot showing the issue

Without compositing its mostly okay. But I get a black area instead of the background image from time to time. The black areas while typing something into input fields or switching windows are only occuring when I have compositing enabled.

So for now as a work-around I have it disabled.

If I recognize the symptoms correctly, this should be fixed with

commit 983b755313df8a0d256c59c32ec4106e35f237aa
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jan 12 21:05:16 2012 +0000

    sna/damage: Fix union of extents with dirty damage but no region
    
    By failing to account for certain paths which would create a damage elt
    without fully initialisating the damage region (only the damage extents),
    we would later overwrite the damage extents with only the extents for
    this operation (rather than the union of this operation with the current
    damage). This fixes a regression from 098592ca5d,
    (sna: Remove the independent tracking of elts from boxes).
    
    Include the associated damage migration debugging code of the callers.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks. I asked the maintainer of the Debian package to provide an updated package to test with. I will report back.

Hmmm,

merkaba:~> zcat /usr/share/doc/xserver-xorg-video-intel/changelog.Debian.gz | head -4
xserver-xorg-video-intel (2:2.17.0+git20120115-1) experimental; urgency=low

  * New upstream snapshot:
    - Merge from upstream master up to 5df7147b09.

doesn´t completely fix the issue, although it contains

merkaba:~> zgrep 983b755313df8a0d256c59c32ec4106e35f237aa /usr/share/doc/xserver-xorg-video-intel/changelog.gz
commit 983b755313df8a0d256c59c32ec4106e35f237aa


The refresh issues and the flickering still happen. I have the impression a bit more rarely than before, but I have no hard facts about it.

Thanks,
Martin

Can you give a more complete description of the "refresh and flickering"? By itself, that suggests to me an output related problem where the entire display is not sync'ed correctly. But since this is a KDE bug, I suspect you mean a graphics glitch whereby small details change appearance as they are re-rendered (with the same intent, i.e. nothing should have changed as it was rerendered). Such details as the '>' continuation marker, or scrollbar buttons. That I have seen and is usually a sign of poor coherency (i.e. missing flush and/or invalidates) in the command stream.

Indeed if I set #define DEBUG_FLUSH_CACHES 1 then the problem I see with glitchy '>' seems to go away.

commit 8b2bb666662305ab88aad8198ad69b1c98407d75
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jan 16 13:35:05 2012 +0000

    sna/gen6: Restore the non-pipelined op after every WM binding table update
    
    The hw wants it as demonstrated by the '>' in KDE's menus. Why is it
    always KDE that demonstrates coherency problems...
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

fixes the glitch in menus for me. The code used to do that precisely that reason, I just forgot the reason, removed the forced flush and thought everything was still fine. Do you want to poke Cyril for a new package and try again? :)

I dared to poke Cyril again - but offered to do it myself with some instructions as well.

In the meanwhile I think that the first patch did fix some refresh issues and that there are more than one bug.

I mentioned that black areas appear while typing into the Subject input field in the mail composer window of KMail. That appears to be gone with the first patch. At least I didn´t see it anymore.

But then I mentioned also that black areas appear on switching between windows. This is still there. But not always. Sometimes big areas on the screen just flicker shortly, as far as I noticed, they are painted black as well, but restored to their original contents very quickly, so that I barely notice it as flickering. But sometimes the black areas remain for a longer time until they eventually get refreshed by the original graphics content.

Does that help? Feel free to ask me specific questions.

Okay, and what is also not gone is black areas when I click on folders in the folder list in KMail. What appears to me as well is that once I clicked often enough in a specific area, it doesn´t happen that easily.

Appears to me that KDE is quite a good testbed for Intel SNA ;)

Pretend that I am someone who just installed Kmail for the first time. Actually don't pretend...

Can you give me, someone who only looks at KDE through xtrace and driver debugging, a step-by-step guide to reproducing some of the remaining issues? I haven't seen a major glitch, certainly nothing like what you have described, and so I am searching for a needle in a large haystack.

If you do grab the source tree and install your own driver, you can assist me immensely by compiling with --enable-debug and seeing if that takes down the Xserver with a host of assertions. (The next step after that is --enable-debug=full and hope the error is obvious enough to stand out.) [Being able to reproduce the problem locally is the fastest way to get it resolved...]

First off, by accident noticed that most if not all of the glitches go away when I enable VSync in Systemsettings/Desktop effects. It was not enabled on my system and I thought why not enable it.

Now I try some reproduce howtos when VSync is off:

- Open KMail
- Create an account with some mail folders in there
  - Easiest would be some existing IMAP account with some folders
  - (I use POP3, but that should not matter)
- Click around on different folders


- Have KMail open
- Use some other applications like Konqueror webbrowser
- Click on a folder in KMail


- Switch between desktops or activities or windows
- That activities switching thing might be good
- Hmmm... or maybe something easier:

- You should have a panel with the K menu button, a window bar, the systray and stuff like this
- On one side I bet usually on the right there should be the Plasma sign to get to the bar to resize the panel, add new applets and such
- When I click on this I had refresh issues several times as well now
- But then now it doesn´t happen always as well
- Sometimes the whole screen will be black for a fraction of a second
- And then a black area
- Well okay, this seems to trigger it quite well
- My panel is on the top if that might matter.


Thing is: It doesn´t happen all the times, only sometimes. Most likely it seems to occur when I do something different and then go back, i.e. when I use something that had no need for refresh for a longer time. But even then it doesn´t happen all the times. Still when I click onto something repeatly refresh issues do seem to go away.

Maybe its easier when I first try the most recent driver. Maybe the issues are already fixed.

Again tested with VSync enabled. I am not able to trigger anything noticable with VSync enabled. I will leave it like this for now to check whether VSync really let these issues vanish.

Hmmm, I have something that for a short time shows a flickering even with VSync enabled.

- Alt-F2
- http://blogs.kde.org/node/4515
- Konqueror should open with the blog page
- Right-click on the link "presentation semantics"
- Prior to the context menu initially appearing the whole HTML rendering pane is black for a short time
- It happens only on the first time after having opened the browser window.

But also this does not happen *always*. Happens with context menus on other web pages as well. Sometimes.

In any case with VSync enabled I did not see a black area remain. I just have the short flickering on rare times.

Well I come to the conclusion that these all really might be fixed meanwhile when you weren´t able to reproduce any glitches so far. Only thing you might look is whether you have "VSync" enabled. If so disable it for testing.

I will now just look to test the newest driver release.

Building a new package worked marvellously thanks to Cyril´s instructions.

I will now be testing this bug against:

commit 850495f956c811b1eb617d2e704e6bb7b5a86369
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jan 17 22:51:29 2012 +0000

    sna: Fix increment of damage boxes after updating for rectangles

which seems to be another fix for refresh issues and at least from the descriptions looks like something I might have seen.

Should some issues remain I can always build a new package, its easy enough.

I will test with VSync disabled cause with VSync enabled I really get no major issues.

I still get issues with this one. Again it seems that some issues are gone. 
In general it seems better, less issues than before.

But I also get one I didn´t see in this way before:

- When I have mutiple Windows open, say KMail, Iceweasel, Konqueror and drag one of them with solid window moving (moving windows with their contents as it is default in KDE) I get this flickering between gfx content is shown and black every few centimeters.

So next stept would be to build this package with enable debug? I need to find out how to do it. Ah it seems I can change this in debian/rules:

  7 # Enable SNA, pass builderstring:
  8 override_dh_auto_configure:
  9 »·······dh_auto_configure -- --enable-sna --with-builderstring="$(SOURCE_NAME) $(SOURCE_VERSION) ($(BUILDER))"

Line 9 looks as if it would take an --enable-debug switch ;).

Debug output would then be going into Xorg.0.log?

(In reply to comment #15)
> I still get issues with this one. Again it seems that some issues are gone. 
> In general it seems better, less issues than before.
> 
> But I also get one I didn´t see in this way before:
> 
> - When I have mutiple Windows open, say KMail, Iceweasel, Konqueror and drag
> one of them with solid window moving (moving windows with their contents as it
> is default in KDE) I get this flickering between gfx content is shown and black
> every few centimeters.
> 
> So next stept would be to build this package with enable debug? I need to find
> out how to do it. Ah it seems I can change this in debian/rules:
> 
>   7 # Enable SNA, pass builderstring:
>   8 override_dh_auto_configure:
>   9 »·······dh_auto_configure -- --enable-sna
> --with-builderstring="$(SOURCE_NAME) $(SOURCE_VERSION) ($(BUILDER))"
> 
> Line 9 looks as if it would take an --enable-debug switch ;).
> 
> Debug output would then be going into Xorg.0.log?

--enable-debug by itself adds lots of assertions to the code without any spamming of the log. If you do hit an assertion X will die and the assert will only apear in the gdm.log (since that captures stderr).

--enable-debug=full spams the log file and slows down your system, it shows pretty much everything that is happening within the DDX so finding the actual mistake is slim, but I usually spot enough things to worry about when reading the debug logs...

Hmmm, thats an issue then. I use this laptop as my main laptop and do not want to afford to crash it every now and then. Especially as I want to preserve probably unsafed work which a crashing X server would take with it.

No worries, if you can keep me informed of ways to reproduce your symptoms, I'll eventually strike lucky. Thanks.

Where you able to reproduce some of the mentioned glitches by what I described you so far? Thanks, Martin

Not so far. I tried enabling GL desktop effects, kwin crashed and now desktop effects seems to be permanently disabled. With the desktop effects disabled, the only glitch I've found so far is that the gradient background of the settings window occasionally has an incorrect stride. I've now tied that machine up with other tasks, but I'll try and do a valgrind pass with kde4 later. Do you, by any chance, know how to launch a KDE4 session manually?

Strange - this works nicely with KDE SC 4.7.4 on Debian Sid, what KDE version do you have? As for manually starting KDE, it should be startx and then startkde, thats a shell script which loads the other parts of the desktop and configures some stuff.

Can you try with manually replacing the start of your ~/.kde/share/config/kwinrc by:

[Compositing]
AnimationSpeed=3
Backend=OpenGL
DisableChecks=false
Enabled=true
GLDirect=true
GLLegacy=false
GLMode=TFP
GLTextureFilter=2
GLVSync=false
HiddenPreviews=5
OpenGLIsUnsafe=false
UnredirectFullscreen=true
XRenderSmoothScale=false

Note, that VSync is disabled here already. With disabled VSync I get the glitches, with enabled VSync there not. Also disabling compositing does do away with the glitches. So it needs to be compositing with disabled refresh.

In case that still doesn´t give you a composited desktop please try with:

DisableChecks=true

Although I thought that wouldn´t be necessary anymore. It disabled sanity checks by KWin - at least earlier versions of KWin disabled compositing when they thought it was to slow.

But it works out of the box for me.

In case you want to use my other effects related settings replace these configuration groups:

[Effect-BoxSwitch]
TabBox=false
TabBoxAlternative=false

[Effect-CoverSwitch]
TabBox=false
TabBoxAlternative=false

[Effect-FlipSwitch]
TabBox=false
TabBoxAlternative=false

[Effect-Magnifier]
Height=200
Width=200

[Effect-PresentWindows]
TabBox=true
TabBoxAlternative=false

[Plugins]
kwin4_effect_blurEnabled=true
kwin4_effect_boxswitchEnabled=false
kwin4_effect_coverswitchEnabled=false
kwin4_effect_cubeEnabled=true
kwin4_effect_cubeslideEnabled=false
kwin4_effect_dashboardEnabled=true
kwin4_effect_desktopgridEnabled=true
kwin4_effect_dialogparentEnabled=true
kwin4_effect_diminactiveEnabled=false
kwin4_effect_dimscreenEnabled=false
kwin4_effect_explosionEnabled=false
kwin4_effect_fadeEnabled=true
kwin4_effect_fadedesktopEnabled=false
kwin4_effect_fallapartEnabled=false
kwin4_effect_flipswitchEnabled=false
kwin4_effect_glideEnabled=false
kwin4_effect_highlightwindowEnabled=true
kwin4_effect_invertEnabled=false
kwin4_effect_loginEnabled=true
kwin4_effect_logoutEnabled=true
kwin4_effect_lookingglassEnabled=false
kwin4_effect_magiclampEnabled=true
kwin4_effect_magnifierEnabled=true
kwin4_effect_minimizeanimationEnabled=false
kwin4_effect_mousemarkEnabled=true
kwin4_effect_outlineEnabled=true
kwin4_effect_presentwindowsEnabled=true
kwin4_effect_resizeEnabled=false
kwin4_effect_scaleinEnabled=true
kwin4_effect_screenshotEnabled=true
kwin4_effect_sheetEnabled=true
kwin4_effect_showfpsEnabled=false
kwin4_effect_showpaintEnabled=false
kwin4_effect_slideEnabled=true
kwin4_effect_slidebackEnabled=false
kwin4_effect_slidingpopupsEnabled=true
kwin4_effect_snaphelperEnabled=false
kwin4_effect_startupfeedbackEnabled=true
kwin4_effect_taskbarthumbnailEnabled=true
kwin4_effect_thumbnailasideEnabled=false
kwin4_effect_trackmouseEnabled=true
kwin4_effect_translucencyEnabled=true
kwin4_effect_windowgeometryEnabled=false
kwin4_effect_wobblywindowsEnabled=true

PS: When KDE crashes on startup, maybe ~/.xsession-errors has some hints about why it did.

Thanks, I was able to get kwin GL compositing again by disabling the blur effect. And I found the cause of my graphics glitch, so I guess we're back in business of trying to reproduce your bugs...

More damage tracking bugs:

commit 35f81005f91d294e61bb4ced7cbddd1a76ccb324
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jan 19 00:41:08 2012 +0000

    sna/damage: Always mark the damage as dirty when recording new boxes
    
    A few of the create_elts() routines missed marking the damage as dirty
    so that if only part of the emebbed box was used (i.e. the damage
    contained less than 8 rectangles that needed to included in the damage
    region) then those were being ignored during migration and testing.
    
    Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=44682
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I've not seen the flashes of black, though I have yet to try your kwinrc verbatim.

I compiled

commit 8a91c7d85740a5adc25d2a9b1972c367780ce714
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Jan 21 01:18:17 2012 +0000

    sna: Give kgem_create_buffer_2d a unique id
    
and was able to reproduce black rectangles within a few minutes. Again only when VSync was *disabled* - and compositing enabled. I now just enable VSync which makes it working.

Thanks,
Martin

Just to clarify, are these black rectangles of the persistent kind or flashes of black before the area is redrawn?

Well none of both. Persistent it appears. Now they are easily reproducable by switching activities. I have an extra activity switcher panel that slides out from the top of the screen when I move the mouse pointer there.

Now when I switch activities black areas, usually just one, sometimes more than one appear. But as far as I can see from a short testing they only appear on the desktop, i.e. within the background image or applets on the desktop. I do not see them appear *within* windows.

They stay. Until I leave the activity switcher bar so that it disappears again. Then the black areas on the desktop get refreshed.

All of this does not appear when VSync is enabled. Which I will now enable again ;).

But this appears to be the only glitch left. That flickering while moving windows appears to be gone. Also the black areas while typing into the subject input field in KMail have gone before.

They only thing I see now it refresh issues with the desktop itself, not windows.

Forget my initial "none of those". They are persistent until I leave the activity switcher bar. It took a while for me to find that out and first thought something different.

Forget my obversation that its only the desktop. On pressing download new mail in KMail part of KMail´s window was overriden by a black rectangle. And then I had the issue the screenshot shows as well again. They were refreshed too, but only after some activity on my side.

Sometimes I have the flickering as well, then the refresh happens very soon after the black area appear.

It still appears there are mutiple refresh issues.

I bet it would be really good if you could reproduce this - would spare quite some roundtrips.

I now also have debian kernel that is based of 3.2.1 vanilla, instead of 3.2-rc7.

PS: Would it be possible to have the assert debug mode without asserting, i.e. without crashing the X server? I.e. something that doesn´t give a ton of logs, but might still be useful to catch these refresh issues while the server is still running safely?

(In reply to comment #30)
> PS: Would it be possible to have the assert debug mode without asserting, i.e.
> without crashing the X server? I.e. something that doesn´t give a ton of logs,
> but might still be useful to catch these refresh issues while the server is
> still running safely?

Yes, I was being lazy and using assert to catch mildly annoying bugs as well as "I am about to crash, assert instead so I know why it crashed." I could add more warnings and fixup for preventable issues or I could just fix the code...


Did I ever ask you to confirm that this only happens with Desktop Effects enabled, that is whilst using kwin as a compositing manager?

You didn´t ask, but I said so several times. I only have these effects when the following circumstances are met:

- Enabled compositing via Open GL aka desktop effects
- Disabled VSync

Whether that would happen only with kwin or other compositing managers as well I do not know. I only have kwin installed.

After some self-compiled versions I upgraded to last debian experimental snapshot of xserver-xorg-video-intel, 2:2.17.0+git20120204-1, which contains upstream upto   24ece4a87e. The glitches still appear, when compositing is enabled in KWin while VSync is disabled.

I will continue with VSync enabled. Which might be the better setting anyway.

My suspicion with regard to the flash is that it is just the artifact from front buffer rendering (i.e. you see intermediate drawing before the final result). Enabling VSync should cause the rendering to be performed in batches and so should reduce the number of times the intermediate result is flushed to the scanout before it is overdrawn.

Difficult to prove either way. But if I am correct that is the behaviour appropriate to the X protocol, and where the wayland design differs. Please do reopen if I've missed something or you have a definite bug. Actually, if you have a definite and distinct bug, open a new bug report. Thanks. (Marking as fixed as I think we *did* fix the original bug.)

Indeed this seems to be fixed with:

martin@merkaba:~> apt-show-versions | grep intel
[…]
libdrm-intel1/sid uptodate 2.4.32-1
[…]
xserver-xorg-video-intel/experimental uptodate 2:2.18.0-1+exp1
xserver-xorg-video-intel-dbg/experimental uptodate 2:2.18.0-1+exp1

There is only some very short flash left occassionally, that almost disappears immediately. No staying artifacts anymore. Anyway I enabled VSync again after testing with it disabled again for a few days.

Thanks you, Chris.