Hyprland support? - Githubissues

quantenzitrone commented 2 years ago

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

install hyprland
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

RandomLegend commented 10 months ago

i don't exactly know what you mean with the grid option?

jack9603301 commented 10 months ago

i don't exactly know what you mean with the grid option?

Please provide an output log similar to this

RandomLegend commented 10 months ago

To clarify:

I have a dual monitor setup, main one: 3440x1440, second one: 1080x1920 (portrait mode)

If i start flameshot gui from the second display, it works properly and let's me shot the entire screen.

If i start flameshot gui from the main display, it actually squeezes in the second screen and cuts off the available area from the main display.

This image i here is what i see when i start flameshot gui from the MAIN display.

This is the kind of output you asked for (started from my main display)

This is using the AUR git version of flameshot. And i currently do NOT have any environment var set to trick flameshot into thinking it's on sway.

jack9603301 commented 10 months ago

@RandomLegend It seems to be due to the different resolutions of the two monitors, as Flameshot seems to place all screenshots of the screen captured by Grim on a single monitor I don't know if Grim can choose a specific monitor

It should be noted that the screenshot log above shows that it is using the GRIM backend

RandomLegend commented 10 months ago

I don't know if Grim can choose a specific monitor

You can do grim screen and it will only shoot the focused screen. So it can differentiate the monitors

jack9603301 commented 10 months ago

Okay, when I have time, I will check and submit a PR

RandomLegend commented 10 months ago

Thank you so much!

jack9603301 commented 10 months ago

Thank you so much!

I couldn't find the screen parameter from Grim's help. Can you provide some explanation? It is best to include links from official sources

mrwsl commented 10 months ago

@jack9603301 I think you are looking for the -o option - see on sourcehut.

jack9603301 commented 10 months ago

@jack9603301 I think you are looking for the -o option - see on sourcehut.

I found an interesting alternative solution in your link that using Grim+Slurp seems to replace some of the features of Flameshot, however, it does not support secondary editing

RandomLegend commented 10 months ago

Thank you so much!

I couldn't find the screen parameter from Grim's help. Can you provide some explanation? It is best to include links from official sources

Yeah it's not listed in the help. But if you do grim screen you will find a screenshot of your focused display in either your home dir or pictures

jack9603301 commented 10 months ago

Thank you so much!

I couldn't find the screen parameter from Grim's help. Can you provide some explanation? It is best to include links from official sources

Yeah it's not listed in the help. But if you do grim screen you will find a screenshot of your focused display in either your home dir or pictures

Halfway through the implementation, I originally planned to use wlr_randr to obtain the current situation, but suddenly thought that it would not work - it is impossible for us to know what the current display is? Unless flameshot passes it over!

You can try using grim+slurp instead

mrwsl commented 10 months ago

@jack9603301 To get the current display, you could use hyprctl:

$ hyprctl -j activeworkspace
{
    "id": 1,
    "name": "1",
    "monitor": "DP-2",
    "monitorID": 1,
    "windows": 2,
    "hasfullscreen": false,
    "lastwindow": "0x57d62afd69a0",
    "lastwindowtitle": "hyprctl -j activeworkspace"
}

jack9603301 commented 10 months ago

@jack9603301 To get the current display, you could use hyprctl:

$ hyprctl -j activeworkspace
{
    "id": 1,
    "name": "1",
    "monitor": "DP-2",
    "monitorID": 1,
    "windows": 2,
    "hasfullscreen": false,
    "lastwindow": "0x57d62afd69a0",
    "lastwindowtitle": "hyprctl -j activeworkspace"
}

We cannot assume that all Wayland users will choose Hyperland, as there is more than one wlroots based synthesizer

Its-Haze commented 10 months ago

This is still a problem for me. I have tried the suggested solutions above, but they simply do not work for me..

lukeramljak commented 9 months ago

These window rules work for me in Hyprland. You might need to play around with the monitor number. 0 didn't work for me, 1 did.

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

EDIT: monitor 1 is my secondary monitor but if I screenshot on my main monitor, the cursor always moves to monitor 1. Haven't found a fix yet.

Andy3153 commented 9 months ago

I'm only getting this :

$ flameshot gui
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: error: Unable to capture screen
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
flameshot: info: Screenshot aborted.

Doesn't even matter if I set the envvars to pretend I'm on Sway, the main error is the same

$ env XDG_CURRENT_DESKTOP=sway XDG_SESSION_DESKTOP=sway QT_QPA_PLATFORM=wayland flameshot gui
flameshot: error: Unable to capture screen
flameshot: error: Unable to capture screen
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
flameshot: info: Screenshot aborted.

mmahmoudian commented 9 months ago

@Andy3153 I don't know which os you are using but hyprland is already a recognized WM:

https://github.com/flameshot-org/flameshot/blob/3d21e4967b68e9ce80fb2238857aa1bf12c7b905/src/utils/desktopinfo.h#L20

How did you install Flameshot? Which version?

Awoodwhale commented 8 months ago

I have two monitors, left is 1920x1080, right is 2560x1440.

These rules work for me in Hyprland

monitor=eDP-1, preferred, 0x0, 1
monitor=DP-1, preferred, 1920x0, 1

windowrule=fakefullscreen, flameshot
windowrule=float,flameshot
windowrule=monitor 0,flameshot
windowrule=move 0 0,flameshot
windowrule=workspace 0,flameshot
windowrule=stayfocused,flameshot

bind = CTRL+$ALT, A, exec, QT_QPA_PLATFORM=xcb flameshot gui -r | wl-copy

I can successfully use flameshot anywhere i want, just like:

left monitor:

right monitor:

both:

flameshot

I hope my configs is helpful...

Lutmak commented 8 months ago

These window rules work for me in Hyprland. You might need to play around with the monitor number. 0 didn't work for me, 1 did.
windowrule = nofullscreenrequest,flameshot
windowrule = float,flameshot
windowrule = monitor 1,flameshot
windowrule = move 0 0,flameshot
windowrule = noanim,flameshot
EDIT: monitor 1 is my secondary monitor but if I screenshot on my main monitor, the cursor always moves to monitor 1. Haven't found a fix yet.

For those using hyprland-git and flameshot-git from the AUR this config no longer works for some reason, i updated it to windowrulev2 and it works now for me (change the last move to your monitor config):

windowrulev2=noanim,class:^(flameshot)$
windowrulev2=float,class:^(flameshot)$
windowrulev2=fakefullscreen,class:^(flameshot)$
windowrulev2=monitor 0,class:^(flameshot)$
windowrulev2=move 0 -195,class:^(flameshot)$

RandomLegend commented 8 months ago

With those new windowrules it places itself perfect, but i still have the issue that pasted images are only rendered 30% and the rest is missing.

Now i can't even properly paste them. For example pasting the image into a chat on signal, shows the image in the text preview but i can't send it.

Pasting it into Dolphin asks me how i want to name it and it detects that it's an image, but pressing OK does nothing

deron-dev commented 8 months ago

Since this is working, the issue seems to be related to display scaling. My displays are scaled to 1.5x, and the preview flameshot shows is a zoomed portion of the screens.

Maybe related to #564 ?

justinrubek commented 7 months ago

Neither of these windowrules work for me. I'm sure it's partly because I don't understand something. I've tried changing the monitor number, but no dice. I'm not sure what to change for the last move value.

My monitor config looks similar to the first post:

monitor = [
  "HDMI-A-1, 2560x1440@100, 1920x0, auto"
  "DP-1, 1920x1080@144, 0x0, auto"
];

Could it be that I can't use auto for scaling?

I also see something about changing the last value for the move in the windowrule. How do I determine what value to use?

Octelly commented 7 months ago

@justinrubek I've been using Flameshot on Hyprland for a while now. Here's the relevant part of my config:

# Flameshot rules
## important
windowrulev2=nofullscreenrequest,class:flameshot
windowrulev2=float,class:flameshot
windowrulev2=monitor 0,class:flameshot
windowrulev2=move 0 0,class:flameshot
## visual
windowrulev2=noanim,class:flameshot
windowrulev2=noborder,class:flameshot
windowrulev2=rounding 0,class:flameshot

Here are my monitor settings for reference:

monitor=DP-2,1920x1080@60,0x0,1
monitor=DP-3,1920x1080@165,1920x0,1,vrr,1
monitor=HDMI-A-1,1920x1080@60,3840x0,1,transform,1

edit: It can be very janky in combination with fullscreen clients and workspace switching, but it does the job. Official support through compositor layers would be ideal.

Its-Haze commented 6 months ago

All i am getting is this:

Installed:
  flameshot-12.1.0-4.fc39.x86_64                        qtlockedfile-qt5-2.4-39.20150629git5a07df5.fc39.x86_64                        qtsingleapplication-qt5-2.6.1-46.fc39.x86_64                       

Complete!

$flameshot gui                                                                                                                                                     ✔  11s   11:06:49 AM  

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: error: Unable to capture screen
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
flameshot: info: Screenshot aborted.

Im on Fedora. And using hyprland-git-0.40.0^8.git57e76f9-1.fc39.x86_64 with flameshot-12.1.0-4.fc39.x86_64

acheong08 commented 5 months ago

@Its-Haze Seems like the patch hasn't landed in a release yet. @mmahmoudian is there a reason a release hasn't been made in such a long time despite numerous improvements and fixes since?

mmahmoudian commented 5 months ago

@acheong08

@mmahmoudian is there a reason a release hasn't been made in such a long time despite numerous improvements and fixes since?

Yes: time

Any help is more than welcome. Reading the PRs, improving documentations, answering users' issues, helping triage the issues, ...

You can use the nightly build if you want to get those improvements quickly as described on our website:

https://flameshot.org/docs/installation/development-build/

Also AUR (flameshot-git) is always following the HEAD and is managed by us.

Its-Haze commented 5 months ago

@acheong08

@mmahmoudian is there a reason a release hasn't been made in such a long time despite numerous improvements and fixes since?

Yes: time

Any help is more than welcome. Reading the PRs, improving documentations, answering users' issues, helping triage the issues, ...

You can use the nightly build if you want to get those improvements quickly as described on our website:

https://flameshot.org/docs/installation/development-build/

Also AUR (flameshot-git) is always following the HEAD and is managed by us.

The problem is that fedora has a newer version in their repository, than this "nightly build" And there is no nightl build available for fc39..

Do i have to build it from source then?

mmahmoudian commented 5 months ago

The problem is that fedora has a newer version in their repository, than this "nightly build"

How can they have something newer than our latest builds?! What version is there?

Do i have to build it from source then?

You can always build it yourself. It is very straightforward.

Its-Haze commented 5 months ago

Built flameshot from source, from the head of master. And it did not crash flameshot right away. But taking screenshots made all my screens turn black, so nothing was able to be screenshotted.

Its-Haze commented 5 months ago

Dnf on Fedora 39 can install flameshot-12.1.0-4.fc39

But the nightly build rpm package was flameshot-12.1.0-1.fc36

Might not be a difference in version. Not sure what differs between 1 and 4 here

mmahmoudian commented 5 months ago

@Its-Haze

The problem is that fedora has a newer version in their repository, than this "nightly build"

I just checked, Fedora 36 to 40 have v12.1.0:

https://repology.org/project/flameshot/versions

Dnf on Fedora 39 can install flameshot-12.1.0-4.fc39 But the nightly build rpm package was flameshot-12.1.0-1.fc36 Might not be a difference in version. Not sure what differs between 1 and 4 here

That 4 is their internal build version. has nothing to do with Flameshot. Anything after - is irrelevant to our versioning system.

Built flameshot from source, from the head of master. And it did not crash flameshot right away. But taking screenshots made all my screens turn black, so nothing was able to be screenshotted.

Which Desktop Environment or Window Manager are you using?

mmahmoudian commented 5 months ago

@Its-Haze have you tried this:

https://flameshot.org/docs/guide/wayland-help/#can-t-screen-anything-on-wayland-gnome

Its-Haze commented 5 months ago

Im using hyprland. Not gnome

Its-Haze commented 5 months ago

This is the error i'm getting when running ./flameshot gui after building it from source on Fedora, Hyprland.

flameshot: warning: If the USE_WAYLAND_GRIM option is not activated, the dbus protocol will be used. It should be noted that using the dbus protocol under wayland is not recommended. It is recommended to recompile with the USE_WAYLAND_GRIM flag to activate the grim-based general wayland screenshot adapter
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()

The thing that happens is that my all 3 monitors turn black. my waybar is still visible on screen though, so not everything is gone. but mainly my screens. the flameshot gui opens but i cant see what i am going to screenshot, all i see is my mouse moving and i am able to use the differnt keyboard shortcuts to switch

acheong08 commented 5 months ago

Try with cmake -S . -B build -DUSE_WAYLAND_GRIM=true && cmake --build build

For reference, I'm on Hyprland (bf75723f2742973d4820f3f5378dff8c99333660) and it works without that option.

Its-Haze commented 5 months ago

Try with cmake -S . -B build -DUSE_WAYLAND_GRIM=true && cmake --build build

For reference, I'm on Hyprland (bf75723f2742973d4820f3f5378dff8c99333660) and it works without that option.

will try, building now.

Its-Haze commented 5 months ago

Try with cmake -S . -B build -DUSE_WAYLAND_GRIM=true && cmake --build build

For reference, I'm on Hyprland (bf75723f2742973d4820f3f5378dff8c99333660) and it works without that option.

Still the same issue, my screens all turn black and the flameshot gui is not visible.

./flameshot gui

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()

acheong08 commented 5 months ago

Does grim work? This doesn't seem like a flameshot issue. Might want to update Hyprland and make sure portals are alive.

Its-Haze commented 5 months ago

I am currently using grimblast, and swappy.

grimblast --freeze copysave area /tmp/screenshot.png && swappy -f /tmp/screenshot.png
rm /tmp/screenshot.png

And it works flawlessly. So i might just stick with it, but i would prefer to use flameshot.

Its-Haze commented 5 months ago

I found the issue. It was my windowrules for hyprland that messed things up with flameshot.

in .config/hypr/userprefs.conf

I needed to delete/comment out these rows, to make my screens not black out.

windowrulev2=noanim,class:^(flameshot)$
windowrulev2=float,class:^(flameshot)$
windowrulev2=fakefullscreen,class:^(flameshot)$
windowrulev2=monitor 0,class:^(flameshot)$

windowrulev2=move 0 -195,class:^(flameshot)$

Putting this here for people that might have similar rules and end up in the same situation.

svenstaro commented 4 months ago

Shouldn't this issue perhaps be closed? Flameshot now officially supports Wayland in various forms. Probably wayland problems shouldn't all be grouped under this single issue. It might be more helpful to have other more specific issues for specific problems with Wayland.

jack9603301 commented 4 months ago

Sven-Hendrik Haase @.***> [2024-07-05 :04:23]:

Shouldn't this issue perhaps be closed? Flameshot now officially supports Wayland in various forms. Probably wayland problems shouldn't all be grouped under this single issue. It might be more helpful to have other more specific issues for specific problems with Wayland.

I agree, flameshot now fully supports the screenshot function of all WM based on wlroots, through grim

suryanarayanan035 commented 4 months ago

I have two monitors, left is 1920x1080, right is 2560x1440.

These rules work for me in Hyprland
monitor=eDP-1, preferred, 0x0, 1
monitor=DP-1, preferred, 1920x0, 1

windowrule=fakefullscreen, flameshot
windowrule=float,flameshot
windowrule=monitor 0,flameshot
windowrule=move 0 0,flameshot
windowrule=workspace 0,flameshot
windowrule=stayfocused,flameshot

bind = CTRL+$ALT, A, exec, QT_QPA_PLATFORM=xcb flameshot gui -r | wl-copy
I can successfully use flameshot anywhere i want, just like:

left monitor:

right monitor:

both:

I hope my configs is helpful...

This is the one that really worked for me. I use Arch Linux and Hyprland.

anonymous-user commented 4 months ago

Doesn't the QT_QPA_PLATFORM=xcb mean you are running flameshot in xwayland mode?

jack9603301 commented 4 months ago

Doesn't the QT_QPA_PLATFORM=xcb mean you are running flameshot in xwayland mode

Flameshot does not need QT_QPA_PLATFORM=xcb, it can run directly under Wayland. In addition, when the configuration is appropriate, the Wayland environment will automatically use xwayland when the Wayland configuration is invalid

SamuelGogarty commented 3 months ago

I have two monitors, left is 1920x1080, right is 2560x1440. These rules work for me in Hyprland
monitor=eDP-1, preferred, 0x0, 1
monitor=DP-1, preferred, 1920x0, 1

windowrule=fakefullscreen, flameshot
windowrule=float,flameshot
windowrule=monitor 0,flameshot
windowrule=move 0 0,flameshot
windowrule=workspace 0,flameshot
windowrule=stayfocused,flameshot

bind = CTRL+$ALT, A, exec, QT_QPA_PLATFORM=xcb flameshot gui -r | wl-copy
I can successfully use flameshot anywhere i want, just like: left monitor: right monitor: both: I hope my configs is helpful...
This is the one that really worked for me. I use Arch Linux and Hyprland.

fakefullscreen is no longer valid, what should we use in place now?

Andy3153 commented 3 months ago

fakefullscreen is no longer valid, what should we use in place now?

Right from the announcements channel of the Hyprland Discord server, right from Vaxry himself: forgot to mention, fakefullscreen is gone in favor of the new fullscreenstate dispatcher.

Check out the Hyprland Wiki for these things.

SamuelGogarty commented 3 months ago

fakefullscreen is no longer valid, what should we use in place now?

Right from the announcements channel of the Hyprland Discord server, right from Vaxry himself: forgot to mention, fakefullscreen is gone in favor of the new fullscreenstate dispatcher.

Check out the Hyprland Wiki for these things.

should this be used in a different fashion? I am not in the discord.

#flameshot
windowrule=fullscreenstate, flameshot
windowrule=float,flameshot
windowrule=monitor 1,flameshot
windowrule=move 0 0,flameshot
windowrule=workspace 0,flameshot
windowrule=stayfocused,flameshot

With these rules, flameshot still opens on the wrong screen, and displays the wrong window on the wrong screen, doesn't pan across all monitors, etc.

alba4k commented 3 months ago

@SamuelGogarty consider removing the workspace 0 windowrule and replace monitor 1 with the minitor name or port (e.g. DP-1)

also, maybe add something like

windowrule = size 3840 1200, flameshot

to make sure the window spans across everything (obv 3840 and 1200 may be different for your setup. if in doubt just throw two 10000 in there)

you might also want to use windowrulev2

windowrulev2 = RULE, class:(flameshot), title:(flameshot)

to make sure other flameshot windows (like the configuration) remain unaffected

unrelated, but in my setup I am also using these rules

rounding 0
noborder

flameshot-org / flameshot

Hyprland support? #2978

Flameshot Version

Installation Type

Operating System type and version

Description

Steps to reproduce

Screenshots or screen recordings

System Information