Collaboration on standard Wayland protocol extensions

[Drew DeVault]

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.

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

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

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

--
Drew DeVault