Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flameshot on Wayland not handling multiple screens #2364

Open
Steffo99 opened this issue Feb 4, 2022 · 106 comments
Open

Flameshot on Wayland not handling multiple screens #2364

Steffo99 opened this issue Feb 4, 2022 · 106 comments
Labels
Bug It's a bug Wayland Wayland specific issues

Comments

@Steffo99
Copy link

Steffo99 commented Feb 4, 2022

Initial report

Flameshot Version

Flameshot v11.0.0 ()
Compiled with Qt 5.15.2
linux: 5.16.5-arch1-1
arch: unknown

Installation Type

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

Operating System type and version

Linux 5.16.5-arch1-1 #1 SMP PREEMPT Tue, 01 Feb 2022 21:42:50 +0000 x86_64 GNU/Linux

Description

Summary

While using multiple screens on Plasma Wayland, Flameshot seems unable to detect all of them properly, and instead takes a screenshot of the left-most screen through KWin, and prompts the user to edit it via the editor.

Additionally, Flameshot seems unable to copy the selected screenshot to the clipboard, but no error is shown and I'm unsure it's related to this bug.

Logs

steffo@nitro:~$ flameshot gui
Unable to get current screen, starting to use primary screen. It may be a cause of logical error and working with a wrong screen.
Unable to get current screen, starting to use primary screen. It may be a cause of logical error and working with a wrong screen.
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
Unable to get current screen, starting to use primary screen. It may be a cause of logical error and working with a wrong screen.
Unable to get current screen, starting to use primary screen. It may be a cause of logical error and working with a wrong screen.
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

Steps to reproduce

With a Wayland session with multiple monitors, using Plasma Desktop:

  1. Run flameshot gui

Screenshots or screen recordings

Will provide a screen recording as soon as OBS Studio finishes compiling 🥲

System Information

uname

steffo@nitro:~$ uname -a
Linux nitro 5.16.5-arch1-1 #1 SMP PREEMPT Tue, 01 Feb 2022 21:42:50 +0000 x86_64 GNU/Linux

Plasma

Plasma Desktop installed from the plasma-desktop 5.23.5-1 Arch Linux package.

@Steffo99 Steffo99 added the Unconfirmed Bug The bug is not confirmed by anyone else. label Feb 4, 2022
@mmahmoudian
Copy link
Member

@Steffo99 can you also post here your monitor arrangement and if you have different resolutions and scalings on the monitors.

@Steffo99
Copy link
Author

Steffo99 commented Feb 5, 2022

My monitor arrangement is:

  • a center 1920x1080 monitor with no scaling
  • two 1280x1024 monitors on the left and right sides with no scaling, vertically aligned to the center

That said...

OBS seems to be failing to launch, so there might be something else currently not working on my setup...

I should be able to do more research on the problem either tomorrow or on Sunday: I'll keep you updated with my findings!

@mmahmoudian mmahmoudian added the Waiting For Info Addressing the issue or merging the PR is halted and we are waiting for more info to be provided. label Feb 5, 2022
@Steffo99
Copy link
Author

Steffo99 commented Feb 6, 2022

System information 2

I just noticed I forgot to mention that I'm using Wayland with the Nvidia proprietary driver and the newly introduced GBM API.

Screen capture failure

I couldn't get a single screen capture program to work, so I'm starting to suspect that something is wrong with my setup.

OBS, KSnap and Grim logs
steffo@nitro:~$ obs
Attempted path: share/obs/obs-studio/locale/en-US.ini
Attempted path: /usr/share/obs/obs-studio/locale/en-US.ini
Attempted path: share/obs/obs-studio/themes/Dark.qss
Attempted path: /usr/share/obs/obs-studio/themes/Dark.qss
info: Platform: Wayland
info: CPU Name: AMD Ryzen 5 1600X Six-Core Processor
info: CPU Speed: 3102.166MHz
info: Physical Cores: 6, Logical Cores: 12
info: Physical Memory: 15992MB Total, 8343MB Free
info: Kernel Version: Linux 5.16.5-zen1-1-zen
info: Distribution: "Arch Linux" Unknown
info: Session Type: wayland
info: Portable mode: false
Attempted path: share/obs/obs-studio/themes/Dark/no_sources.svg
Attempted path: /usr/share/obs/obs-studio/themes/Dark/no_sources.svg
QMetaObject::connectSlotsByName: No matching signal for on_tbar_position_valueChanged(int)
QMetaObject::connectSlotsByName: No matching signal for on_actionShowTransitionProperties_triggered()
QMetaObject::connectSlotsByName: No matching signal for on_actionHideTransitionProperties_triggered()
info: OBS 27.1.3-tytan652-14 (linux)
info: ---------------------------------
info: ---------------------------------
info: audio settings reset:
        samples per sec: 48000
        speakers:        2
