"qt.qpa.wayland: Wayland does not support QWindow::requestActivate()" on Sway.

[raidenovich]

Flameshot Version

flameshot 12.1.0-1 from the community repo

Installation Type

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

Operating System type and version

Arch Linux 6.0.11.arch1-1

Description

whenever I copy or save my image, I get nothing. If I try to copy it to discord I get an unfinished render of the image which in turn doesnt load and ends up as a failed upload.

example: https://cdn.discordapp.com/attachments/922926392511979551/1051159400397676624/image.png

Steps to reproduce

1. on sway, run "flameshot gui" from a terminal
2. try to copy it
3. then the error should show up in the terminal.

Screenshots or screen recordings

https://cdn.discordapp.com/attachments/922926392511979551/1051159400397676624/image.png

System Information

OS specifications: Arch Linux 6.0.11.arch1-1 Display configuration: output DP-2 { background ~/Pictures/9aa94c65-3724-4595-b31e-e5bf132c1a5c.png fill mode 2560x1440@143.856003Hz } output HDMI-A-1 { background ~/Pictures/6021c2ef-750f-4d56-b521-2b19741122e4.png fill resolution 1920x1080

}

WM: Sway Display Server: Wayland

[raidenovich]

this might be because I don't have DBus working on sway but I'm not sure if that has any relevance

[jack9603301]

I'm a little tired of this weird dbus method of capturing screenshots, and I might implement a generic wayland adapter based on grim if possible

[raidenovich]

That would be great. Grim is already required for this stuff so...

[jack9603301]

I can't imagine how long this bad screenshot method has lasted at flameshot. Almost every time flameshot is installed at wayland, it takes a lot of time to configure the desktop portal, and it's hard for me to imagine who actually uses this method to solve the wayland screenshot problem

[raidenovich]

I'll try to get DBus working but until then I'm kinda stuck without a screenshot tool.

[jack9603301]

On my gentoo+hyprland, there have been errors since installation, installing the desktop agent took me a lot of time to get it to work, software shouldn't be a hassle for users, more than one user in the community complained about flameshot having problems with wayland, At the end of the day, it uses a weird logic -- in xcb using qt screenshots, in wayland using dbus protocol screenshots. Oh no, that's a bad idea.

[jack9603301]

I'm an avid user of flameshot, and because it's the best screenshot tool out there, I spend a lot of time getting it to work

[raidenovich]

ShareX is tons nicer than Flameshot but It doesn't support linux, nor is it good on wine.

[jack9603301]

If you can't use flameshot for now, try the fork that has the wayland grim adapter, here's a PR about that work

https://github.com/flameshot-org/flameshot/pull/3018

[raidenovich]

What's the fork's name? Can I get a link to it? The AUR doesnt seem to have it..

[jack9603301]

You can get it through the PR I sent

https://github.com/flameshot-org/flameshot/pull/3018

It should be noted that the opening method suggested in the PR description and the prerequisite for enabling the Grim universal wayland screen capture adapter: you must have at least Grim on your system

[jack9603301]

AUR should not have it as it is what I just finished in

[raidenovich]

I don't really know If I wanna compile manually for that... I'll wait for the merge I guess..

plus I'm not very familiar with cmake generally..

[jack9603301]

Ok, I'm just offering you a solution: If you really need to run flameshot right away, manually compiling my fork would be a start, and USE_WAYLAND_GRIM is off by default, it may take time to wait for the distro to add configuration parameters to it

[raidenovich]

Actually... I commented that while I was outside and reading the page now, compiling wasn't that hard. Will let you know if your fork works for me, thanks for the great work

[raidenovich]

Update: It has compiled but I can't type in

flameshot gui

to take a screenshot, am I supposed to be in a certain directory to execute the command?

[jack9603301]

Update: It has compiled but I can't type in

flameshot gui

to take a screenshot, am I supposed to be in a certain directory to execute the command?

Please provide a screenshot, it is fully tested in my environment, by the way, if grim cannot be executed, it will tell you, please make sure your computer has grim installed

