Discussion: Work with wlroots to use their protocols rather than using a separate set

[orowith2os]

By design, Wayland has fragmentation in how protocols are handled, currently there being three main sets: KDE, GNOME, and wlroots.

I would suggest working with wlroots to use their protocols rather than using a separate set, so as to reduce fragmentation of the Linux desktop. This would also make it easier for utilities to support Cosmic, since they can just build for wlroots and it'll already work on Cosmic.

[Drakulix]

That is the plan, though we are not working directly with the wlroots folks, but try to upstream the used protocols:

• cosmic-workspace-unstable-v1 is a purely namespaced version of the ext-workspace protocol. Which itself was supposed to be wlr-workspace-unstable-v1, but that never materialized, arguing the protocol should better be upstreamed. Out of that the ext-workspace PR was started, which is currently maintained by myself. Once that is merged, everyone can just use that protocol.
• cosmic-toplevel-info-unstable-v1 is mostly just another namespaced variant of the ext-foreign-toplevel-info protocol, which is based on wlr-foreign-toplevel-management. We also plan to switch to that protocol, once it is merged: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/155
• Same for cosmic-toplevel-management-v1: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/156
• cosmic-export-dmabuf-unstable-v1 is mostly a slightly edited version of the wlr-export-dmabuf protocol, but will be replaced by...
• cosmic-screencopy-unstable-v1, which is based on ext-screencopy. This one is a little more tricky, because we want to be able to capture windows and workspaces, both options are currently not available in the proposed protocol. But options to support arbitrary sources have been discussed on IRC recently and a new version of said protocol should be able to cover our use cases.

As you can see there is active work going on for all protocols to reduce fragmentation long-term. We will continue making protocols, where functionality is lacking for features we want to provide. And I cannot promise you, that we won't end up with one or two private protocols for certain shell functionality, but we are actively trying to use established solutions and participate in developing new ones.

Additionally we are already using wlr-protocols, where they already seem a good fit. E.g. the wlr-layer-shell and the wlr-output-configuration protocol, which are both fully supported by cosmic-comp.

[loligans]

@Drakulix

• cosmic-export-dmabuf-unstable-v1 is mostly a slightly edited version of the wlr-export-dmabuf protocol, but will be replaced by...

• cosmic-screencopy-unstable-v1, which is based on ext-screencopy. This one is a little more tricky, because we want to be able to capture windows and workspaces, both options are currently not available in the proposed protocol. But options to support arbitrary sources have been discussed on IRC recently and a new version of said protocol should be able to cover our use cases.

You mentioned that cosmic-export-dmabuf-unstable-v1 will be replaced by cosmic-screencopy-unstable-v1. Does this mean that cosmic-screencopy-unstable-v1 will support both screen capture AND screen casting use cases? If not I think cosmic-export-dmabuf-unstable-v1 should probably be kept in order to support the screen casting use case

[Drakulix]

@Drakulix

You mentioned that cosmic-export-dmabuf-unstable-v1 will be replaced by cosmic-screencopy-unstable-v1. Does this mean that cosmic-screencopy-unstable-v1 will support both screen capture AND screen casting use cases? If not I think cosmic-export-dmabuf-unstable-v1 should probably be kept in order to support the screen casting use case

The protocol doesn't differentiate between what you do with the captured contents. (Stream or save to disk or whatever.)

As such both screen casting and recording use cases can be covered by it.

[probonopd]

Why cosmic-screencopy-unstable-v1 when there is already wlr-screencopy-unstable-v1?

Would it mean that existing tools that use wlr-screencopy-unstable-v1, such as wf-recorder -a, would not work without modification on Cosmic?

Why would anyone want such fragmentation?

[PolyMeilex]

Why cosmic-screencopy-unstable-v1 when there is already wlr-screencopy-unstable-v1?

Would it mean that existing tools that use wlr-screencopy-unstable-v1, such as wf-recorder -a, would not work without modification on Cosmic?

Why would anyone want such fragmentation?

It was already answered, wlr can't capture capture windows or workspaces. And as far as I understand cosmic wants to switch to ext_screencopy once it has needed features and is merged upstream, trying to use official protocol extension is opposite of fragmentation.

[probonopd]

Thanks for your expanation, looking forward to it then. It'd be so nice if all compositors supported all protocols. Currently every desktop environment has some things that work in Wayland and others that are broken.

Wouldn't it be sensible to standardize on wlroots and let it handle the rest?

[Consolatis]

Wouldn't it be sensible to standardize on wlroots and let it handle the rest?

The wlroots protocol does not support capturing single windows. So unless cosmic wants to implement both protocols (which would be possible be also somewhat redundant) it would loose the ability to capture single windows.

Usually how screencapture / screencast works in wayland from an application point of view (e.g. OBS or similar) is via a xdg-desktop portal interface so the actual wayland protocol in use doesn't really matter as the abstraction in this case is via the xdg-desktop portal interface. That does mean however that tools that directly use the wayland protocol (like wf-recorder) won't work.

[probonopd]

That there is no Portals involved makes wf-recorder -a so great and simple if you "just want to record your screen with audio coming from the microphone", as is a common use case.