info: ---------------------------------
info: Initializing OpenGL...
info: Using EGL/Wayland
info: Initialized EGL 1.5
error: eglChooseConfig failed
error: device_create (GL) failed
error: Failed to initialize video.  Your GPU may not be supported, or your graphics drivers may need to be updated.
Cannot find EGLConfig, returning null config
error: obs_display_init: Failed to create swap chain
info: Freeing OBS context data
info: == Profiler Results =============================
info: run_program_init: 2076.4 ms
info:  ┣OBSApp::AppInit: 6.239 ms
info:  ┃ ┗OBSApp::InitLocale: 0.861 ms
info:  ┗OBSApp::OBSInit: 77.217 ms
info:    ┣obs_startup: 12.337 ms
info:    ┗OBSBasic::OBSInit: 6.23 ms
info:      ┣OBSBasic::InitBasicConfig: 0.102 ms
info:      ┣OBSBasic::ResetAudio: 0.227 ms
info:      ┗OBSBasic::ResetVideo: 5.864 ms
info: obs_hotkey_thread(25 ms): min=0 ms, median=0 ms, max=0.001 ms, 99th percentile=0.001 ms, 100% below 25 ms
info: audio_thread(Audio): min=0.008 ms, median=0.019 ms, max=0.032 ms, 99th percentile=0.032 ms
info: =================================================
info: == Profiler Time Between Calls ==================
info: obs_hotkey_thread(25 ms): min=25.032 ms, median=25.082 ms, max=25.491 ms, 100% within ±2% of 25 ms (0% lower, 0% higher)
info: =================================================
info: Number of memory leaks: 184
steffo@nitro:~[130]$ ksnip
Warning: Unable to find any translation files for ksnip.
Warning: Unable to find any translation files for kImageAnnotator.
Warning: Wayland does not support QWindow::requestActivate()
Warning: Wayland does not support QWindow::requestActivate()
Warning: This plugin does not support setting window opacity
Critical: Unable to show image: No image provided but one was expected.
Warning: Wayland does not support QWindow::requestActivate()
Warning: Wayland does not support QWindow::requestActivate()
steffo@nitro:~$ grim
compositor doesn't support wlr-screencopy-unstable-v1

The grim log makes me think that perhaps a protocol required for proper screen capture is missing from KWin...

@Steffo99
Copy link
Author

Steffo99 commented Feb 6, 2022

Segfault?

flameshot screen appearently segfaults?

steffo@nitro:~$ flameshot screen
fish: Job 1, 'flameshot screen' terminated by signal SIGSEGV (Address boundary error)

@Steffo99
Copy link
Author

Steffo99 commented Feb 6, 2022

Example screenshot

This is what screenshots of the middle screen taken with flameshot gui look like:

A 1920x1080 screenshot taken from the middle screen, displaying part of the left 1280x1024 screen

@Steffo99
Copy link
Author

Steffo99 commented Feb 6, 2022

Screenshot of the bug

spectacle seems to work!

Screenshot_20220206_175726

@Steffo99
Copy link
Author

Steffo99 commented Feb 9, 2022

If you need additional info I'd be glad to provide them :)

@mmahmoudian
Copy link
Member

mmahmoudian commented Feb 10, 2022

I have similar setup and don't have this issues.

Similarities:

  • 3 monitors with H shape arrangement
  • Nvidia proprietary driver
  • KDE Plasma

Differences:

  • all monitors have the same resolution
  • I use X11
  • I'm on Manjaro

I can't mess up with this computer to try to reproduce this issue. So let's wait and see if other devs have a solution/hypothesis in mind.

P.s: thanks for providing all these information 👍🏼

@fraschm1998
Copy link

I have the same issue, I'm running Wayland with DWL on Gentoo with Nvidia proprietary drivers. I have my laptop 1920x1080 and an external monitor 3840x2160. I do not have Xwayland enabled in DWL but I do have Xwayland installed

