ksnapshot: taking a snapshot has sometimes the opened file dialog window where to save the file added to the screenshot afterwards

[star-buck]

sounds like timewarp magic has been added to frameworks lately...

[star-buck]

Example (not Photoshopped!!! only removed the annoying "e" in jpeg per hand):

[eikehein]

^ It's worth noting that this is the KDE 4 version of KSnapshot (you can tell by the position of the buttons in the Save As dialog - the KF5 dialog uses QDialogButtonBox and has the buttons at the bottom, which is ugly by the way). It's probably a real bug in the KDE 4 version, but I'm not sure if we're ever going to make a release of it again -- the next KDE Applications release should probably ship the KF5 port, where I can't reproduce this ...

[star-buck]

another weirdness: PRINT brings up ksnapshot with its own popup overlaying the snapshot already (which it didnt do in kde4) qdbus org.kde.kwin /Effects unloadEffect screenshot

[eikehein]

Edit: I theorized asynchronous screenshot-taking via KWin might be at fault, but KWin isn't used in fullscreen screenshot mode.

(I currently can't reproduce this problem on the system installed from the ISO or on other systems.)

[star-buck]

just posted on IRC: another angle i tried testing your kwin theory: (10:31:19 PM) starbuck11: xrender instead of opengl solves this even with mouse cursor disabled! (10:31:23 PM) starbuck11: hooray! (10:32:18 PM) starbuck11: so thats why with netrunner over here constantly failing with opengl and intel and therefore setting to xrender default (as advised) was taking screenshots just fine

[star-buck]

https://www.dropbox.com/s/yo7fyv1y0zpceit/knsapshot.mkv?dl=0

[mgraesslin]

I'm able to reproduce the problem on my notebook with the current ISO.

[mgraesslin]

I did some testing yesterday and tried all possible combinations of repaint strategies and buffer handling in KWin with OpenGL compositing. The problem was present with all of them.

My current theory is that X reads from KWin's write buffer instead of the read buffer. If that's the case the problem should be reproducable with any OpenGL compositor.

[mgraesslin]

Not reproducable with Compton. This makes everything more confusable.

[mgraesslin]

Doesn't happen with EGL

[mgraesslin]

and I cannot reproduce on Debian.

[mgraesslin]

Maybe relevant packages:

• libdrm-intel1:
  • Debian testing: 2.4.58
  • Ubuntu utopic: 2.4.56
  • Ubuntu vivid: 2.4.58
• xserver-xorg-video-intel:
  • Debian testing: 2.21.15
  • Ubuntu utopic: 2.99.914
  • Ubuntu vivid: 2.99.917
• xserver-common:
  • Debian testing: 1.16.2
  • Ubuntu utopic: 1.16.0
  • Ubuntu vivid: 1.16.2
• libgl1-mesa-dri:
  • Debian testing: 10.3.2
  • Ubuntu utopic: 10.3.0
  • Ubuntu vivid: 10.3.2

Overall the ISO (based on utopic) has older versions than Debian testing. Especially bug fix releases are missing in X, mesa and drm. All of them are updated in vivid to the same version which is in Debian testing. Given that I suggest that we move back any further investigations till the ISO switched over to vivid.

Another possibility is that the xserver-xorg-video-intel is at fault here. Ubuntu is shipping an experimental package (notice the version number .99 and it's in Debian experimental with an explicit "exp" suffix in the package version). I could try to install that package on my system, but I'm hesitant as I fear to destroy the system by installing experimental drivers.

[mgraesslin]

I just tested the vivid live cd (still Plasma 5.1, though) and there the problem is not reproducable.

[mgraesslin]

and another test: Kubuntu 14.10 tech preview live iso shows the problem.

[star-buck]

yes, it is very likely xserver-xorg-video-intel: I updated to 2.99.917 on utopic and ksnapshot became normal, so I would rule out the other packages.

You think it is safe to close this or might there be something on our side lurking, as the ksnapshot behaviour was certainly a bit frightening ;)

[mgraesslin]

Given the testing I did I'm 99.9 % sure that we are innocent here.

[star-buck]

okay, closing then here