Hi, what I'm replying to has nothing to do with security anymore, so I changed the topic.
The security issue is what and when can use a specific protocol interface, the below is about how to use the interfaces once you already have access. On Wed, 8 Jan 2014 23:30:29 +0100 Maarten Baert <maarten-ba...@hotmail.com> wrote: > > On 08/01/14 13:52, Martin Peres wrote: > > I think the screenshot API and the video recording one should be > > separate. > Ideally that's true, but it creates extra work for the compositor > developers. And I don't see a huge benefit, actually. On X11 I can > simply take 30 screenshots per second and this works great, the > performance is about as good as it can get (2ms for a 1920x1080 frame, > that's almost as fast as a simple copy) and the only issue is tearing > (which is something that a good screenshot protocol should already > solve, obviously we don't want tearing in screenshots either). So I > would be perfectly happy with a screenshot interface that works just > like X11 minus the tearing. Do we really need a separate API for that? > > There's another gray area here: what about timelapse videos? These are > created by taking a screenshot every few seconds and then playing them > back at much higher speed. Should such an application use the > screenshot or the video API? There are differences in the implementation details of shooting (stills) vs. recording (videos). Weston supports (though disabled atm, AFAIK) hw overlays in addition to the GL renderer. To make a screenshot, the overlays are temporarily disabled, so that GL can composite the whole image which can then be sent to the shooting client. If you do repeated shooting, you probably end up doing a lot of useless back and forth work, enabling and disabling hw overlays. Also, shooting has one frame latency, because you have to wait for a repaint after you disabled the overlays. It will probably be quite hard to get a stable framerate. If the compositor knows we are doing recording instead of shooting, it can disable overlays for the whole duration. You only have the latency for the first frame, not all frames. There are probably other details that can be optimized, too. Shooting can easily be implemented like the current screenshooter protocol: a client creates a wl_buffer, and tells the compositor to fill it in. There is an inevitable copy, but since shooting is a rare action and usually triggered by the user directly, that cost is acceptable. The timing requirements are also very loose. That scheme might not work too well with recording, and achieving a zero-copy path to the video encoder will be hard. In that sense, the compositor autonomously pushing buffers to the client would be more performant, but then we have the problem of synchronizing buffer reads, writes, and re-uses. In the opposite direction, the synchronization was solved with the wl_surface.attach/commit and wl_buffer.release messages, but here an accidentally malfunctioning client has a greater risk to crash the compositor, if it does not return the buffers to the compositor in time, so the compositor needs a failsafe mechanism. Those are some reasons why screen recording (video) is easier to do as a compositor plugin, like it is currently in Weston. A separate client would need a non-trivial amount of new Wayland protocol to work well. Which method timelapse recording should use depends on the desired framerate and accuracy requirements. > > For the configuration of the screenshot, I see two cases. Either we > > just want > > the compositor to grab the image and pass it to an application [1] > > or we want > > the screenshotting app to be able to be able to query the number of > > screens and > > windows and their positions. The first doesn't require a Wayland > > protocol, the > > second does however require a privileged protocol. > The second is required for more all complex use cases, i.e. where the > user wants to capture only a single screen (or part of a screen). I > already support this under X11 and it seems to be a feature that many > users use (simply because monitor resolutions are usually larger than > the desired video resolution). Exporting the window hierarchy is not a good idea, and I think we are seriously trying to avoid it unless absolutely necessary. Instead, a client could ask the compositor to ask the user which window she wants to capture, and then the compositor would capture only that. Capturing individual outputs is a lot easier: Wayland core protocol already exposes all outputs, so the client can directly ask for a certain output. Asking the compositor to ask the user is really the only way to choose a window, anyway. There are no global names for windows that you could use from clients, and even if you did, you would not be able to implement "pick by clicking the actual window" without asking the compositor to do that. It would be a lot of new Wayland protocol to have the window picking controlled by the client. If you need some information about the window the user picked, you need to embed that into the shooting and recording protocols. In the part I cut out, there were some concerns about who and how should decide what hotkeys may or may not start shooting or recording. I think there was recently'ish a nice suggestion about a generic solution to the global hotkey problem, so you can probably leave it for that. I'm referring to the "clients bind to actions, server decides what hotkey is the action" kind of an idea, IIRC. There is a myriad of details to solve there, too. > User interaction is something that can only be defined by the > application, not by the compositor. The compositor can't anticipate > what kind of GUI or CLI some application might decide to use. Maybe > some users want the ability to start/stop recording using an IR > remote! Actually that's not even that far-fetched with SteamOS and > their 'big picture mode'. Should every Wayland compositor add support > for IR remotes too? I believe so, yes. An IR remote is an input device, and only the compositor can know which client should receive which events, if any. That way the normal users don't even need to access the device node directly, so you make eavesdropping harder. Whether the remote is exposed as a keyboard or triggering just actions or something else, is just yet another detail. You may want to map different buttons of the same remote to act on different programs, like volume always to the mixer while numbers to the current app, and the compositor itself handling the power button. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
