Hyprland support?

[quantenzitrone]

Flameshot Version

Flameshot v12.1.0 (-) Compiled with Qt 5.15.7

Installation Type

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

Operating System type and version

NixOS 22.11pre425156.872fceeed60 (Raccoon)

Description

Flameshot doesn't work on Hyprland (a wayland compositor). With $XDG_CURRENT_DESKTOP set to the default "Hyprland", flameshot says:

~ $ echo $XDG_CURRENT_DESKTOP
Hyprland
~ $ flameshot &
[1] 127966
kf.windowsystem: Could not find any platform plugin
~ $ flameshot full
flameshot: error: Unable to detect desktop environment (GNOME? KDE? Sway? ...)
flameshot: error: Hint: try setting the XDG_CURRENT_DESKTOP environment variable.
flameshot: error: Unable to capture screen
flameshot: info: Screenshot aborted.
~ $

However, when I set the environment variable $XDG_CURRENT_DESKTOP to Sway flameshot just doesn't do anything.

~ $ XDG_CURRENT_DESKTOP=Sway
~ $ echo $XDG_CURRENT_DESKTOP
Sway
~ $ flameshot &
[1] 128100
kf.windowsystem: Could not find any platform plugin
~ $ time flameshot full
^C

real    0m16.907s
user    0m0.145s
sys 0m0.074s
~ $

Steps to reproduce

1. install hyprland
2. run flameshot gui

Screenshots or screen recordings

No response

System Information

~ $ inxi --width 80 --system --graphics
System:
  Host: nix Kernel: 6.0.7-zen1 x86_64 bits: 64 Desktop: N/A
  Distro: NixOS 22.11 (Raccoon)
Graphics:
  Message: No device data found.
  Device-1: DGEMU019I992XE HP Wide Vision HD Camera type: USB driver: uvcvideo
  Display: wayland server: X.Org 1.22.1.3 driver: loaded: N/A
  resolution: 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel HD Graphics 630 (KBL GT2) v: 4.6 Mesa 22.2.2

~ $ wlr-randr                                                                                          ✘ 1
eDP-1 "Chimei Innolux Corporation 0x15D3 (eDP-1)"
  Physical size: 340x190 mm
  Enabled: yes
  Modes:
    1920x1080 px, 40.004002 Hz
    1920x1080 px, 60.007999 Hz (preferred, current)
  Position: 0,0
  Transform: normal
  Scale: 1.000000

~ $ lspci | grep -i 'vga\|3d\|2d'
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04)
01:00.0 VGA compatible controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] (rev a1)

~ $ lshw -class display
WARNING: you should run this program as super-user.
  *-display
       physical id: 0
       bus info: pci@0000:01:00.0
       version: a1
       width: 64 bits
       clock: 33MHz
       capabilities: bus_master cap_list rom
       configuration: driver=nvidia latency=0
       resources: irq:141 memory:b3000000-b3ffffff memory:a0000000-afffffff memory:b0000000-b1ffffff ioport:4000(size=128) memory:b4080000-b40fffff
  *-display
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 04
       width: 64 bits
       clock: 33MHz
       capabilities: bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:139 memory:b2000000-b2ffffff memory:c0000000-cfffffff ioport:5000(size=64) memory:c0000-dffff
WARNING: output may be incomplete or inaccurate, you should run this program as super-user.

~ $ uname -a
Linux nix 6.0.7-zen1 #1-NixOS ZEN SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980 x86_64 GNU/Linux

[mmahmoudian]

@emrakyz Thanks for the testing and the info. the #3059 will be merged as soon as another dev can also review the code. There are some parts that are slightly out of my league (e.g this part), and also my main responsibility is triage, so I cannot merge it myself.

[emrakyz]

Now I got only these problems left (These problems also happened before the two problems fixed):

• After running flameshot gui, the user interface looks a little bit weid, sometimes it gets inside the selected area.
• After selecting a tool, for example the numbering tool; then it distorts the image while I am moving the mouse and it does not return to its normal state. (Can provide video if needed)

@mmahmoudian What do you think about these? Expected for now?

[mmahmoudian]

