Collaboration on standard Wayland protocol extensions

[Drew DeVault]

On 2016-03-29 10:30 AM, Jonas Ådahl wrote:
> 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.

I think these features have a lot to do with Wayland, and I still
maintain that protocol extensions make sense as a way of doing it. I
don't want to commit my users to dbus or something similar and I'd
prefer if I didn't have to make something unique to sway. It's probably
going to be protocol extensions for some of this stuff and I think it'd
be very useful for the same flexibility to be offered by other
compositors.

> 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".

I prefer to think of it as "who has logical ownership over this resource
that they're providing". The compositor has ownership of your output and
input devices and so on, and it should be responsible for making them
available.

> > - 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.

I know that Gnome folks really love their DBus, but I don't think that
it makes sense to use it for this. Not all of the DEs/WMs use dbus and
it would be great if the tools didn't have to know how to talk to it,
but instead had some common way of getting pixels from the compositor.

I haven't heard of Pinos before, but brief searches online make it look
pretty useful for this purpose. I think it can be involved here.

> > - 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.

I'm dropping the output configuration protocols that I initially wanted
to make, I've come around. I think we just need to rethink fullscreen
requests to work with the permission model we come up with.

> > - 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).

This sounds reasonable.

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

Same as output configuraiton, I've come around and we should probably
drop this, though again with the constraint that we should tweak things
like pointer-constraints to work with the permissions model.

> 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.).

Most of what you mentioned (geolocation, notifications, music control,
audio device discovery) have anything to do with Wayland. Why would they
have to use the same communication system? Things like how output/input
devices are handled, screen capture, and so on are very clearly Wayland
related and I think a Wayland solution for them is entirely acceptable.

--
Drew DeVault