Re: Collaboration on standard Wayland protocol extensions

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.

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

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

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