On 07/01/2014 20:43, Pekka Paalanen wrote:
On Tue, 7 Jan 2014 14:26:36 -0500
"Jasper St. Pierre" <jstpie...@mecheye.net> wrote:
On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres
<martin.pe...@free.fr> wrote:
Would it be ok for you if the compositor asked the user to
agree for the program to
do the operation? If so, we can guarantee that this is really
the user's intent and
allow the application. We can also add a security warning with
a "Do not ask again"
checkbox. Would it be satisfactory to you?
The user opened up a screen recording app. The user's intent is
very much to record the screen. We don't need to ask the user
again with a prompt.
For just screenshooting and recording, how about a simple setting
"allow all programs capture the screen? yes/no" in the compositor's
configuration dialog? Since it sounds like any automatic
authentication/authorization scheme is going to hit cornercases.
With that, write a screenshooting protocol interface, that is
bindable for all clients, and informs the client whether capturing
at will is allowed or not. When not, the client can show an
informational message "Screen capturing is disabled in your
compositor preferences."
Make that support dynamic enable/disable and make access denied a non-fatal
error.
What I like about your dynamic enable/disable idea is that there is no
storage
of the settings that could be abused by other apps (since they are usually
run with the same user as the compositor). If we want to make the setting
permanent (for whatever stupid reason one may have), it should require
root access to store this setting.
I think making sure the user really is the one who launched the app (by
letting
the compositor launch it for us) is really a lesser evil and should
cover all the
cases. No need to add complexity by creating new protocols to require
privileges (I already implemented one and it is hard to make it right,
and I'm not
even talking about the fact it requiring a policy!).
I think the screenshot API and the video recording one should be separate.
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.
If we go for the second solution (which could make sense for other use
cases),
we should limit the number of screenshots the app can make, otherwise we
cannot make sure the app really exited and is not grabbing the screen
all the
time. I am however willing to live with that if the default-screenshot
app can
only be changed as root or as a run-time change. Another possibility would
be to advise to use [1] by default and the second solution would be the
less-secure fallback that doesn't restrict the user much.
Any thoughts?
As for the video grabbing API, I see the same solutions. Different
hotkeys could
automatically grab the screen content (either by window or screen) or it
could be
queried using the screen/window layout query protocol. Once the screen
capture
has been set up, a stream of DMA-buf (or shm) should be sent to
different program
that would record the output to whatever format one wants (stream of png
or video)
using either sw or hw encoders. Both the first and second case would use
an external
program to select the output format and encoding method. The good thing
is that this
encoding program would be compositor-independent and could be shared by
all of them.
Weston could then get rid of his VA-encoder and just use this new protocol.
The good thing about sending a stream of images is that we get explicit
synchronization
between the compositor and the screen grabbing app which means it can
miss no frames
nor sample the same one twice (unless that's what the app wants).
Again, any thoughts on this?
Cheers,
Martin
[1]:
The screenshot "API" could just grab an image based on what hotkey is used:
- window under the cursor
- current screen (where the cursor is)
- all the screens
I'm not sure how to do that on touch devices, but this is a compositor
implementation detail. Once the image is grabbed, the compositor should
either
save the file somewhere or pass it to an application.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