[jack9603301]

example:

[jack9603301]

The USE_WAYLAND_GRIM flag must be turned on. My compilation and installation commands are as follows:

cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DUSE_WAYLAND_GRIM=true
make
sudo make install

[raidenovich]

I don't know why but the issue fixed itself. I can't launch the flameshot daemon though so I'll be opening a new issue for that.

[jack9603301]

I also find it weird, and not sure if it's from the mainline or my modification, I just added the wayland adapter, judging from the code patch, it shouldn't break other functions of flameshot

[raidenovich]

the thing is I don't think I compiled your fork properly, and never got around to recompiling it with the extra flag you put in your comment.

[raidenovich]

Now the image itself is back to rendering only part of the image. Great. This code is greatly inconsistent...

About your fork, I'd greatly appreciate an AUR package or something of the sort, It would be great for lots of users. Heck, I'd even be down to help with the packaging, though I don't know much about it myself.

[raidenovich]

Update again: I think this is a Wayland clipboard issue. It pastes just fine on discord web, doesn't work on regular discord, halfway renders on WALC (a whatsapp client). This is once again a very inconsistent way of taking screenshots, DBus is very unreliable and outdated for this. I can't offer an alternative but if there are any devs on this page, I'd love for jack's code get merged with mainline flameshot :^)

[jack9603301]

I'm leaning toward merging with the official library, since it's just such a small feature, I don't even think I need to submit an RFC proposal

Regarding the clipboard, you can use the -raw parameter in conjunction with wl-copy

[mmahmoudian]

Thanks for going back and forth with this. But few comments:

@jack9603301

more than one user in the community complained about flameshot having problems with wayland, At the end of the day, it uses a weird logic

Flameshot was written for X11 and we are adopting wayland gradually. Wayland itself is in a horrific situation and still is not stable. Many things are getting implemented by day and still has lots of caveats and issues. So we support X11 fully, and we are trying to support Wayland as we go forward.

Also, DBus has lots of merit, it is not used to take screenshot, but rather to pass messages to different components. This is very common practice.

@ardishco-the-great if DBus is missing, you perhaps have to report to the maintainer of Flameshot package of your repo to make it a dependency.

