Re: Collaboration on standard Wayland protocol extensions

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

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

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.


Drew DeVault

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