Hello, This bug is a continuation of my comments on bug #279615. This is for Ksnapshot 0.8.2 on KDE 4.14.1, openSUSE 13.2 RC1. 1. Open Ksnapshot (via menu or PrintScreen key) 2. When Ksnapshot appears, its preview of the full screen capture includes its own Ksnapshot window. 2.1 Ksnapshot should capture the whole screen, but automatically hide itself first before capturing. 3. Click "Save As" in Ksnapshot, save as ~/Desktop/snapshot1.png 4. Open ~/Desktop/snapshot1.png in an image viewer. The saved image not only shows the Ksnapshot window, but now on top it even shows the save dialog that I used to save snapshot1.png. 4.1 Ksnapshot should save whatever it captured and showed me in the preview before I saved it. It definitely should not be re-capturing the screen upon clicking "Save As". https://bugs.kde.org/attachment.cgi?id=89230 https://bugs.kde.org/attachment.cgi?id=89239 Reproducible: Always
> 2. When Ksnapshot appears, its preview of the full screen capture includes its own Ksnapshot window. This is already odd, and an indication a second instance of ksnapshot is running. The initial full screen grab should not include the ksnapshot window. Could you please show your ksnapshotrc, as well as check with Ctrl+Esc if there are multiple instances of ksnapshot?
I confirmed that there is only one instance of ksnapshot running. And I am attaching the ksnapshotrc. Thanks for looking into this!
Created attachment 89243 [details] ksnapshotrc
Apparently this is present in Kubuntu as well: http://mylinuxexplore.blogspot.com/2014/11/kubuntu-1410-utopic-unicorn-review.html "Only one thing to mention here is a bug in ksnapshot. Even in Kubuntu Trusty Ksnapshot or the screenshot taking program would work perfect. But, in 14.10, I had a hard time making it work. It would include the screenshot window as well along with the intended screen in Full Screen mode. I was able to manage using Rectangular Region mode somehow but it wasn't easy."
My openSUSE 13.1 x86_64 (KDE 4.11.5) system didn't had this bug. I did a test with the openSUSE 13.2 KDE-LiveCD x86_64 (KDE 4.14.2) and my installed openSUSE 13.2 system (also KDE 4.14.2). http://ftp4.gwdg.de/pub/opensuse/distribution/13.2/iso/openSUSE-13.2-KDE-Live-x86_64.iso http://software.opensuse.org/132/en LiveCD test in VirtualBox 4.3.18: no errors! Installed openSUSE 13.2 and LiveCD on my notebook. Both (installed system and LiveCD) give same results. Didn't changed any settings in the LiveCD-System before started testing. - KSnapshot captures itself - KSnapshort captures the "save dialog" When turning 3D acceleration off, the bug is gone! It's maybe something about the 3D chip being used. So this is my notebook's hardware: notebook vendor: Lenovo notebook model: ThinkPad x220 exact notebook model/type: 4291-36G CPU + GPU: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz RAM: 8 GB openSUSE 13.2 comes with: Linux kernel: 3.16.6 Mesa: 10.3.0
xfce4-screenshooter works fine on my openSUSE 13.2 x86_64 system! (still using KDE desktop environment, not XFCE) Using this xfce4-screenshooter from openSUSE 13.2 standard repository. http://download.opensuse.org/distribution/13.2/repo/oss/suse/x86_64/xfce4-screenshooter-1.8.1-9.1.4.x86_64.rpm
Mine is a Lenovo Thinkpad T530 with Intel graphics. I suspect it has to do with 3D graphics, particularly the faster machines. It's probably capturing some kind of leftover frames from the smooth transitions between application windows. I noticed on my screenshots that the opacity of the erroneously captured ksnapshot window had different levels of transparency on different shots, which would seem to be a capture of the fancy Kwin transitions.
On my desktop computer (very different hardware from my Lenovo ThinkPad notebook) KSnapshot is working fine! It doesn't captures itself and/or it's save dialog. My desktop computer's details: OS: openSUSE 13.2 x86_64 (KDE 4.14.2) CPU: AMD Phenom(tm) II X4 955 Processor RAM: 12 GB GPU: AMD Radeon HD 6450 GPU driver: radeon (opensource driver) On this computer I'm also using this software, provided by openSUSE 13.2: Linux kernel: 3.16.6 Mesa: 10.3.0
Another reviewer ran into this issue on KDE *and* Ubuntu Unity: http://www.dedoimedo.com/computers/kubuntu-utopic-kde4.html
I'm experiencing the same problem after upgrading to Kubuntu Utopic 14.10
I'm having this problem in Kubuntu Utopic Unicorn 14.10 while it didn't happen in 13.10
*** Bug 341037 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
In addition to what's already been posted about this bug, I've noticed that if you were to change whatever is on your screen (e.g., changing to a different window or different tab in your browser) after taking the snapshot but before actually saving it, it will save the current state of the screen as opposed to what you originally took a snapshot of. It seems that saving the image recaptures the screen upon doing so. I am currently running OpenSUSE 13.2.
It definitely doesn't look like we can blame the Xorg/Intel driver stack, because on this same machine, still running openSUSE 13.2, the Gnome screenshot tool works fine under Cinnamon.
(In reply to S from comment #15) > It definitely doesn't look like we can blame the Xorg/Intel driver stack, > because on this same machine, still running openSUSE 13.2, the Gnome > screenshot tool works fine under Cinnamon. I'd agree My openSUSE 13.2 Box with nvidia GPU is fine My Laptop with Intel has the bug (New user tested also) I'm also seeing some issues in apps (most notably Firefox) where I get what I would describe as broken artifacts in the apps UI
I have the same problem on Kubuntu 14.10.
Is this bug in high priority? It has a big impact on the user experiencie...
I agree that this bug should have a high priority. Unfortunately, neither of the KWin developers can reproduce it (see bug 279615 comment #42 and newer). And I cannot reproduce either with KDE 4.14.3 on openSUSE 13.1. If this happens on openSUSE 13.2 and KDE 4.14.3, it might be caused by (newer) video drivers not copying video memory when grabbing, but only returning a reference to the compositing buffers.
If you have an Intel GPU, please try using an openSUSE 13.2 LiveCD to reproduce the bug. If you have similar hardware as I (see link below) this should reproduce the bug for sure! https://bugs.kde.org/show_bug.cgi?id=340202#c5
Same problem here using default kwin on kubuntu with intel graphic (I tested also a live image of opensuse 13.2 with same result). But using KWIN_OPENGL_INTERFACE=egl or kwin_gles does not show this problem and screenshot are ok. Maybe this is not related but with the default kwin the vsync option are not respected. I used the "show paint" option and it shows "random" repaint on the screen (whatever option I select).
I can confirm that this is a bug in the intel driver. It is fixed in git (don't know which released version). I used this ppa in ubuntu "https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers" to upgrade the intel driver to git and it solved every problem with ksnapshot+kwin (with standard opengl effects).
Looks like the bug is gone on my openSUSE 13.2 with all current openSUSE 13.2 updates applied. But if you want to reproduce the bug, just use an openSUSE 13.2 x86_64 KDE livecd. It reliably reproduced this bug (at least on my CPU + GPU "Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz"). http://ftp4.gwdg.de/pub/opensuse/distribution/13.2/iso/openSUSE-13.2-KDE-Live-x86_64.iso
On Fedora 21, updating from xorg-x11-drv-intel-2.99.916-3.20141117.fc21 to a git snapshot fixed the issue.
The problem is also fixed again in Kubuntu 15.04. I'm setting to RESOLVED UPSTREAM as there is nothing which we could do about it :-(
(In reply to Loïc Yhuel from comment #24) > On Fedora 21, updating from xorg-x11-drv-intel-2.99.916-3.20141117.fc21 to a > git snapshot fixed the issue. In fact it's only hidden since DRI3 is now disabled by default. If I enable it in xorg-x11-drv-intel (like done on Rawhide), the bug reappears (unless I disable DRI3 for kwin, by setting LIBGL_DRI3_DISABLE=1).
@Martin Gräßlin Please don't set to RESOLVED UPSTREAM and set it back to CONFIRMED. I guess they'll re-enable DRI3 soon. (Anyone has information why they disabled it?) And there's for sure a way to fix this here. As said before, xfce4-screenshooter works well on exactly the same system (running a KDE session, just starting xfce4-screenshooter instead of ksnapshot). By the way: On openSUSE 13.2 it also seems to be the xf86-video-intel package. openSUSE 13.2 comes with xf86-video-intel-2.99.916-2.1. On such a system, I have to run LIBGL_DRI3_DISABLE=1 kwin --replace to make the bug disappear. On 15-Dec-2014 openSUSE 13.2 delivered xf86-video-intel-2.99.916-5.1 via update, which also completely disables DRI3. Afterwards ksnapshots works fine (also without LIBGL_DRI3_DISABLE=1).
The patch-file disabling DRI3 in openSUSE 13.2 xf86-video-intel-2.99.916-5.1 says: The external libraries, both in git, and especially shipping already enabled in distributions, are buggy and lead to server crashes and lockups. Caveat emptor. http://download.opensuse.org/update/13.2/src/xf86-video-intel-2.99.916-5.1.src.rpm A patch-file in Fedora 21 xorg-x11-drv-intel-2.99.916-3.20141117.fc21 says: Keith Packard says that he did not implement fences for mesa and so DRI3 with explicit fencing is currently broken by design. https://dl.fedoraproject.org/pub/fedora/linux/releases/21/Everything/source/SRPMS/x/xorg-x11-drv-intel-2.99.916-3.20141117.fc21.src.rpm I'm not sure if that means, they're completely disabling DRI3. @Loïc Yhuel Where did you see the information, that Fedora has completely disabled DRI3? Can you find any background information why they did so? So this may be a bug by the Intel driver DRI3 code (maybe the fences thing). But as said, xfce4-screenshooter seems to be able to work well under these conditions.
> But as said, xfce4-screenshooter seems to be able to work well under these conditions. which is completely irrelevant. Kernel may not break userspace, it's an old mantra from Linus. No matter how wrong our or xfce's code is, it should not break if the kernel changes a subsystem.
(In reply to kolAflash from comment #28) > @Loïc Yhuel > Where did you see the information, that Fedora has completely disabled DRI3? > Can you find any background information why they did so? DRI3 is now disabled by default upstream, by the patch you saw in openSUSE package (http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/configure.ac?id=b6eeb7a1f7efa591504070b606be655e27e6e9c2). The F21 package is older than that, so DRI3 is enabled. My git snapshot is newer, so DRI3 is disabled. On F22 (Rawhide), DRI3 was disabled for one release, but they now add --enable-dri3 (http://pkgs.fedoraproject.org/cgit/xorg-x11-drv-intel.git/commit/?id=716cbc7b81c69116aecdaeca680e7364fbe1e8d7).
The Fedora commit Loïc Yhuel mentioned (which is reenabling DRI3) is 2014-12-24. I tested this Fedora 22 rawhide/nightly livecd (date 2015-01-28): https://kojipkgs.fedoraproject.org//work/tasks/6665/8756665/Fedora-Live-Jam_KDE-x86_64-rawhide-20150128.iso http://koji.fedoraproject.org/koji/taskinfo?taskID=8756665 Result: DRI3 is enabled again and the bug is back! Workaround LIBGL_DRI3_DISABLE=1 is still possible. (That livecd comes without ksnapshot - you need to install it by "yum install ksnapshot") We should really consider to reopen this bug or at least to talk to the Intel developers if they can fix it in the DRI3 code of their driver! By the way: This isn't a kernel issue. So kernel doesn't breaks userspace. Everything the xf86-video-intel-2.99.916-5.1 update (openSUSE 13.2) changes are the following userspace libraries/executeables: /bin/intel-virtual-output /lib64/xorg/modules/drivers/intel_drv.so /lib64/libIntelXvMC.so.1.0.0 See: http://download.opensuse.org/update/13.2/x86_64/xf86-video-intel-2.99.916-5.1.x86_64.rpm
*** Bug 344424 has been marked as a duplicate of this bug. ***
If it's RESOLVED UPSTREAM, could one please point to the upstream bug report?
(In reply to Markus S. from comment #33) > If it's RESOLVED UPSTREAM, could one please point to the upstream bug report? I'm not sure whether there is an upstream bug report. But there certainly are downstream bug reports to disable DRI3 by default again.
Confirming on Fedora 21 KDE 4.14.6
DRI3 is also used in Fedora 22 and the bug is still here, now with KDE5.
Could someone please change the status back to OPEN! Looks like this is clearly not resolved-upstream.
(In reply to kolAflash from comment #37) > Could someone please change the status back to OPEN! > > Looks like this is clearly not resolved-upstream. RESOLVED UPSTREAM means that it's not our fault but usually it also means that an upstream bug number is provided. I lack the technical details to properly file a bug report. Maybe Martin can do it.
(In reply to Markus S. from comment #38) > (In reply to kolAflash from comment #37) > > Could someone please change the status back to OPEN! > > > > Looks like this is clearly not resolved-upstream. > > RESOLVED UPSTREAM means that it's not our fault but usually it also means > that an upstream bug number is provided. I lack the technical details to > properly file a bug report. Maybe Martin can do it. Sure, that it's not our (KDE's) faut? Because other screenshot tools (like xfce4-screenshooter) work fine, even with DRI3. To be sure, we must know which API calls KSnapshot uses to get the screens content and what's the documentation of those API calls. I guess, there's a buffer holding the screen content. But it's being overwritten again and again by the graphics driver (xf86-video-intel). So we must find out, if that behaviour is documented and wanted that way or if it's really a fault by the graphics driver, overwriting this buffer again and again. By the way: Is Ksnapshot going to be replaced by something else? http://quickgit.kde.org/?p=kscreengenie.git
> So we must find out, if that behaviour is documented and wanted that way or if it's really a fault by the graphics driver, overwriting this buffer again and again. I consider this as completely irrelevant. We had used it that way for > 15 years, if it breaks now it's a issue in the lower level. You don't break user space!
Kernel shouldn't break userspace. But as said, the kernel hasn't anything to do with this. It's those two shared-object files from package xf86-video-intel. intel_drv.so libIntelXvMC.so.1.0.0 Nevertheless, I created a bugreport upstream. So let's see what happends. https://bugs.freedesktop.org/show_bug.cgi?id=90836
(In reply to valdikss from comment #36) > DRI3 is also used in Fedora 22 and the bug is still here, now with KDE5. @valdikss For the upstream bugreport https://bugs.freedesktop.org/show_bug.cgi?id=90836#c1 we like to know, which exact version of the xorg-x11-drv-intel package is installed on your Fedora 22 system. Is it 2.99.917-6.20150211.fc22 or did you already update to 2.99.917-10.20150526.fc22 If it's the newer version, is the bug still there? Thanks!
I've booted Fedora from LiveUSB, but I'll try to update it asap.
I just found out that this has been going on for months, and I have about thirty pictures with what you describe, "not only is ksnapshot in the middle of the picture but also most of the time the "save dialog" is also in the picture". Big bummer for me, thought that I had those snapshots, and I had noticed it before so I used the workaround to take a new shot(full screen) after hitting the PrntScr(which would take a shot but with ksnapshot opening in the in the center of the pic) key, that used to work but sometime ago it apparently started behaving like this. My system is Fedora 21 KDE x86_64 all updates. ksnapshot.x86_64 14.12.3-1.fc21 @updates