@jack9603301 thanks for your PR (#3018). It is under review

[lbatalha]

I have tested #3018, and it appears to work as designed (no need for xdg-desktop-portal), but the messages in the title of this issue still show up in the terminal, are they unrelated to this issue?

❯ flameshot gui
flameshot: warning: grim's screenshot component is implemented based on wlroots, it may not be used in GNOME or similar desktop environments
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.

Between the grim component warning and the rest, as with any previous commits down to the latest stable release, there is a few seconds (2-3) delay between any UI is shown. Wonder if it has any relation to these issues, somehow proportional to render area.

On X11 the delay was too short to be a bother.

[jack9603301]

@lbatalha Under what circumstances did he appear? Are you using the GRIM Universal Screenshot Adapter?

[jack9603301]

@lbatalha my output:

 ~  
$ flameshot gui                                                                                                                                                                                                                        1679ms  四 13:07
flameshot: warning: grim's screenshot component is implemented based on wlroots, it may not be used in GNOME or similar desktop environments
QLayout: Attempting to add QLayout "" to SidePanelWidget "", which already has a layout
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

[lbatalha]

@jack9603301 When I moved to Wayland in November flameshot gui already had the start delay issue in both stable or git versions, on X11 there were no issues. This is not grim adapter specific, I only tested the grim adapter yesterday as part of debugging in case it was somehow a xdg-desktop-portal-wlr specific problem (also tested the stable release and latest HEAD for both xdg-desktop-portal-wlr and xdg-desktop-portal). All the commits I tested back to, even before the stable release in June, have this issue.

Just noticed also, before the UI appears, one CPU core is maxed out.

This also happens with flameshot launcher, and when I click to take a screenshot, there is another delay and a requestActivate() message. (Though there are no current screen messages like with gui)

flameshot screen simply segfaults immediately flameshot full works correctly, but takes about 7 seconds total to execute, along with the high single core usage.

~/.cache/aurutils/sync/grim-git master*
❯ flameshot screen
zsh: segmentation fault (core dumped)  flameshot screen

~/.cache/aurutils/sync/grim-git master*
❯ flameshot launcher
flameshot: warning: grim's screenshot component is implemented based on wlroots, it may not be used in GNOME or similar desktop environments
flameshot: warning: grim's screenshot component is implemented based on wlroots, it may not be used in GNOME or similar desktop environments
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

~/.cache/aurutils/sync/grim-git master* 1m 20s
❯ flameshot full 
flameshot: warning: grim's screenshot component is implemented based on wlroots, it may not be used in GNOME or similar desktop environments
flameshot: info: Capture saved as /home/lbatalha/screenshots/2023-01-12_10-56.png

I have Xwayland active, but flameshot appears to be running in wayland mode, wonder if there might be some stray X11 code running, because Wayland/Sway has no concept of a primary display at all.

[jack9603301]

@lbatalha It looks like you have a screenshot adapter with USE_WAYLAND_GRIM enabled, which works with all wayland window managers based on wlroot (note that some Wayland window managers that depend on older versions of wlroot may not support the protocol required by grim for the time being)

If you are running a wayland window compositor/manager that depends on wlroot, you can activate two options USE_WAYLAND_GRIM and USE_WAYLAND_CLIPBOARD

Regarding the delay problem, I also have this problem here, I don't know why this problem occurs, it may be related to the processing of other parts of flameshot

flameshot screen

Doesn't cause crashes in my environment

Note, if you run sway, please make sure that the wlroot version supports the screenshot protocol, for the too old wlroot window compositor. The protocol required by grim may not be supported at the moment

[lbatalha]

@jack9603301 yes, I am currently using your patch with the Grim adapter (compiled with -DUSE_WAYLAND_GRIM=1 and -DUSE_WAYLAND_CLIPBOARD=1) I am using sway-git and wlroots-git for some nvidia specific fixes, but even the Arch main repo packages are quite recent and have supported grim for a long long time. (I have been using grim since I moved to Wayland, as a stopgap until flameshot works).

The issues above are probably best discussed in #3039 , I posted here to make sure that qt.qpa.wayland: Wayland does not support QWindow::requestActivate() should still be appearing with the grim adapter, and it seems that is the case.

Besides the issues in #3039 caused by the geometry display and the magnifier, and scaling issues with multiple monitors in #2364 (which I can fix by setting QT scale factor to 1), flameshot is functional with the grim adapter or with xdg-desktop-portal-wlr. The stuff in #3039 does make it completely unusable at the moment, however.

Note: starting the daemon has no effect on the startup delay as far as I can tell.

[Tnology]

Hey, any update on this? I seem to be having this issue when running flameshot gui in the command line, and also, it uses another monitor for my main monitor's capture while my main monitor is still active and the other monitor is blocked.

I'm using Wayland because updating my system upgraded me to KDE 6, which changed me over from x11. This error seems to appear every time I create a new selection with Flameshot. I tried looking at the Flameshot Wayland Help page and neither of the KDE steps worked for me - the two packages listed for the second solution were already installed on my system and reinstalling them using pacman didn't help. Sorry if this isn't the right way to ask, please feel free to correct me in that case so I know for the future.

[J053Fabi0]

For anyone missing the ability to copy to clipboard and freeze the screen when taking a screenshot, I created a Deno script that you can compile and use.

https://gist.github.com/J053Fabi0/84245bf1932ce8e7a8690f21b534681c

[AkechiShiro]

Testing with Sway inside a VM, the way to have a screenshot that works and is copied fully into the clipboard is using QT_QPA_PLATFORM=xcb flameshot && disown without encountering this error.

This probably uses Xwayland and the focus on the flameshot gui (avoid being in fullscreen) is lost so hotkeys do not work.