Collaboration on standard Wayland protocol extensions

[Jonas Ådahl]

On Sun, Mar 27, 2016 at 04:34:37PM -0400, Drew DeVault wrote:
> Greetings! I am the maintainer of the Sway Wayland compositor.
> 
> http://swaywm.org
> 
> It's almost the Year of Wayland on the Desktop(tm), and I have
> reached out to each of the projects this message is addressed to (GNOME,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:

I'm just going to put down my own personal thoughts on these. I mostly
agree with Carsten on all of this. In general, my opinion is that it is
completely pointless to add Wayland protocols for things that has
nothing to do with Wayland what so ever; we have other display protocol
agnostic methods for that that fits much better.

As a rule of thumb, whether a feature needs a Wayland protocol or not,
one can consider whether a client needs to reference a client side
object (such as a surface) on the server. If it needs it, we should add
a Wayland protocol; otherwise not. Another way of seeing it would be
"could this be shared between Wayland/X11/Mir/... then don't do it in
any of those".

> 
> - Screen capture

Why would this ever be a Wayland protocol? If a client needs to capture
its own content it doesn't need to ask the compositor; otherwise it's
the job of the compositor. If there needs to be a complex pipeline setup
that adds sub titles, muxing, sound effects and what not, we should make
use of existing projects that intend to create inter-process video
pipelines (pinos[0] for example).

FWIW, I believe remote desktop/screen sharing support partly falls under
this category as well, with the exception that it may need input event
injection as well (which of course shouldn't be a Wayland protocol).

As a side note, for GNOME, I have been working on a org.gnome prefixed
D-Bus protocol for remote desktop that enables the actual remote desktop
things to be implemented in a separate process by providing pinos
streams, and I believe that at some point it would be good to have a
org.freedesktop.* (or equivalent) protocol doing that in a more desktop
agnostic way. Such a protocol could just as well be read-only, and
passed to something like ffmpeg (maybe can even pipe it from gst-launch
directly to ffmpeg if you so wish) in order to do screen recording.

> - Output configuration

This has nothing to do with Wayland as well. If there is any need for
various compositors to support third party output configuration, at
least make it display protocol agnostic (D-Bus) so that it the doesn't
have to be one implementation in each layer for each display protocol
when there is actually no point of doing so.

> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)

Sounds like a job for a xdg_* protocol. However, I think we need to
first settle on a bare minimum protocol, in order to be able to
stabalize anything. This bare minimum protocol needs allows for
extendability making it possible to add things like negotiating how
decorations are drawn etc. The idea is that xdg_shell v6 will allow
this.

Of course we can add xdg_shell extensions already though (i.e. stand
alone protocol extension that extends xdg_shell).

> - Input device configuration

Same as output configuration. There simply is no valid reason for adding
a Wayland protocol for it.

> 
> I think that these are the core protocols necessary for
> cross-compositor compatability and to support most existing tools for
> X11 like ffmpeg. Considering the security goals of Wayland, it will also
> likely be necessary to implement some kind of protocol for requesting
> and granting sensitive permissions to clients.
> 
> How does this list look? What sorts of concerns do you guys have with
> respect to what features each protocol needs to support? Have I missed
> any major protocols that we'll have to work on? Once we have a good list
> of requirements I'll start writing some XML.

I don't think we should start writing Wayland protocols for things that
has nothing to do with Wayland, only because the program where it is
going to be implemented in may already may be doing Wayland things.
There simply is no reason for it.

We should simply use the IPC system that we already have that we already
use for things like this (for example color management, inter-process
video pipelines, geolocation, notifications, music player control, audio
device discovery, accessibility, etc.).


Jonas

> 
> --
> Drew DeVault
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list at gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list