The ext-image-capture-source-v1 and ext-image-copy-capture-v1 screen copy protocols build upon wlroots’ wlr-screencopy-unstable-v1 with various improvements for better screen capture support under Wayland. These new protocols should allow for better performance and window capturing support for use-cases around RDP/VNC remote desktop, screen sharing, and more.

Merge Request: Create ext-image-capture-source-v1 and ext-image-copy-capture-v1

  • Mactan@lemmy.ml
    314·
    1 month ago

    under the definition of bike shedding in the Encyclopedia you’ll find wayland the prime example. been waiting years on one pr for them to decide on the word “may” vs “will”

    • gbin@lemmy.ca
      163·
      1 month ago

      It drives me crazy. Just release it 18+months ago and iterate with versions, at least your users will have the feature in their hands.

      • Skull giver@popplesburger.hilciferous.nl
        14·
        1 month ago

        That’s how you get the Zoom problem, where a Zoom developer decided to be nice and port their program to Wayland before screen capture was implemented well, resulting in a “workaround” that took screenshots in a loop rather than move to the proper API.

        The API has been in the hands of people and developers for months, just not those who like their system to be moderately stable.

        • gbin@lemmy.ca
          41·
          30 days ago

          It is kind of shooting at the ambulance, zoom needs to also adapt to the new API. The alternative is a completely non functional Wayland for videoconferencing for years… Unusable stable is not better than unstable usable IMHO at least you have a shot at fixing it for the second option.

          • Skull giver@popplesburger.hilciferous.nl
            71·
            30 days ago

            Yes, of course. But jumping on early with an incomplete API isn’t just something Zoom does. Plenty of applications are broken because they don’t receive complete API rewrites every few years.

            Plus, it’s not like desktop Linux didn’t already ship a screen casting API. If developers wanted an unfinished/unstable API, they could’ve just implemented Gnome’s DBUS based API, that’s been around for years. No need to use something wlroots specific. Plus, the Gnome API also works on X11.

    • Vincent@feddit.nl
      32·
      30 days ago

      decide on the word “may” vs “will”

      I assume they went with way land as a compromise.

  • red@lemmy.zip
    11·
    1 month ago

    I hope this can mean I can use my android tablet as a 3rd screen with vnc with usable lag and frame rate

  • daq@lemmy.sdf.org
    6·
    30 days ago

    Pipewire works well enough for sharing screen even though it isn’t well supported by shit software like Slack. Would this replace it?

    • pnutzh4x0rOPAEnglish
      11·
      30 days ago

      No, most likely Pipewire would be used to implement the protocol for various compositors.

      Think of the protocols as high-level descriptions of interfaces (or designs) that specify what needs to be implemented to support a particular feature (in this case capturing images of a “screen”). Looking at this one, it describes a ext_image_capture_source_v1 object that has various methods such as create_source and destroy. Different compositors could then implement or support this interface with whatever technology they wish (most will rely on Pipewire).

      This is already the case with the existing screensharing protocol. For instance wlroots uses pipewire buffers in xdg-desktop-portal-wlr.

  • ashaman2007@lemm.ee
    36·
    1 month ago

    So… does THIS mean that this doesn’t support explicit sync, right as explicit sync is about to be stable and supported in the NVIDIA 560/565 drivers? As far as I know there are currently other ways to do screen capture outside of this protocol on Wayland so its not like there are no interim solutions, why release this when it is essentially still incomplete?