Bug 513785

Summary: Feature: Implement wayland staging protocols ext_image_copy_capture_v1 and ext_image_capture_source_v1
Product: [Plasma] kwin Reporter: me
Component: wayland-genericAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED INTENTIONAL    
Severity: wishlist CC: kde
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description me 2025-12-24 19:26:28 UTC 
wayland-protocols merged[3]  the protocols ext_image_copy_capture_v1[1] and ext_image_capture_source_v1[2] into staging in august of 2024.

There represent an improved version of wlr-screencopy-unstable-v1, which is quite widespread. It has the advantage, to many, that it does not use XDG Portals, which means its far more useful for commandline usage, called from a global hotkey, or other kinds of usecase where having to accept a portal every time would be disruptive. I dont know KDEs stance on Portals and explicit permissions, but it should still be possible to implement a permission system for this (afaik thats what Hyprland is planning/doing).

Its currently implemented in the following compositors:
- COSMIC
- mahkoh/jay
- canonical/Mir
- wlroots
  - Sway
  - linuxdeepin/treeland
  - Labwc
  - Wayfire

With the following having plans to implement it:
- Hyprland [4]
- Niri [5]

Tools that can use the protocols already:
- emersion/grim - popular commandline screenshotter, feels like 80% of posts i've come across asking for wlr-screencopy-unstable-v1 support are grim users
- Ferdi265/wl-mirror - a simple Wayland output mirror client
- russelltg/wl-screenrec - High performance screen recorder for wlroots Wayland
- whynothugo/shotman - The uncompromising screenshot GUI for Wayland compositors
- any1/wayvnc - a VNC server for wlroots-based Wayland compositors

Note: The applications i mention above likely won't magically work if KWin gets this protocol, but for many it would become a far more reasonable ask to support KWin.

- [1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/ext-image-capture-source/ext-image-capture-source-v1.xml?ref_type=heads
- [2] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/ext-image-copy-capture/ext-image-copy-capture-v1.xml?ref_type=heads
- [3] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124
- [4] https://github.com/hyprwm/Hyprland/issues/9916
- [5] https://github.com/YaLTeR/niri/issues/1558
Comment 1 David Edmundson 2025-12-25 19:43:40 UTC 
Our priority is portals and improving this experience. 
Supporting two methods fragments this, we won't be adding this.
Comment 2 me 2025-12-25 21:11:56 UTC 
(In reply to David Edmundson from comment #1)
> Our priority is portals and improving this experience. 
> Supporting two methods fragments this, we won't be adding this.

I have some issues with portals which would make this a far more attractive option:
- portals screenshot API returns a URI, whereas this protocol stores the result directly in a CPU or GPU buffer. That makes this protocol far lower latency than portals.
- portals screencast API always requires pipewire usage, forcing devs to pull a big and complex library into their projects. For low-latency screenshots this also isn't a great option as it requires an ongoing permanent screen capture just to have the newest frame available.

I'm also pretty worried by the ongoing ecosystem split: With so many compositors planning to implement this protocol, and the current trend of screenshot and accessibility apps seemingly mainly using the protocols ober portals, i can barely find any options for screenshot tools that use portals.

So please, i would urge you (KWin/Plasma devs) to carefully consider this before outright denying.