Le 09/01/2014 21:47, Maarten Baert a écrit :
On 09/01/14 10:00, Pekka Paalanen wrote:
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.
That's probably true, but you can't expect applications to write a
separate plugin for each compositor. Besides, I highly doubt that it's a
good idea to load ffmpeg/libav and all its dependencies into the
compositor - these libraries aren't exactly known for their stability ;).
Very valid point!
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.
The window picking function that I have now (for X11) is really just a
way to quickly enter the correct coordinates and size of the area that
should be recorded. I don't expect the user to move the window around.
And just to be clear, the goal is NOT to capture only the buffer of a
single window, because then 'subwindows' (like browser plugins) and
dialog windows won't be recorded. If I really wanted to capture just a
single SHM buffer, I would probably just do it client-size, in the same
way I already do OpenGL recording now (because this gives me much more
flexibility).
So what I'm asking for is just a function to get the rectangle (x,y,w,h)
that corresponds to the window directly below a given position (x,y).
The compositor doesn't even have to handle the complexity of 'real' user
interaction (i.e. showing a message to the user telling him to pick a
window, waiting for the user to do that, dealing with clients that make
a request and then die, ...). Such a function would do everything I
need, and I think it also covers what the existing screenshot
applications need. I prefer to do it like this because it is the most
simple way to implement this for the compositor, and it is more flexible
(e.g. applications can choose to select the recording area in advance
and then repeatedly use the same area without telling the user to select
it over and over again).
I'm not saying supporting the acquisition of just a rectangle isn't a
good idea but if what the user wants is the output of a window, it is stupid
to grab the whole screen. Shouldn't we try to make stuff just work,
whatever the user does?
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.
That would make a lot more sense, at least it is a lot more flexible
than requiring the recording application to be launched by the same key
press that starts the recording (which would effectively force me to
split my application into two separate processes, and then I would have
to figure out a secure way to let these two processes communicate).
But what about things like mouse clicks? Can the compositor tell that
the user clicked the 'start recording' button?
It can't but we are talking about video recording. The app should just
drop the frames when it is not interested in them. Once it has been
run with the right hotkey, it will receive all the frames.
As for security, the compositor should provide some feedback in the
notification tray until the apps stops, I guess.
Maarten Baert
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
