On Tue, 29 Mar 2016 12:01:52 +0800 Jonas Ådahl <jadahl gmail com> wrote:
On Mon, Mar 28, 2016 at 11:33:15PM -0400, Drew DeVault wrote:On 2016-03-29 10:30 AM, Jonas Ådahl wrote:I'm just going to put down my own personal thoughts on these. I mostly agree with Carsten on all of this. In general, my opinion is that it is completely pointless to add Wayland protocols for things that has nothing to do with Wayland what so ever; we have other display protocol agnostic methods for that that fits much better.I think these features have a lot to do with Wayland, and I still maintain that protocol extensions make sense as a way of doing it. I don't want to commit my users to dbus or something similar and I'd prefer if I didn't have to make something unique to sway. It's probably going to be protocol extensions for some of this stuff and I think it'd be very useful for the same flexibility to be offered by other compositors.As a rule of thumb, whether a feature needs a Wayland protocol or not, one can consider whether a client needs to reference a client side object (such as a surface) on the server. If it needs it, we should add a Wayland protocol; otherwise not. Another way of seeing it would be "could this be shared between Wayland/X11/Mir/... then don't do it in any of those".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.- Screen captureWhy would this ever be a Wayland protocol? If a client needs to capture its own content it doesn't need to ask the compositor; otherwise it's the job of the compositor. If there needs to be a complex pipeline setup that adds sub titles, muxing, sound effects and what not, we should make use of existing projects that intend to create inter-process video pipelines (pinos[0] for example). FWIW, I believe remote desktop/screen sharing support partly falls under this category as well, with the exception that it may need input event injection as well (which of course shouldn't be a Wayland protocol). As a side note, for GNOME, I have been working on a org.gnome prefixed D-Bus protocol for remote desktop that enables the actual remote desktop things to be implemented in a separate process by providing pinos streams, and I believe that at some point it would be good to have a org.freedesktop.* (or equivalent) protocol doing that in a more desktop agnostic way. Such a protocol could just as well be read-only, and passed to something like ffmpeg (maybe can even pipe it from gst-launch directly to ffmpeg if you so wish) in order to do screen recording.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? 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.I haven't heard of Pinos before, but brief searches online make it look pretty useful for this purpose. I think it can be involved here.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.I don't think we should start writing Wayland protocols for things that has nothing to do with Wayland, only because the program where it is going to be implemented in may already may be doing Wayland things. There simply is no reason for it. We should simply use the IPC system that we already have that we already use for things like this (for example color management, inter-process video pipelines, geolocation, notifications, music player control, audio device discovery, accessibility, etc.).Most of what you mentioned (geolocation, notifications, music control, audio device discovery) have anything to do with Wayland. Why would they have to use the same communication system? Things like how output/input devices are handled, screen capture, and so on are very clearly Wayland related and I think a Wayland solution for them is entirely acceptable.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.
For the record, I totally agree with Jonas. Let's not reinvent existing protocols just because you want to use Wayland IPC, unless using Wayland IPC is actually a fundamental requirement for the operation. The fundamental requirement to use Wayland IPC is precisely the need to reference Wayland protocol objects, e.g. wl_surface, or the need to identify a Wayland client (a Wayland connection) without a trusted third party like a container framework. Also what I bothered to read from the exhausting thread between Drew and Carsten, I would agree with Carsten in practically every point. Thanks, pq
Attachment:
pgpe8I_Fu3JYY.pgp
Description: OpenPGP digital signature