@ModProg
Copy link

ModProg commented Feb 15, 2022

This is not related to NVIDIA, I have the same issue using sway with an AMD GPU.

Interesting to note is, it captures my left screen, but displays the editor on my right screen, even tho I tried to capture my middle screen.

@mmahmoudian mmahmoudian added Wayland Wayland specific issues and removed Waiting For Info Addressing the issue or merging the PR is halted and we are waiting for more info to be provided. labels Feb 16, 2022
@Hi-Alex
Copy link

Hi-Alex commented Feb 23, 2022

Hi

Have the same issue in the same setup.

Flameshot v11.0.0 (-)
Compiled with Qt 5.15.2

Manjaro, Plasma version 5.24.2, and using wayland with proprietary nvidia drivers.

Appears in both scenarios when resolution on all screens is equal and when center monitor have higher resolution, but differently. In first case flameshot appears on the right screen showing the left screen, in second - appears on the center screen and shows left screen with a bit bit of the center screen.

In the terminal "flameshot gui" has this info:
Unable to get current screen, starting to use primary screen. It may be a cause of logical error and working with a wrong screen. Unable to get current screen, starting to use primary screen. It may be a cause of logical error and working with a wrong screen. qt.qpa.wayland: Wayland does not support QWindow::requestActivate() Unable to get current screen, starting to use primary screen. It may be a cause of logical error and working with a wrong screen. flameshot: info: Screenshot aborted.

flameshot screen:
zsh: segmentation fault (core dumped) flameshot screen

flameshot_bug_equal_resolution

flameshot_bug_diff_resolution

@mmahmoudian mmahmoudian added Bug It's a bug and removed Unconfirmed Bug The bug is not confirmed by anyone else. labels Feb 24, 2022
@143mailliw
Copy link

Yeah, I'm having the same issue on Sway as well, screenshots the left screen and shows the GUI on the right screen.

@marcwittke
Copy link

marcwittke commented Feb 25, 2022

Am I late to the party? At least now it starts on Plasma 5.24.1 (Wayland, no scaling, intel iGPU) and flameshot 11, but...

Spectacle:
spectacle

Flameshot:
flameshot

(shifted to the right by one FullHD screen)

@rstrube
Copy link

rstrube commented Mar 2, 2022

I'm running KDE plasma 5.24.2 with multiple monitors and I'm also experiencing this issue.

What seems to be occurring is that flameshot starts with the total screen real-estate of both monitors combined, but tries to present that real estate on the primary monitor. This obviously can't fit, so things appear to shift around as it presents just the top left view of the total combined real estate.

I've noticed that on Gnome, you're prompted to select a monitor first (via xdg-desktop-portal), which limits flameshot's initial starting to a single monitor. This means that you can't create screenshots across monitors, but it doesn't have the issue where window contents are shifted around as it tries to squeeze the entire real estate view into a single monitor.

Perhaps do something similar with KDE plasma running on wayland and present the xdg-desktop-portal dialog?

@xstable
Copy link

xstable commented Mar 11, 2022

I also have the same issue.
Switched today from xorg to wayland, and found that on dual-screen setup, flameshot shows the "select area" at the right (secondary) screen, while in the background you see the content of the primary screen.
Strange!

My Setup:

Betriebssystem: Manjaro Linux
KDE-Plasma-Version: 5.24.2
KDE-Frameworks-Version: 5.91.0
Qt-Version: 5.15.2
Kernel-Version: 5.15.25-1-MANJARO (64-bit)
Grafik-Plattform: Wayland
Prozessoren: 8 × Intel® Core™ i7-3610QM CPU @ 2.30GHz
Speicher: 15,1 GiB Arbeitsspeicher
Grafikprozessor: Mesa DRI Intel® HD Graphics 4000

Flameshot v11.0.0 (-)
Compiled with Qt 5.15.2
linux: 5.15.25-1-MANJARO
manjaro: unknown

@ryan77627
Copy link

Hey, I'd like to report I have the same issue as well. Running flameshot v11.0.0 on sway 1.7 and wlroots 0.15.1. Seems it grabs my left-most monitor as the only display when using flameshot screen (even when executing the command from the other screen). When running in gui mode, the screenshot is always of the leftmost screen and the interface always appears on the rightmost screen. Running under Xwayland (QT_QPA_PLATFORM=xcb) resolves the issue, however in sway it seems that breaks keyboard shortcuts (it thinks it isn't focused)

