Bug 490096 - Screenshot (Portal?) breaks
Summary: Screenshot (Portal?) breaks
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: Spectacle
Classification: Applications
Component: General (other bugs)
Version First Reported In: 24.05.2
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: Noah Davis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-11 10:34 UTC by Nico
Modified: 2024-07-12 12:58 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nico 2024-07-11 10:34:51 UTC
SUMMARY
It seems like screenshotting functionality (tested with Spectacle and grim) breaks until I do something I don't remember.

STEPS TO REPRODUCE
Sadly I can't say what to do reproduce but when running

grim -g "$(slurp)"
I got
compositor doesn't support wlr-screencopy-unstable-v1


OBSERVED RESULT
Launching Spectacle failed Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

EXPECTED RESULT
Work normally

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.1.2
KDE Frameworks Version: 6.3.0
Qt Version: 6.8.0
Kernel Version: 6.9.7-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: AMD Radeon RX 6900 XT
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7C37
System Version: 1.0

ADDITIONAL INFORMATION
It seems like whatever I did fixed it for now.
Comment 1 David Edmundson 2024-07-11 10:36:02 UTC
>compositor doesn't support wlr-screencopy-unstable-v1

This is expected, that is a sway only thing and does not involve the portal.

If spectacle fails to launch, please report to spectacle.
Comment 2 Nico 2024-07-11 10:37:32 UTC
Oh then I misinterpreted that, yeah It seems like this always appears but nevertheless here are also additional spectacle logs that might help:

kpipewire_vaapi_logging: VAAPI: Mesa Gallium driver 24.1.3-arch1.1 for AMD Radeon RX 6900 XT (radeonsi, navi21, LLVM 18.1.8, DRM 3.57, 6.9.7-zen1-1-zen) in use for device "/dev/dri/renderD128"
qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0
Comment 3 Noah Davis 2024-07-11 15:28:02 UTC
Regarding the question in the title, there actually is no screenshot portal support right now. Spectacle uses KWin's DBus API for screenshots directly.

You say "this always appears".
Do you mean Spectacle always launches successfully, but it failed to take a screenshot?
Do you mean those two lines always appear in the console output?
The first message about VAAPI is expected.
The second line "qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0" seems a bit unusual. "surface: 0x0" seems to imply that a wayland surface (basically a window) is null and some kind of graphics related error happened because of that. There's nothing else I can figure out from that.

You also said "It seems like whatever I did fixed it for now." Is it still working for you?
Comment 4 Nico 2024-07-11 16:27:23 UTC
The first line always appears but the second one no longer appears after it's working again. The window did not spawn when it was broken. It's working right now but if it happens again what should I run get proper logs that might help?
Comment 5 Noah Davis 2024-07-11 19:44:41 UTC
(In reply to Nico from comment #4)
> The first line always appears but the second one no longer appears after
> it's working again. The window did not spawn when it was broken. It's
> working right now but if it happens again what should I run get proper logs
> that might help?

I'm not sure. I don't know why the wayland surface would be null. Since the error message came from the Wayland Qt Platform Abstraction plugin, it could be an error in Qt Wayland, but it might not be. Without any knowledge of how to reproduce the bug, there's not much that can be done. I'm marking this as RESOLVED WORKSFORME since you say the bug no longer happens. If you encounter this issue again, you can reopen this bug.
Comment 6 Nico 2024-07-12 10:41:47 UTC
Yeah, I will definitely encounter it again because it already happened multiple times and a reboot always fixed it. But what should I do when it happens again? How can I provide logs or any other meaningful information?
Comment 7 Noah Davis 2024-07-12 12:58:38 UTC
(In reply to Nico from comment #6)
> Yeah, I will definitely encounter it again because it already happened
> multiple times and a reboot always fixed it. But what should I do when it
> happens again? How can I provide logs or any other meaningful information?

The best thing you could give me are detailed and reliable steps to reproduce the bug. The second best thing is a backtrace, but you probably won't be able to get one unless you can get spectacle to crash. The only logs right now are console output. You could post the console output for `QT_LOGGING_RULES="spectacle=true" spectacle -i`, although it probably won't have much useful info.