@emrakyz those do not seem to be related to hyprland. I have not experienced them myself either. Perhaps separate bug report report should be created for each. In the meanwhile, can you provide a shortvideo demoing the second one, and when the first one happens, also take a screenshot of that (you can use flameshot to screenshot flameshot)

[leifmadsen]

@mmahmoudian Update after four months. Using Linux 6.2.9 kernel; latest git versions of Hyprland, xdg-desktop-portal-hyprland, wlroots, wayland, wayland-protocols, wayland-scanners, grim and slurp. I also have latest versions of qt5 and qt6. I enabled use-wayland-grim.

Same issue here on Fedora 38 + swaywm + compiled flameshot with -DUSE_WAYLAND_GRIM=true. Looks exactly the same as this video.

Edit: looks like there is an open PR I could patch and try with. Will also read through the rest here, but as the code stands today, I can confirm the very slow screen selection. FWIW I'm using HiDPI monitor with scaling factor 1.3 in swaywm config via output configuration.

[mmahmoudian]

@leifmadsen Just for the sake of curiosity, would it be possible for you to test with display scaling factor = 1 with or without that patch? I'm curious to know if that has any significant effect.

[leifmadsen]

@leifmadsen Just for the sake of curiosity, would it be possible for you to test with display scaling factor = 1 with or without that patch? I'm curious to know if that has any significant effect.

I'd say it's a bit faster, but still quite laggy. Let me know if there is anything else you'd like me to test.

[alba4k]

The issues I'm having with (built using the AUR flameshot-git PKGBUILD) are:

• super slow responsiveness when running flameshot-gui
• only seems to see my first screen
• only allows screenshots of a single screen
• the controls are stuck at the window corner (pic)
• the tools sidebar doesnt appear when right-clicking and selecting the color wheel

[herbiejhopkins]

Also had the issue of not being able to screenshot on first screen. This seems to be due to the screenshot overlay going fullscreen on one monitor even though it's captured an image spanning whole viewport. This is my quick hack to solve this:

#prevent flameshot from requesting fullscreen
windowrulev2 = nofullscreenrequest,class:^(flameshot)$,title:^(flameshot)

#set flameshot to floating
windowrulev2 = float,class:^(flameshot)$,title:^(flameshot)

#set flameshots position to top left of my left screen and set the size so that it spans whole viewport (you'll need to adjust the monitor and size as appropriate for your display set up)
windowrulev2 = monitor DP-1,class:^(flameshot)$,title:^(flameshot)
windowrulev2 = move 0 0,class:^(flameshot)$,title:^(flameshot)
windowrulev2 = size 6000 1440,class:^(flameshot)$,title:^(flameshot)

[ardishko]

@herbiejhopkins I made some changes to the hyprland wiki a few days prior mentioning this.

Also my fix was to use the flameshot-git package from the AUR and to compile #3059

I have exec-once=/usr/bin/flameshot and I have Print bound to flameshot gui which works fine.

[emrakyz]

@mmahmoudian

The most recent trial after a long time with Hyprland on Linux 6.4.3:

Using latest versions on every dependency:

git clone https://github.com/flameshot-org/flameshot.git cd flameshot git fetch origin pull/3059/head:pr_3059 git checkout pr_3059 mkdir build
rm -rf ./external/singleapplication cd build && cmake .. -DUSE_WAYLAND_CLIPBOARD=true -DUSE_WAYLAND_GRIM=true -DUSE_EXTERNAL_SINGLEAPPLICATION=1 -DENABLE_CACHE=0 make -j$(nproc)

• The mentioned PR fixes the lagging issue.
• env QT_SCREEN_SCALE_FACTORS="0.5" fixes the scaling issue if you use 2x scaling.
• With "flameshot gui", I see the screenshot window (my fullscreen), I select a location then problems start:

1. For example when I move my mouse, artifacts and screen tearing starts to appear. This doesn't carry over to the saved screenshot. It only occurs "during" selection and processing period and it doesn't look good.
2. Can't copy the screenshot, or use some functions such as "pinning". It basically kills the flameshot without any errors.

The output I see on the terminal is below: 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()

[alba4k]

To copy the screenshot, you may need wl-clip-persist, or alternatively have flameshot running as a daemon to keep your copied images.

