Re: Collaboration on standard Wayland protocol extensions



On Tue, 29 Mar 2016 12:01:52 +0800
Jonas Ådahl <jadahl gmail com> wrote:

On Mon, Mar 28, 2016 at 11:33:15PM -0400, Drew DeVault wrote:
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.  

I didn't say the display server shouldn't be the one exposing such an
API, I just think it is a bad idea to duplicate every display server
agnostic API for every possible display server protocol.

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

So if you have a compositor or a client that wants to support three
display server architectures, it needs to implement all those three
API's separately? Why can't we provide an API ffmpeg etc can use no
matter if the display server happens to be the X server, sway or
Unity-on-Mir?

I don't see the point of not just using D-Bus just because you aren't
using it yet. It's already there, installed on your system, it's already
used by various other parts of the stack, and it will require a lot less
effort by clients and servers if they they want to support more than
just Wayland.


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.
  

Pinos communicates via D-Bus, but pixels/frames are of course never
passed directly, but via shared memory handles. What a screen
cast/remote desktop API would do is more or less to start/stop a pinos
stream and optionally inject events, and let the client know what stream
it should use.

  
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.  

Sorry, I don't see how you make the connection between "Wayland" and
"screen capture" other than that it may be implemented in the same
process. Wayland is meant to be used by clients to be able to pass
content to  and receive input from the display server. It's is not
intended to be a catch-all IPC replacing D-Bus.

For the record, I totally agree with Jonas.

Let's not reinvent existing protocols just because you want to use
Wayland IPC, unless using Wayland IPC is actually a fundamental
requirement for the operation.

The fundamental requirement to use Wayland IPC is precisely the need to
reference Wayland protocol objects, e.g. wl_surface, or the need to
identify a Wayland client (a Wayland connection) without a trusted
third party like a container framework.

Also what I bothered to read from the exhausting thread between Drew
and Carsten, I would agree with Carsten in practically every point.


Thanks,
pq

Attachment: pgpe8I_Fu3JYY.pgp
Description: OpenPGP digital signature



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