Collaboration on standard Wayland protocol extensions

[Jonas Ådahl]

On Tue, Mar 29, 2016 at 07:41:10AM -0400, Drew DeVault wrote:
> Thus begins my long morning of writing emails:
> 
> On 2016-03-29 12:01 PM, Jonas Ådahl wrote:
> > > 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.
> 
> Do you foresee GNOME on Mir ever happening? We're trying to leave X
> behind here. There won't be a Wayland replacement for a while. The
> Wayland compositor has ownership over these resources and the Wayland
> compositor is the one managing these resources - and it speaks the
> Wayland protocol, which is extensible.

GNOME's mutter already work as being a compositor for two separate
protocols: X11 and Wayland. Whenever possible, I by far prefer to
deprecate the way replacing it with a display server protocol agnostic
solution, than having duplicate implementation for every such thing.

> 
> > > 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?
> 
> See above

Most if not all clients will for the forseeable future most likely need
to support at least three protocols on Linux: X11, Wayland and Mir. I
don't see any of these going away any time soon, and I don't see any
reason to have three separate interfaces doing exactly the same thing.

> 
> > 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.
> 
> Not everyone has dbus on their system and it's not among my goals to
> force it on people. I'm not taking a political stance on this and I
> don't want it to devolve into a flamewar - I'm just not imposing either
> side of the dbus/systemd argument on my users.
> 
> > 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.
> 
> Hmm. Again going back to "I don't want to make the dbus decision for my
> users", I would prefer to find a solution that's less dependent on it,
> though I imagine taking inspiration from Pinos is quite reasonable.

We are not going to reimplement anything like Pinos via Wayland
protocols, so any client/compositor that want to do anything related to
stream casting (anything that doesn't just make the content end up
directly on the filesystem) will either need to reimplement their own
private solution, or depend on something like Pinos which will itself
depend on D-Bus.

> 
> > 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.
> 
> DBus is not related to Wayland. DBus is not _attached_ to Wayland. DBus
> and Wayland are seperate, unrelated protocols and solving Wayland
> problems with DBus is silly.

So is screen casting/recording/sharing. It's a feature of a compositor,
not a feature of Wayland. Screen casting in the way you describe (pass
content to some client) will most likely have its frames passed via
D-Bus, so you'd still force your user to use D-Bus anyway.


Jonas

> 
> --
> Drew DeVault