As for artifacts, I am also getting a lot of them, but in the opposite direction: the preview looks fine, the screenshots however sometimes get weird:

• they get "squashed" horizontally (about 1 in
  sample image

• they are a black and white mess
  sample image

sample image 2


• the resolution goes super-low (about 2-3 in ten)
  sample image

• ...

getting those images took quite a lot of attempts lol (got them using `flameshot full -c

This is what those images are supposed to look like


Also, I'm unable to paste them in most apps (I can, however, in tg desktop). I was only able to paste the images posted here thanks to telegram. I sent them there first, saved those images and posted them here.

Edit: this is related to memory buffer corruption on big images (e.g. big flameshot gui selections or flameshot full). Flameshot (either the shooting instance or the daemon) outputs the following when trying to copy something that's too big

flameshot: info: Capture saved to clipboard.
maximum memory limit (134217728) would be exceeded
cannot create matrix
cannot encode main body
jpc_encode failed
jpc_encode failed

[VPavliashvili]

@emrakyz Hello, thanks for your effort in this thread. I am getting this error

Flameshot predefined color palette large: false git found: /usr/bin/git in version 2.41.0 FLAMESHOT_GIT_HASH: 84acbdaf -- Configuring done (0.1s) CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: QTSINGLEAPPLICATION_LIBRARY linked by target "flameshot" in directory /home/stranger/temp/flameshot/src -- Generating done (0.0s) CMake Generate step failed. Build files cannot be regenerated correctly.

I installed qt5-singleapplication package from aur but still same error. Can you give me any suggestion regarding this issue?

[RandomLegend]

Hey wanted to ping this issue?

Hyprland came a long way and is getting traction really quick nowadays. Might be worth looking into it again.

I installed garuda-hyprland on my laptop and i plan to switch to it with my desktop aswell. Desktop still runs X11 and flameshot is by far the best screenshot tool i have ever used and i would LOVE for it to work properly on hyprland!

[5ouls3dge]

This package is listed on hyprland plugin page here .

I have researched the below, was hoping someone could have a try. (Im still creating a script, no install to test).

IF YOU GET ONE TO WORK PLEASE WRITE UP A DUMMIES GUIDE.

Possible fixes

Option 1: From the plugin site: " To use, make sure you have grim flag enabled" anyone tried or know where to use this flag?

Option 2: XDG_CURRENT_DESKTOP=sway flameshot

of add this to your hyprland.conf

env = XDG_CURRENT_DESKTOP,sway

Option 3:

It should work if you use flameshot-git from the AUR however it's recommended compiling it yourself with the USE_WAYLAND_GRIM flag set.

Option 4: (arcolinux strickes gold?) https://www.youtube.com/watch?v=skHFa0rPZFk https://github.com/arcolinux/arcolinux-wayland-app-hooks

[RandomLegend]

@5ouls3dge

I think Option 1 and Option 3 are the same. I compiled flameshot from source with the USE_WAYLAND_GRIM flag and it definitely changed the behavior of the program. Prior to that flag it didn't even start regardless of what env i'd set.

With the special build flag i can now actually start it, the GUI spans across the whole display as intendet but after a screenshot is taken the output file is not rendered completely. It's just a strip at the top that is rendered out, the rest is transparent.

[erikdubois]

We are grateful that you have created this application and keep maintaining it. Some feedback on the use of Flameshot on Arch Linux - ArcoLinux - how to overcome things - workflow

https://youtu.be/lwK-3_aLqiY

One issue that is still open for me as a two screen user is that the buttons are gone IF you select the whole screen. I can not add text, drawings to a full screen as a result.

Arch Linux versions

The maintainer on the AUR has added the DUSE_WAYLAND_GRIM= true to his pkgbuild. So no need to add it anymore. I created my own package in the past with that setting.

[5ouls3dge]

@RandomLegend - Did option 4 do anything? Was hoping the dev at arcoLinux fixed it. Its arch based.

@erikdubois - can you give more details on your setup. Certainly which package you installed and its version. Thank you.

I did find in arch extra a compiled: x86_64 Extra flameshot 12.1.0-3 Powerful yet simple to use screenshot software 2023-10-01

The version in Aur is git: flameshot-git r1938.fa29bcb4-1 38 0.46 Powerful yet simple to use screenshot software mehrad 2023-11-10 14:16 (UTC)

I can see in your screen shot flameshot-git is being used, i thought that pulls direct?

Was also thinking it would be important to have correct nvidia drivers setup so, those who get it working can share info on that also.

Thank you both

[RandomLegend]

@5ouls3dge Option 4, as far as i understood, simply adds env = XDG_CURRENT_DESKTOP,sway so it's basically Option 2.

But interestingly enough, i just completely uninstalled flameshot from my system, removed the config folder for it and purge my self compiled version of it.

Now i just installed the AUR version of flameshot-git and it now works perfectly fine.

EDIT: sorry, not perfectly fine actually. I have a dual monitor setup and one of them is in portrait mode. If i take a screenshot with flameshot it moves my main monitor down by the difference in "height" between it's upper edge and the edge of my portrait one on the left... so basically i can't take screenshots of the bottom third of my main monitor.

[5ouls3dge]

@5ouls3dge Option 4, as far as i understood, simply adds env = XDG_CURRENT_DESKTOP,sway so it's basically Option 2.

But interestingly enough, i just completely uninstalled flameshot from my system, removed the config folder for it and purge my self compiled version of it.

Now i just installed the AUR version of flameshot-git and it now works perfectly fine.

@RandomLegend Perfect thank you. will update script with git version from AUR.

@erikdubois has just posted the same issue with dual monitor (couple of posts up). I have the same setup also, so will let you know tomorrow.

[RandomLegend]

okay so this is what it looks like and i just realized that my description was wrong. It actually takes in the window on my second portrait monitor INTO the screenshot area and then moves the ones on my main monitor down accordingly.

Interestingly enough, it doesn't reach the bottom end on either of them. So every window is cut off at the bottom, the ones on my main monitor are cut off even more than the other.

[5ouls3dge]

Does it do the same if you take the screen out of portrait mode?

[RandomLegend]

Interesting, no it doesn't... then it stays focused inside that specific monitor and actually let's me take the whole screen...

[5ouls3dge]

At a guess, it maybe outside its range of resolution. Will check the source code.

[RandomLegend]

my main monitor is 3440x1440 the portrait one is 1080x1920

[RandomLegend]

But on X11 it flameshot worked with that high resolution no prob

[RandomLegend]

So if i do flameshot screen -c from the terminal on my main monitor it also slips in the second one... so yeah it get's confused about the monitors i guess

[5ouls3dge]

Was looking at the code, this maybe an issue with grim? you should have grim installed worth checking if Grim outputs the same.

[RandomLegend]

I do have grim installed but grim doesn't have an interface like flameshot does.

I am using https://github.com/prasanthrangan/hyprdots and they implemented a script to use grimblast to draw the area. And there everything works fine

[5ouls3dge]

You should be able to use Grim in terminal to see if the bug is there or in flameshot.

I found this so far in the code will look deeper. But it does have the option of "Capture a screenshot of the specified monitor". so maybe 2 hotkey for screenshot of each display separate as a workaround.

CommandArgument fullArgument(
      QStringLiteral("full"),
      QObject::tr("Capture screenshot of all monitors at the same time."));
    CommandArgument launcherArgument(QStringLiteral("launcher"),
                                     QObject::tr("Open the capture launcher."));
    CommandArgument guiArgument(
      QStringLiteral("gui"),
      QObject::tr("Start a manual capture in GUI mode."));
    CommandArgument configArgument(QStringLiteral("config"),
                                   QObject::tr("Configure") + " flameshot.");
    CommandArgument screenArgument(
      QStringLiteral("screen"),
      QObject::tr("Capture a screenshot of the specified monitor."));

[RandomLegend]

Yeah so using grim in the terminal simply puts a screenshot of both of my monitors (perfect though) into my pictures folder.

So it's not grim, that much i can say.

[5ouls3dge]

Then use grim for now. As your not using the advance gui features of flameshot for this task so let grim do the work till its resolved. Confirm these findings in a new Issue for the dev. i will have a look to..

Grim is under the hood so for now add hotkey for this to Grim instead eg: from https://github.com/emersion/grim Capture a screenshot of the specified monitor grim -o DP-1

Grab a screenshot from the focused monitor under Sway, using swaymsg and jq: grim -o $(swaymsg -t get_outputs | jq -r '.[] | select(.focused) | .name')

[RandomLegend]

i am using grimblast with the script that provides me with a nearly as good as flameshot gui so no issues there.

It's just that i always preferred flameshot as it is the superior tool imo.

I will be waiting :-) everytime i see it in my update list i'll check

[5ouls3dge]

OPen a new issue, this issue needs closing i think.

[RandomLegend]

Yeah you're right

[erikdubois]

@5ouls3dge

Video was made on ArcoLinux/Arch Linux/ Flameshot-git from AUR is always on your last commit on your github. No matter what the number says on the AUR. There is no Nvidia anywhere near. Exec line in the .desktop file is unchanged - just /usr/bin/flameshot Grim is installed.

[mmahmoudian]

@erikdubois

The maintainer on the AUR has added the DUSE_WAYLAND_GRIM= true to his pkgbuild. So no need to add it anymore. I created my own package in the past with that setting.

The AUR is maintained by us. It us something that the devs use in daily basis to find bugs or usage issues. Generally it is stable unless we have this type of issue that a dependency is by mistake missing from the PKGBUILD 😅

Thanks for using Flameshot and providing your feedback.

[erikdubois]

I suggest we close this and open a new issue just about Hyprland and dual screen issue...

[alba4k]

rather than that, clipboard management being broken

[erikdubois]

Is clipboard management broken? on what system is it broken.

do you mean this as it works on Hyprland

[alba4k]

@erikdubois

https://github.com/flameshot-org/flameshot/issues/2978#issuecomment-1640901815

it's probably a qt wayland issue tho

[jack9603301]

I am the developer of the grid screenshot adapter for Flameshot. Please note that if you are using the USE WAYLAND GRIM, flameshot will always obtain screenshots from Grim - Grim obtains screenshots directly from the wlroots screenshot protocol, so it is available for wlroots based on support

You can output the processed image in raw format (using the flameshot parameter), and then copy it through Wayland's clipboard management component, or save it to a file

[jack9603301]

Also, if you use hyprland, and compile it from source, XDG_CURRENT_DESKTOP now supports Hyprland, so you don't need to trick it

[alba4k]

You can output the processed image in raw format (using the flameshot parameter), and then copy it through Wayland's clipboard management component [...].

@jack9603301

That could be interesting, how would I do that? I suppose using flameshot [smth] gui | wl-copy? what is that something though?

[jack9603301]

You can output the processed image in raw format (using the flameshot parameter), and then copy it through Wayland's clipboard management component [...].

@jack9603301

That could be interesting, how would I do that? I suppose using flameshot [smth] gui | wl-copy? what is that something though?

bind = $mainMod + SHIFT, Print, exec, flameshot gui -r | wl-copy

[RandomLegend]

Also, if you use hyprland, and compile it from source, XDG_CURRENT_DESKTOP now supports Hyprland, so you don't need to trick it

I am on hyprland and use the AUR git version. Does someone else had documented the problem that if started from one particular screen it pulls in the windows from the other screen and cuts off the initial screen content?

If i do flameshot full -c it captures the whole main screen properly (and also takes in the second screen as wanted) but if i do flameshot screen -c it does'nt properly take the full main screen but rather cuts it off at roughly 75% right and bottom

[jack9603301]

Is this happening after calling grid or after calling the original screenshot backend?

[RandomLegend]

i don't know how i could check that.

all i do is either run flameshot gui, flameshot screen or start it via the tray i con.

If i use grim screen it properly catches the screen i am on. grimblast (which i primarily use to interact with grim) also properly catches the screen i am on.

[jack9603301]

emm, this is strange, did you use USE_WAYLAND_GRIM to compile?

[RandomLegend]

i am using the AUR git version but i also tried the compiled version with USE_WAYLAND_GRIM, the compiled version couldn't even start unless i'd trick it with the sway env

[jack9603301]

i am using the AUR git version but i also tried the compiled version with USE_WAYLAND_GRIM, the compiled version couldn't even start unless i'd trick it with the sway env

When you compile and overwrite the grid option yourself. What information does it output?