flameshot Flameshot capturing outdated memory alongside monitor misalignment

Flameshot Version

Flameshot v12.1.0 (d420a53a) Compiled with Qt 6.9.1 Obtained from Terra (actions build from associated commit)

Installation Type

Linux, MacOS, or Windows Package manager (apt, pacman, eopkg, choco, brew, ...)

Operating System type and version

Fedora Linux 42 (KDE Plasma)

Description

When taking a screenshot using this version of Flameshot, my triple monitor configuration appears to slide over by one monitor, leaving my leftmost monitor out of view, and my right most monitor is replaced with what was previously in memory (possibly presenting a minor security risk under certain circumstances?).

To clarify, all three monitors have the same resolution using the same configuration apart from their horizontal offsets (all are aligned vertically) and the fact that the center monitor is the primary display (see system information).

I have noticed a similar issue has been reported in #1530 and #4009, but both of those describe this behaviour on exclusively Wayland, whereas I am on X11, therefore I thought I should make a separate issue.

Steps to reproduce

Run flameshot full using a multi-monitor configuration
???

Cannot reproduce using: Flameshot v12.1.0 (4edfb2a) Compiled with Qt 5.15.17 Obtained from Terra (actions build from associated commit)

Screenshots or screen recordings

Result of flameshot full (monitors can be identified using information on screen):

System Information

Fedora Linux 42 (kernel 6.14.11-300.fc42.x86_64)
KDE Plasma 6.3.5
KWin (X11) 6.3.5
NVIDIA 575.57.08 (from the negativo17 repository)
3x 1920x1080 @ 144Hz monitors (see below)

Thanks, Elliott

Jun 17 '25 18:06 pointydev

Thanks for the detailed report. Can you clarify the part that says "What was previously in memory"?

Jun 18 '25 00:06 borgmanJeremy

Referring to the screenshot I attached, some of the content to the right third was no longer on screen when the screenshot was taken, such as parts of the file explorer (sometimes while trying to reproduce, the right third was completely black or just a copy of one of the monitors).

Jun 18 '25 01:06 pointydev

I can add that I have the same issue with a very similar setup.

In my case, the screens are also shifted by one, but the "empty" areas are always just black. One monitor is a slightly lower resolution, and it gets a black border to match the resolution of the other screens.

The issue also happens when trying to screenshot a window region, the preview image is the monitors shifted to the right by one (with the originally leftmost screen being lost, and the rightmost screen in the image being pure black).

Full system info:

Flameshot:
  Flameshot v12.1.0 (d420a53a)
  Compiled with Qt 6.9.1
System:
  Kernel: 6.15.2-arch1-1 arch: x86_64 bits: 64
  Desktop: bspwm v: 0.9.10 Distro: Arch Linux
Graphics:
  Device-1: Advanced Micro Devices [AMD/ATI] Navi 31 [Radeon RX 7900 XT/7900
    XTX/7900 GRE/7900M] driver: amdgpu v: kernel
  Device-2: Advanced Micro Devices [AMD/ATI] Granite Ridge [Radeon Graphics]
    driver: amdgpu v: kernel
  Display: unspecified server: X.org v: 1.21.1.18 driver: X: loaded: amdgpu
    unloaded: modesetting dri: radeonsi gpu: amdgpu resolution:
    1: 2560x1440~165Hz 2: 2560x1440~165Hz 3: N/A
  API: EGL v: 1.5 drivers: kms_swrast,radeonsi,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 25.1.4-arch1.1
    renderer: AMD Radeon RX 7900 XTX (radeonsi navi31 LLVM 20.1.6 DRM 3.63
    6.15.2-arch1-1)
  API: Vulkan v: 1.4.313 drivers: radv surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo gpu: radeontop
    x11: xprop,xrandr
Monitors:
  0: +*DisplayPort-1 2560/597x1440/335+2560+0  DisplayPort-1
  1: +DisplayPort-0 2560/597x1440/335+0+0  DisplayPort-0
  2: +DisplayPort-2 1920/598x1080/336+5120+0  DisplayPort-2