For reference, I have two monitors that are arranged like the attached photo shows. Both are 1080p with the same amount of scaling.

flameshot_screen_layout

@rstrube
Copy link

rstrube commented Mar 25, 2022

Running under Xwayland (QT_QPA_PLATFORM=xcb) resolves the issue, however in sway it seems that breaks keyboard shortcuts (it thinks it isn't focused).

This also fixes the issues i've been having in KDE Plasma with multiple monitors, thanks for the tip!

@UltraBlackLinux
Copy link

UltraBlackLinux commented Mar 26, 2022

Although the above fix works (apparently only when launching FS via the terminal), I was able to verify, that version 0.10.2 doesn't have this problem

@ryan77627
Copy link

ryan77627 commented Mar 26, 2022 via email

@Sharparam
Copy link

Setting QT_QPA_PLATFORM=xcb seems to make it work with multiple monitors, but makes it unable to handle keyboard shortcuts it seems. (Ctrl+C or Ctrl+S no longer work for copying to clipboard or saving to file, manually pressing the buttons or using double left click still works.)

@fx
Copy link

fx commented Apr 1, 2022

For me, it simply opens on the right-most monitor, full screen. Luckily that's easily fixed in the sway config:

for_window [app_id="flameshot"] border pixel 0, floating enable, fullscreen disable, move absolute position 0 0

@143mailliw
Copy link

For me, it simply opens on the right-most monitor, full screen. Luckily that's easily fixed in the sway config:

for_window [app_id="flameshot"] border pixel 0, floating enable, fullscreen disable, move absolute position 0 0

Thanks for this, that fixed my multi monitor issue. Now I just need to fix my clipboard and it'll be working perfectly.

@borgmanJeremy
Copy link
Contributor

We just merged a change to use the XDG portal on KDE wayland. That might have resolved this.

@doublevoid
Copy link

The change doesn't seem to have helped, still need the QT_QPA_PLATFORM=xcb, which still breaks the shortcuts

@alxndr13
Copy link

alxndr13 commented Oct 6, 2023

I was able to work around this in KDE with these window settings

  • Matching the window class and title - to only affect the screenshot editor, and not any of the configuration windows
  • Force Fullscreen off - to allow flameshot to cover all monitors
  • Force Position 0, 0 - to put flameshot on the leftmost monitor
  • Force Ignore requested geometry - to prevent flameshot from overriding Fullscreen and Position
  • Apply Initially Keep above others - to allow flameshot to cover all desktop panels (because fullscreen is off)

Thanks man, that helped putting me on the right track on sway. I wanted to only have the screenshot editor to be fullscreen, not the savings dialog or the config menu.

added:

for_window [title="flameshot" app_id="flameshot"] fullscreen enable global

to my sway config, works as expected now.

@e-cal
Copy link

e-cal commented Oct 24, 2023

Workaround for hyprland:

windowrule=nofullscreenrequest,flameshot
windowrule=float,flameshot
windowrule=monitor 0,flameshot
windowrule=move 0 0,flameshot

@Cybso
Copy link

Cybso commented Dec 13, 2023

Edit: Sorry, I was wrong about this. This patch does NOT resolve the issue.

The keyboard issue with QT_QPA_PLATFORM=xcb can be resolved with the following patch:

--- flameshot-12.1.0.bak/src/core/flameshot.cpp 2022-07-03 15:42:21.000000000 +0200
+++ flameshot-12.1.0/src/core/flameshot.cpp 2023-12-13 13:31:06.850534282 +0100
@@ -124,6 +124,10 @@
         m_captureWindow->raise();
 #else
         m_captureWindow->showFullScreen();
+        if (DesktopInfo().waylandDetected()) {
+            m_captureWindow->activateWindow();
+            m_captureWindow->raise();
+        }
 //        m_captureWindow->show(); // For CaptureWidget Debugging under Linux
 #endif
         return m_captureWindow;

@Christian-Klempau
Copy link

What worked for me using KDE and Wayland:

  • installed Flameshot via Flatpak
  • Added the "force Flameshot size" window rule, as explained above BUT with some minor tweaks, like substring matching and removing the repeated "flameshot" in the original description:
  • also, idk if relevant but changed the flatpak permission to this, removing X11:

flameshot_flatseal

flameshot

@kiike
Copy link

kiike commented Jan 11, 2024

I am running into this issue as well, and the workaround suggested above does indeed work. If the window matching is set up too loose, the rules will also apply to the settings dialog, for instance, so I set:

  • window class: exact match with value flameshot flameshot
  • match whole window class enabled
  • window title: exact match with value flameshot (configuration dialog will have Configuration as title, so we want to match just the capture GUI).

As you can see from the screenshot below, these settings work around the issue perfectly, so thanks everyone for your tips!

image

@Haraven
Copy link

Haraven commented Jan 26, 2024

Just wanted to chime in also, @Lightfire228's and @Christian-Klempau combined suggestions fixed the issue for me.

Thanks very much!

@insunaa
Copy link

insunaa commented Feb 4, 2024

image

I have 2 unequal monitors and these settings in kde plasma have made it work for me without needing to move around my monitors to meet some weird 0,0 standard

@cbbh0101
Copy link

Based on a mixture of settings from @insunaa and @kiike, I am able to make both the main capturing window and the configuration window behave normally on my laptop.

  • OS: Debian 12
  • KDE Plasma Version: 5.27.5
  • KDE Frameworks Version: 5.103.0
  • Qt Version: 5.15.8

Window Manager Settings
Window Manager Settings

Display Geometry
2024-02-27_display_geometry

@outloudvi
Copy link

outloudvi commented Feb 29, 2024

Not sure whether the change is about KDE 6, but there's no the "Ignore requested geometry | Force | Yes" option here anymore. This option might have been replaced with "Obey geometry restrictions | False | No", but in my case this option's not needed for Flameshot to recover.

In case that one may want to just directly import the window rule configuration (it doesn't have "Obey geometry restrictions" configured), save it as config.kwinrule and import it thru KDE Settings:

[Flameshot workaround (#2364)]
Description=Flameshot workaround (#2364)
above=true
aboverule=2
fullscreenrule=2
position=0,0
positionrule=2
title=flameshot
titlematch=1
types=1
wmclass=flameshot flameshot
wmclasscomplete=true
wmclassmatch=1

@Lightfire228
Copy link

Not sure whether the change is about KDE 6, but there's no the "Ignore requested geometry | Force | Yes" option here anymore. This option might have been replaced with "Obey geometry restrictions | False | No", but in my case this option's not needed for Flameshot to recover.

This seems to be the case for me as well. Forcing position, fullscreen, and keep above others are still necessary for the aforementioned reasons. Otherwise, the workaround works perfectly in kde 6.0

kwin rules screenshot

image

There still is a noticeable lag before the gui comes up, but oh well

@daveemu
Copy link

daveemu commented Mar 10, 2024

image

I have 2 unequal monitors and these settings in kde plasma have made it work for me without needing to move around my monitors to meet some weird 0,0 standard

This settings perfectly worked for me, after Plasma 6 (and Wayland) upgrade on Arch.

@avindra
Copy link

avindra commented Mar 11, 2024

I'm having multi monitor issues on X11

@P-Storm
Copy link

P-Storm commented Mar 26, 2024

Not sure whether the change is about KDE 6, but there's no the "Ignore requested geometry | Force | Yes" option here anymore. This option might have been replaced with "Obey geometry restrictions | False | No", but in my case this option's not needed for Flameshot to recover.

In case that one may want to just directly import the window rule configuration (it doesn't have "Obey geometry restrictions" configured):

[Flameshot workaround (#2364)]
Description=Flameshot workaround (#2364)
above=true
aboverule=2
fullscreenrule=2
position=0,0
positionrule=2
title=flameshot
titlematch=1
types=1
wmclass=flameshot flameshot
wmclasscomplete=true
wmclassmatch=1

For me the workaround is working on KDE 6. Only thing now is that scaling is a bit wonky, but for the screenshot creation this is fine for me. Of course I want to see this fixed, but time is a thing :)

@guillaumearnx
Copy link

Hi, Working for me with this screen disposition.
Cdlt

flameshot

image

@AkechiShiro
Copy link

AkechiShiro commented Jun 4, 2024

Anyone has any idea of the codepath impacted that is causing this bug ? What do we need to change ? I'm willing to work on a PR and I've got a VM setup just for fixing flameshot issues, as they've been here for too long.

@insunaa
Copy link

insunaa commented Jun 5, 2024

@AkechiShiro The problem isn't flameshot, really. It's that in Wayland windows can't request/demand to be opened at specific coordinates: it's up to the wayland compositor to place the window. On KDE this means kwin decides where the flameshot gui appears. You can use kwin rules like those shown in the issue here to make kwin place the window differently, but there's nothing you can do from within flameshot. I'm not familiar enough with kwin to know if they have some sort of "quirks" ruleset where the devs specify rules for particular applications ahead of time, but if they do that's probably the only place where you can realistically make this change. For other window managers / desktop environments that's again in the power of their compositor and would have to be changed at each place individually. This will NEVER happen with Gnome, so there will never be a full solution to this issue under wayland, unless the by now several year old issue about respecting window placement requests is merged, which I doubt will happen.

@AkechiShiro
Copy link

AkechiShiro commented Jun 5, 2024

Was this problem reported upstream to Wayland in details ? @insunaa

That Flameshot has lots of bugs due to this decision ? And that it is breaking the user experience for everyone moving to Wayland and using Flameshot for screenshots ?

@Cybso
Copy link

Cybso commented Jun 5, 2024

@AkechiShiro The problem isn't flameshot, really. It's that in Wayland windows can't request/demand to be opened at specific coordinates: it's up to the wayland compositor to place the window. On KDE this means kwin decides where the flameshot gui appears. I'm not familiar enough with kwin to know if they have some sort of "quirks" ruleset where the devs specify rules for particular applications ahead of time

Actually, there has to be some sort auf "quirk", since it works with Plasma's "Spectacle". Or does that tool use a completely different approach?

@mmahmoudian
Copy link
Member

mmahmoudian commented Jun 5, 2024

Actually, there has to be some sort auf "quirk", since it works with Plasma's "Spectacle". Or does that tool use a completely different approach?

@Cybso Just to add to the conversation, some DEs have their own private API that have access to certain parts of compositor and window manager that other apps which use the public API don't. The infamous example is Gnome which their own private API gives all sorts of access to their own apps including the Gnome screenshot, but other screenshot tools are given the same level of access. That's why Gnome screenshot tool works smoothly and all other screenshot apps are suffering. I don't remember the KDE Plasma situation, but they might also use some sort of private API as well. That should be checked, so take it with a grain of salt.

Also I myself have now moved to Wayland Plasma and I can reproduce the problem in multi-monitor setup. I tried to see if window rules in Plasma can be configured to improve the situation, but nothing good came out of that.

@mmahmoudian mmahmoudian removed the Upstream There's a problem with upstream code. label Jun 5, 2024
@AkechiShiro
Copy link

@mmahmoudian then a way forward with this issue might be to ask if those API can be used by screenshots open source software and not just by their own private app

What do you think if I open up two issues one from GNOME and one for KDE regarding this issue and link them here ?

@3vi1
Copy link

3vi1 commented Jul 17, 2024

I've got this exact same issue when using Wayland, but trying every variation of the kwin rule above does not workaround the problem for me.

  • nvidia 555.52.04 drivers - RTX 2070 Super
  • flameshot built from current git
  • Plasma 6.2 Dev built from today's source
  • Left Monitor = 2560x1080 (DVI), Right Monitor = 2560x1440 (HDMI)

It makes no difference if I have the left monitor at 0x0 or not... crashes in the same manner. Flameshot works great with X11, and Spectacle works fine with Wayland.

@insunaa
Copy link

insunaa commented Jul 18, 2024

@3vi1 you tried it with the "Initial Placement: Force: Random" selector? That's what did the trick for me. Tho granted I'm on kde 6.1.2
image

@3vi1
Copy link

3vi1 commented Jul 18, 2024

@3vi1 you tried it with the "Initial Placement: Force: Random" selector? That's what did the trick for me.

Yes. I tried that, and even tried to start the app multiple times just in case the "Random" location was somehow bad - but it didn't appear to make any difference. Thank you for the suggestion though.

@Wolfhound905
Copy link

I am running into this exact issue. Whe prefixing the flameshot gui with QT_QPA_PLATFORM=xcb it shows my screens properly.

@Supermarcel10
Copy link

Issues

  • The GUI is very laggy.
  • The GUI only shows up after 2-3 seconds of activating a screenshot.
  • The scaling of the GUI seems to be heavily zoomed in (cursor is a lot larger than normal)

Notes

  • Running flameshot as sudo correctly shows across two screens, albeit the content of the screens is black.
    • Output of sudo echo $QT_QPA_PLATFORM is blank.
    • Output of sudo echo $XDG_SESSION_TYPE is wayland.
    • This makes it possible that flameshot utilises the QT_QPA_PLATFORM variable (haven't checked any underlying code, so take that with a grain of salt) to determine something, and would imply it's not an issue related to permissions.
  • As @Wolfhound905 mentioned, running QT_QPA_PLATFORM=xcb flameshot gui seems to work.
    • Flameshot spans my screens properly
    • Scaling seems to be correct
    • Lag is significantly better
    • As a side effect I cannot copy to clipboard, but that's somewhat to be expected.

Configuration

OS: NixOS 24.11.19700101.dirty (Vicuna) x86_64
DE: KDE Plasma (plasmashell 6.1.5)
WM: KWin (Wayland) (wayland-scanner 1.23.1)

Kernel: Linux 6.6.50

Screen configuration:

$ kscreen-doctor -o
Output: 1 DP-1
        enabled
        connected
        priority 2
        DisplayPort
        Modes:  0:2560x1440@60!  1:2560x1440@165  2:2560x1440@144*  3:2560x1440@120  4:1920x1080@165  5:1920x1080@120  6:1920x1080@60  7:1920x1080@60  8:1920x1080@50  9:1680x1050@60  10:1280x1024@75  11:1280x1024@60  12:1440x900@60  13:1280x960@60  14:1152x864@75  15:1280x720@120  16:1280x720@100  17:1280x720@60  18:1280x720@60  19:1280x720@50  20:1440x576@50  21:1024x768@75  22:1024x768@70  23:1024x768@60  24:1440x480@60  25:800x600@75  26:800x600@72  27:800x600@60  28:800x600@56  29:720x576@50  30:720x480@60  31:640x480@75  32:640x480@73  33:640x480@60 
        Geometry: 0,0 1440x2560
        Scale: 1
        Rotation: 8
        Overscan: 0
        Vrr: Automatic
        RgbRange: unknown
        HDR: disabled
        Wide Color Gamut: disabled
        ICC profile: none
        Color profile source: EDID
Output: 2 DP-2
        enabled
        connected
        priority 1
        DisplayPort
        Modes:  0:3840x2160@60!  1:3840x2160@144*  2:3840x2160@120  3:3840x2160@120  4:3840x2160@100  5:3840x2160@60  6:3840x2160@50  7:3840x2160@30  8:3840x2160@25  9:3840x2160@24  10:2560x1440@144  11:2560x1440@120  12:2560x1440@60  13:1920x1200@60  14:1920x1080@144  15:1920x1080@120  16:1920x1080@120  17:1920x1080@100  18:1920x1080@60  19:1920x1080@60  20:1920x1080@50  21:1920x1080@30  22:1920x1080@25  23:1600x1200@60  24:1680x1050@60  25:1600x900@60  26:1280x1024@75  27:1280x1024@60  28:1280x800@60  29:1152x864@75  30:1280x720@60  31:1024x768@75  32:1024x768@60  33:800x600@75  34:800x600@60  35:720x576@50  36:720x480@60  37:640x480@75  38:640x480@60  39:640x480@60 
        Geometry: 1440,416 3072x1728
        Scale: 1.25
        Rotation: 1
        Overscan: 0
        Vrr: Automatic
        RgbRange: unknown
        HDR: disabled
        Wide Color Gamut: disabled
        ICC profile: none
        Color profile source: sRGB

Example Image

The following is shown in my primary screen:
image

@mmahmoudian
Copy link
Member

@AkechiShiro

@mmahmoudian then a way forward with this issue might be to ask if those API can be used by screenshots open source software and not just by their own private app

What do you think if I open up two issues one from GNOME and one for KDE regarding this issue and link them here ?

Please checkout the links in this part of our documentation:

https://flameshot.org/docs/guide/wayland-help/#i-am-asked-to-share-my-screen-every-time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug It's a bug Wayland Wayland specific issues
Projects
None yet
Development

No branches or pull requests