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
Our priority is portals and improving this experience. Supporting two methods fragments this, we won't be adding this.
(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.