I'm just guessing, but the issue may have something to do with the line 1: 2560x1440~165Hz 2: 2560x1440~165Hz 3: N/A from the X.org display (inxi output).

Jun 24 '25 10:06 Allypost

I'm just guessing, but the issue may have something to do with the line 1: 2560x1440~165Hz 2: 2560x1440~165Hz 3: N/A from the X.org display (inxi output).

Curious how my inxi doesn't want to show the resolutions, probably an NVIDIA moment.

$ inxi -SG
System:
  Host: pointy.local Kernel: 6.14.11-300.fc42.x86_64 arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.4.0 Distro: Fedora Linux 42 (KDE Plasma Desktop
    Edition)
Graphics:
  Device-1: NVIDIA TU106 [GeForce RTX 2070] driver: nvidia v: 575.64
  Device-2: Realtek FULL HD WEB CAM driver: snd-usb-audio,uvcvideo type: USB
  Display: x11 server: X.Org v: 21.1.16 with: Xwayland v: 24.1.8 driver: X:
    loaded: nvidia unloaded: modesetting,nouveau gpu: nvidia,nvidia-nvswitch
    resolution: 1: N/A 2: N/A 3: N/A
  API: EGL v: 1.5 drivers: nvidia,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 575.64
    renderer: NVIDIA GeForce RTX 2070/PCIe/SSE2
  API: Vulkan v: 1.4.313 drivers: nvidia,llvmpipe surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor gpu: nvidia-settings,nvidia-smi
    wl: wayland-info x11: xdriinfo, xdpyinfo, xprop, xrandr

$ xrandr --listmonitors
Monitors: 3
 0: +*DP-0 1920/521x1080/293+1920+0  DP-0
 1: +DP-2 1920/521x1080/293+0+0  DP-2
 2: +DP-4 1920/521x1080/293+3840+0  DP-4

Jun 24 '25 17:06 pointydev

Thanks for takiing the time to fill a bug report. The screenshot from the "past images" is actually an upstream issue originally reported in #2075 . This is not a Flameshot issue as Spectacle (KDE's own screenshot tool) have the same issue:

https://bbs.archlinux.org/viewtopic.php?id=263247

To help you understand the situation better, this is how Flameshot works:

Flameshot request a screenshot from the compositor (in this case Plasma)
Flameshot displays whatever compositor provides and allows the user to annotate.

Flameshot has zero understanding of what have been shown on the screen in the past. It merely displays whatever the compositor provides. Ergo, this can't be a Flameshot issue :)

I'm closing this as a duplicate of #2075 and also duplicate of other issues which have reported mis-aligned picture in a multi-monitor setup that the top of the monitors are not vertically aligned.

Jun 24 '25 21:06 mmahmoudian

@mmahmoudian

