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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel