On Wed, Nov 27, 2013 at 2:38 AM, Daniel van Vugt <daniel.van.v...@canonical.com> wrote: > On an implementation note... > > I think adding yet more library dependencies (dbus) to Mir would be a > mistake. It's already quite bloated in that respect. >
+1, Mir should expose the required functionality via its server-side interfaces. Exposure to other clients than the shell is then the responsibility of the shell from my pov. Thomas > The key recording functionality in Mir shouldn't care about the > communications anyway. So it would probably be a cleaner division of > responsibility to make the bus communication external to libmir*. Either > attached to unity-mir or some privileged client etc. > > > > On 26/11/13 20:31, Daniel d'Andrada wrote: >> >> Hi, >> >> On November 26th I (Unity8), Kevin Gunn, Chris Gagnon (Autopilot) and >> Alexandros Frantzis (Mir) had a meeting on the requirements and >> implementation of screenshotting and screencasting. >> >> Chris told us that what autopilot really wants is screencasting (not >> screen shots) as it records all that happens during a test case and >> publishes the resulting video in case of failure. >> >> Kevin came with the point that application developers already want >> screenshotting and screencasting and therefore the solution should also >> cater to them (as opposed to having a solution that works for autopilot >> now and for other/third-party applications to be done only later). >> >> Thus considering those requirements and the future mir architecture >> (using qt scenegraph), that's the implementation we agreed upon: >> >> Unity8 would provide a D-Bus service for clients (applications, >> autopilot) to request for a screencast or screenshot. In case of a >> screenshot, the requestor would just provide a filename (or directory) >> where the screenshot(s) should be placed and unity8 would do it. For >> screencasts unity8 would provide a shared memory area to the requestor >> that would be kept up to date with the contents of the screen. Access to >> that shared memory area would be controlled with a semaphore and a >> mutex. So the problem of handling codecs, recording and audio stream to >> go along with it, etc is left to the user (i.e. an actual screencasting >> application or tool). >> >> D-Bus was chosen because access control to the screenshot/screencast >> feature can be easily implemented using D-Bus security policies. >> According to Alexandros, Mir probably won't have to be modified for >> screen[shotting|casting]. As a QQuickWindow will be controlling the >> composition now (qt-scenegraph approach), what would have to be done is >> calling glReadPixels right after the scene graph is rendered, which is >> essentially how "QImage QQuickWindow::grabWindow()" is implemented (if I >> understood its code correctly). >> >> So that's where I'm heading with the implementation (didn't start yet). >> If someone has a better idea, sees a problem with this approach or >> otherwise has something to add, please advise. >> >> Feedback already received so far: >> >> Thomi Richards: >> - Clarified that autopilot also wants screenshots. >> - Asked for a command line tool that does all the work of talking to >> that proposed screencasting API and outputs an ogv. >> >> Michał Sawicz: >> - "I'm not sold on the idea that it's unity8's / unity-mir's >> responsibility to provide that interface, though, as the ability to do >> those feels like a very generic need that should be built into the >> display server itself. Maybe the fact that we might be using Qt's >> scenegraph changes something here, though - but maybe that just means >> there's a new project growing on unity-mir's side?" >> > > -- > Mir-devel mailing list > Mir-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/mir-devel -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