This is not a Flameshot issue as Spectacle (KDE's own screenshot tool) have the same issue

I just tested using the latest official Flatpak build, with this issue still occurring (could we get proper packaged builds back for testing?), but not occurring with a recent version of Spectacle, so while it may be an upstream issue, I believe it can be mitigated. I'd like to reiterate that I cannot reproduce this issue on 4edfb2ac1d71e7f75fcdcb850ff6bce5fb148a7b.

I'd also like to add that the top of my monitors are aligned (see my monitor configuration in the previous comment), so I don't believe that is quite the same issue.

Flameshot v12.1.0 (0d71402)
Compiled with Qt 6.9.0
linux: 6.14.11-300.fc42.x86_64
org.kde.Platform: 6.9

Spectacle: 6.4.0
KDE Frameworks: 6.15.0
Qt: Using 6.9.1 and built against 6.9.1
Fedora Linux 42 (KDE Plasma Desktop Edition) (Xcb)
Build ABI: x86_64-little_endian-lp64
Kernel: linux 6.14.11-300.fc42.x86_64

Jun 24 '25 22:06 pointydev

Same here, Spectacle works fine and displays the screens correctly. Additionally, I don't run KDE nor any intel drivers (which was stated as the problem in the linked issues). This happens whether I'm running a compositor or not (I'm using fastcompmgr and there is no difference between it running and not) so it seems it's either a different upstream issue or Flameshot's problem this time around.

Jun 25 '25 06:06 Allypost

@pointydev thanks for the comment. I have missed two key points in your original post:

"all three monitors have the same resolution using the same configuration apart from their horizontal offsets (all are aligned vertically)'
"KWin (X11) 6.3.5"

Sorry about that. Yes, regarding the offset, this is a not a duplicate as far as I can remember other issues. Although you have your main panel on your left monitor, "the center monitor is the primary display" and that's perhaps the issue that Flameshot tries to start displaying the screenshot at 0x0 coordinate of the primary monitor rather than the 0x0 coordinate of the overall canvas that the monitors make. In Wayland we have a similar issue but not exactly the same. Would it be possible for you to try this also on Wayland (same monitor setup, OS, Flameshot version,...) and see if the behavior is the same? Also, in X11, if you temporarily make the left-most monitor the primary, does the problem completely disappear?

Jun 25 '25 06:06 mmahmoudian

@mmahmoudian

I can confirm that on my setup, when the primary monitor is the leftmost one flameshot works as expected. Generalizing a bit more: whichever monitor is set as the primary becomes the "first"/leftmost monitor in the screenshot with all monitors that were originally to the left of the primary not showing up/getting cropped out. The overall resolution of the screenshot is correct (with black/garbage data filling in the rightmost part with the size of the "missing" monitors).

Jun 25 '25 09:06 Allypost

Here are my results when changing the primary display for X using the NVIDIA control panel, with xrandr outputs showing the same. Note that screen priorities in KDE display configuration were kept the same throughout. While all the dead areas show black here, I did see one just before taking these screenshots for the issue that showed the glitchy behaviour I observed in my original report.

$ xrandr --listmonitors 
Monitors: 3
 0: +*DP-2 1920/521x1080/293+0+0  DP-2
 1: +DP-0 1920/521x1080/293+1920+0  DP-0
 2: +DP-4 1920/521x1080/293+3840+0  DP-4

$ xrandr --listmonitors 
Monitors: 3
 0: +*DP-0 1920/521x1080/293+1920+0  DP-0
 1: +DP-2 1920/521x1080/293+0+0  DP-2
 2: +DP-4 1920/521x1080/293+3840+0  DP-4

$ xrandr --listmonitors 
Monitors: 3
 0: +*DP-4 1920/521x1080/293+3840+0  DP-4
 1: +DP-0 1920/521x1080/293+1920+0  DP-0
 2: +DP-2 1920/521x1080/293+0+0  DP-2

I also tried to take a screenshot with Flameshot in a Wayland session, but it would only show one monitor (the left) as selectable (it seemed like I could select the other monitors blindly by dragging the selection outside the visible area, but that isn't exactly usable), took this screenshot with Spectacle to demonstrate:

Jun 25 '25 11:06 pointydev

Flameshot v12.1.0 (3a206fce)
Compiled with Qt 6.9.1

Operating System: Manjaro Linux 
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.12.34-1-MANJARO (64-bit)
Graphics Platform: X11
Graphics Processor: Intel® Iris® Xe Graphics

I can confirm Flameshot works as expected when the primary monitor is the leftmost one.

$ xrandr --listmonitors 
Monitors: 4
 0: +*HDMI-1 1920/527x1080/296+0+0  HDMI-1
 1: +eDP-1 1920/302x1200/189+3840+0  eDP-1
 2: +DP-1 1920/527x1080/296+1920+0  DP-1
 3: +DP-2 1920/340x1080/190+1920+1080  DP-2

However, when the primary monitor is the rightmost one (in my case the "Pantalla Integrada" or built-in display), the rest of the screens are black and the built-in display is shifted to the left. My only temporary solution is to set the primary monitor from left to right.

Btw, Spectacle works fine and displays the screens correctly in both cases.

Jul 10 '25 08:07 Madh93

Is this bug going to be shipped with v13? Can still reproduce with the RPM artifact for Fedora 42 from this run. (sidenote, the commit hash isn't shown on the about screen)

Flameshot v13.0.0 ()
Compiled with Qt 6.9.1
linux: 6.15.6-200.fc42.x86_64
fedora: 42

Jul 26 '25 22:07 pointydev

Unfortunately yes as I have no way to replicate the issue, and I still think the root cause must be outside of flameshot. We simply use the free desktop portal to request a screen shot, and the display what that separate piece of software returns.

Jul 26 '25 22:07 borgmanJeremy

It's a shame as Spectacle doesn't have this issue (possibly using a workaround?), but Flameshot has the more complete feature set. Thank you regardless for your continued development work.

Jul 26 '25 23:07 pointydev

@pointydev what version of spectacle are you using? I can check what they are doing. I wonder if even on X11 they use the portal API, Im thinking about this more and on X11 we dont use the freedesktop portal, instead we use the native Qt screenshot call.

Jul 26 '25 23:07 borgmanJeremy

Spectacle: 6.4.3
KDE Frameworks: 6.16.0
Qt: Using 6.9.1 and built against 6.9.1
Fedora Linux 42 (KDE Plasma Desktop Edition) (Xcb)
Build ABI: x86_64-little_endian-lp64
Kernel: linux 6.15.6-200.fc42.x86_64

Jul 27 '25 00:07 pointydev

Also I'd just like to add, if any workarounds or fixes come to light, I'd happily be willing to test them on my system provided they're RPM packaged. If there's any Fedora specific testing you'd like doing in future, I'm also open to that too (feel free to hit me up on Discord @pointy).

Jul 28 '25 02:07 pointydev

The v13 release notes mention mixed monitor setups, is that referring to the other issue that this was originally misclassified as, or will the stated fix for v14 include a workaround to this issue?

Aug 03 '25 22:08 pointydev

Not this issue, I still don't know what to make of this.

Aug 03 '25 22:08 borgmanJeremy

I myself have experienced this in v11, and in IRL people reported to me about this issue as well on v11. At the time the common factors were V11 + KDE Plasma + Arch/Manjaro. I never managed to find a way to reproduce it consistently.

Since v12 onwards I've not experienced it and this issue is the first one that is reported this behavior.

@pointydev can you reproduce this consistently in a VM? That can be a very good start for us to have an environment in which we can reproduce this issue and investigate.

Aug 04 '25 06:08 mmahmoudian

@mmahmoudian Successfully reproduced in a VM (created using virt-manager) using Fedora 42 KDE on the first attempt with the plasma-workspace-x11 package installed and switched to on the login screen, using multiple virtio heads so that multiple monitors can be used (see below, virt-viewer used to see all monitors), and Flameshot v13 from releases.

$ xrandr --listmonitors
Monitors: 3
 0: +*Virtual-1 1920/487x1080/274+1920+0  Virtual-1
 1: +Virtual-2 1920/487x1080/274+0+0  Virtual-2
 2: +Virtual-3 1920/487x1080/274+3840+0  Virtual-3

<video>
  <model type="virtio" heads="3" primary="yes"/>
  <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>

Flameshot v13.0.0 ()
Compiled with Qt 6.9.1
linux: 6.15.8-200.fc42.x86_64
fedora: 42

Spectacle: 6.4.3
KDE Frameworks: 6.16.0
Qt: Using 6.9.1 and built against 6.9.1
Fedora Linux 42 (KDE Plasma Desktop Edition) (Xcb)
Build ABI: x86_64-little_endian-lp64
Kernel: linux 6.15.8-200.fc42.x86_64

Aug 04 '25 15:08 pointydev

This happens to me as well on Budgie 10.9.2 with Flameshot v13.0.1 (Qt 6.9.1). Looks like I'm an outlier here because I can mostly see reports of this happening on KDE. Budgie, however, is GNOME-based. Output from inxi -SG:

System:
  Host: nekoarch Kernel: 6.15.9-arch1-1 arch: x86_64 bits: 64
  Desktop: Budgie v: 10.9.2 Distro: Arch Linux
Graphics:
  Device-1: NVIDIA GA104 [GeForce RTX 3070 Lite Hash Rate] driver: nvidia
    v: 575.64.05
  Display: x11 server: X.org v: 1.21.1.18 with: Xwayland v: 24.1.8 driver:
    X: loaded: nvidia unloaded: modesetting gpu: nvidia,nvidia-nvswitch
    resolution: 1: 1280x1024~60Hz 2: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: nvidia,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 575.64.05
    renderer: NVIDIA GeForce RTX 3070/PCIe/SSE2
  Info: Tools: api: eglinfo,glxinfo gpu: nvidia-settings,nvidia-smi
    x11: xprop,xrandr

Worth noting that this doesn't happen with Budgie's built-in screenshotting tool, which opens a really interesting perspective to see (see the funny stuff at the right): "An image was here. If it doesn't show up, I deleted it." Somehow, I don't recall this happening a few months prior, despite having a dual-monitor setup for a good while.

Aug 10 '25 15:08 Alluseri

@Alluseri this is indeed not KDE exclusive, as there was a reproduction earlier in the thread from someone using bspwm. Also reiterating that KDE Spectacle also doesn't have this issue.

@mmahmoudian following up the detailed repro instructions you asked for (the same process I used):

For my reproduction I used the same OS I'm actually using, Fedora KDE 42 x86_64 from here
Create a new VM using virt-manager
Select Local install media
Select Browse, then add the directory containing the ISO (using the dir type, name the pool whatever you want, I would recommend making a dedicated folder for your system images)
Select the Fedora image and click Choose Volume
Select memory and cores to use (I would recommend at least 8GB/8192MB and 8 cores)
Create a disk image for the VM automatically (the default 20GB should be fine, we can delete this later)
Name the VM something recognisable (e.g. flameshot-test), then tick Customise configuration before install

Go to the Video tab, go to the XML tab and paste the following in, then click Apply

<video>
  <model type="virtio" heads="3" primary="yes"/>
  <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>

Click Begin Installation top left
On the GRUB screen, skip testing media and select Start
Open Install to Hard Drive (single click on the icon in the popup)
Select a language (irrelevant, but I used English (UK))
Select Installation Destination, then select Custom under Storage Configuration, then Done
Switch from Btrfs to Standard Partition, then click Click here to create them automatically (likely irrelevant, but I've always found ext4 to be more stable than btrfs), then click Done and Accept Changes
Click User Creation, insert a username and uncheck Require a password to use this account (for ease of use), then click Done and Begin Installation, then Finish Installation once complete
Open the application launcher, select Restart
Press enter to skip the password prompt
Open Konsole from the app launcher and type sudo dnf upgrade --assumeyes to install system updates (Fedora can be a little funky if you don't do this and start installing other packages and dependencies)
Once that finishes, type sudo dnf install plasma-workspace-x11 --assumeyes, then restart again to ensure everything is upgraded
Before logging in, select Plasma (X11) as the desktop session bottom left, then skip the login screen as before
Back on your host machine, install virt-viewer and run sudo virt-viewer vmname (with vmname what we set back in step 8). This should disconnect the view inside virt-manager.
To ensure the monitor windows the same size while testing, click the hamburger menu top right and uncheck Auto resize
Open Display Configuration inside the VM and set all monitors to the same resolution (800x600 works) and ensure they are all aligned, then change priorities so that the center monitor is the primary one, then click Apply, then confirm the changes (you may have to resize the window)
Put the screen windows in the same order on screen as shown in the configuration using the numbers in the window names
Open Konsole and run dnf install https://github.com/flameshot-org/flameshot/releases/download/v13.0.1/flameshot-13.0.1-1.fc42.x86_64.rpm --assumeyes
Open Flameshot, then attempt to take a screenshot, and observe
Once you've finished with the VM, you can free up the storage space taken by the virtual drive and VM configuration by right clicking the VM in the virt-manager list and ensuring Delete associated storage files remains checked, then clicking Delete

Aug 10 '25 17:08 pointydev

This issue appears to have been fixed by #4127, thank you to @ionsquare for the fix.

Flameshot v13.1.0 ()
Compiled with Qt 6.9.1
linux: 6.15.9-201.fc42.x86_64
fedora: 42

Aug 16 '25 15:08 pointydev