Re: Collaboration on standard Wayland protocol extensions

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

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

- 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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]