And now... I found a workaround. The problem is Wayland. Or rather, the problem is that something goes strangely wrong if I run ksnip in my environment, while allowing Qt to auto-adapt as it does at this time. I had this weird thought in my mind, that the factor of 2 by which the images are mistreated sounded familiar - from one point only: it's the scale factor I'm using for my 4k screens.

So I ran ksnip like this:

XDG_SESSION_TYPE=xwayland QT_QPA_PLATFORM=xcb ksnip -e <file.png>

... and voila, it's all good. Suddenly the annotated saved file maintains the original resolution, and it is complete and not just the top-left corner. Magic.

I'll close this issue and apologize for the hassle - I hope the workaround is going to help somebody, but I suspect that a fix is out of scope for ksnip.

hmm, could it be that you're facing this issue that should be fixed in latest? #439

@DamirPorobic Yes and no, I guess. I suspect that my issue is related to running on a scaled Wayland. The corner of the image that is being persisted is most definitely the top left one though, every time. Odd discrepancy between my issue and #439, but there it is. Of course my workflow also includes using -e instead of taking a screenshot directly, but that's probably not an important difference.

(I tried to take a screenshot btw, but as long as I'm running natively on Wayland, it does not work - I use Sway and I suspect that ksnip does not support its screenshot protocol.)

@DamirPorobic My apologies - I didn't mean to ignore your suggestion that v1.8.0 might fix the problem. I just installed that version using the ksnip-git AUR package. Mixed news:

• Good news: the test I ran before now seems to work - I can edit an image, and it it saved completely, i.e. not just the top-left corner. When I check the result image visually, it looks correct.
• Bad news: something is still wrong with the result file, since it includes four times the pixels of the source image according to identify:

➜ identify 20201118-090829.png test.png
20201118-090829.png PNG 768x606 768x606+0+0 8-bit sRGB 118515B 0.000u 0:00.000
test.png PNG 1536x1212 1536x1212+0+0 8-bit sRGB 217992B 0.000u 0:00.000

• Finally, bad (though unrelated) news: screenshots seem to support the dbus portal system on Wayland now. However, this doesn't do anything for Sway. Based on what I recently read in the Flameshot repo, it is also not a very good way - but that's a different discussion. Just thought I'd mention it while I was trying the latest build.

Hey Oli, sorry for the late replies, I usually reply within a day. I'm in the middle of a move to a new flat and need to renovate that thing so I don't get to much PC time at the moment :)

If I remember correctly, the user that requested Generic Wayland Portal Screenshots used also Sway and for him (and other Sway Users) I have implemented a Setting that prevents this upscaling that you see, it's under the Image Grabber Settings and can only be enabled for Wayand, see here for more details: #243.

Regarding the taking Screenshots via DBus, it's the way thinks are done under Wayland. Wayland is more secure then X11 and doesn't allow accessing what you want, you need to request stuff via DBus calls and the DE honors your request or not. So far Gnome and KDE Plasma had own implementations for Wayland Screenshots that were quit different but both relied on DBus calls and ksnip (like other Screenshot tools) supported both ways. Now every DE is implementing the XDG Screenshot Portal for taking screenshots, which is a generic way but also relies on DBus calls but also involves an additional confirmation window (or not, like in the case of Sway). Ksnip adds XDG Portal support with version 1.8.0 and so far the only Screenshot tools that supports it (though this might have changed recently). Under Gnome and KDE Plasma we still use the DE Specific screenshots but you have a setting to enforce the XDG Portal Screenshots here to (under Image Grabber). If the DE is not Gnome or KDE Plasma or ksnip running in a snp environment, we use by default the XDG Portal Screenshots.

Hi Damir,

Moving must be more stressful than usual at this time, I don't envy you!

If I remember correctly, the user that requested Generic Wayland Portal Screenshots used also Sway and for him (and other Sway Users) I have implemented a Setting that prevents this upscaling that you see, it's under the Image Grabber Settings and can only be enabled for Wayand, see here for more details: #243.

I didn't read the entire long issue, I'm afraid. However, I'm confused. First, that issue seems to pertain to the actual "grabbing" functionality, as does the setting you mention. I'm not doing any grabbing, I'm just editing. So is it news to you that the problem is actually just one of file persistence, not related to grabbing at all? Or is this a completely different problem after all?

Additionally, I'm not sure which setting you are referring to. The thread #243 refers to a "factor" multiple times, but I don't see any setting of a "factor" anywhere on the Image Grabber settings page. I see two items called "force generic wayland screenshot" and "scale generic wayland screenshot". They are both unchecked. I tried running ksnip with and without the "anti-wayland" environment variables and nothing changes about the settings on that page.

Regarding the taking Screenshots via DBus, it's the way thinks are done under Wayland.

I'm not going to pretend to be an expert, but I believe this is only partially true. I was specifically referring to this issue from the Flameshot repo, where I found a comment indicating that the xdg-desktop-portal approach may be too high-level for a screenshot tool, since it may involve a DE-specific dialog popping up. In my environment, I can't see the xdg-desktop-portal based functionality in action, so I can't judge whether this is a big problem.

My second reason to say that the statement is only partially true is that I'm now using grim (in combination with slurp), and it takes screenshots very nicely on Sway. I understand it uses a protocol called wlr-screencopy, which seems to be implemented in wlroots and therefore available in all wlroots-based compositors.