Hi Kevin,
Thanks for the summary. Might I be a pain, and suggest that if it's going to happen through the mir API, we also need a simple app that can take screenshots. Writing python <-> C bindings probably isn't the best way to go here, so I wonder if we could have a simple app that we can call like so: "mir-screenshot /path/to/file.png". That should be easy to write, I think? On Thu, Dec 5, 2013 at 12:33 AM, Kevin Gunn <kevin.g...@canonical.com>wrote: > After some discussion > > - first goal is to satisfy our QA requirement to capture full screen > output > - note, fullscreen only for now, not going to address app windows > - screencast/screenshot will go through the mir api > - e.g. mir_connection_output_surface, where the client can indicate > whether or not the client wants a gl or sw buffer, and then > mir_output_advance_buffer to indicate reading the next buffer (note > names > subj to change...just proposed ;) > - which fails for unprivileged clients > - we did discuss the potential addition of explicit capability > acquire/release for privileged apps, but it was decided we shouldn't add > this to the api until we have more concrete need/use cases > - mir will have a server side check with unity-mir for unity8 to check > against app armor to determine if the app has the capability to screencast, > this check will only happen when the call to the api is made > > > > > On Thu, Nov 28, 2013 at 1:40 AM, Daniel van Vugt < > daniel.van.v...@canonical.com> wrote: > >> Keeping in mind recording at full frame rate (or near) would solve both >> problems, I think we should have a single approach. >> >> The key thing to remember is bandwidth. Only the buffer sharing logic >> used in client IPC has the bandwidth to cope with recording/screencasting. >> >> Consider: 1920x1200 x 4bytesperpixel x 60FPS >> --> 553 megabytes per second >> >> Or even: 1366x768 x 4bytesperpixel x 30FPS >> --> 126 megabytes per second >> >> Hopefully it would be encoded more efficiently for storage, but still, >> you need to use buffer IPC that's designed for speed. Fortunately we have >> that already. >> >> >> >> On 27/11/13 23:30, Ricardo Mendoza wrote: >> >>> On Wed, 2013-11-27 at 07:32 +0100, Thomas Voß wrote: >>> >>>> On Tue, Nov 26, 2013 at 4:12 PM, Alexandros Frantzis >>>> <alexandros.frant...@canonical.com> wrote: >>>> >>>>> On Tue, Nov 26, 2013 at 01:13:28PM +0000, Gerry Boland wrote: >>>>> >>>>>> Hey, >>>>>> The system compositor will probably not be using the Qt scenegraph, >>>>>> but >>>>>> instead Mir's own compositor. I don't know if using >>>>>> QQuickWindow::grabWindow() will work in that case (though if it just >>>>>> calls glReadPixels, it probably will). >>>>>> >>>>>> Also if hardware (non-GL) compositing is being used, reading back >>>>>> pixels >>>>>> via glReadPixels won't be enough as not everything on screen will be >>>>>> drawn by GL. >>>>>> >>>>> >>>>> The original discussion was about autopilot being able to take >>>>> screenshots/casts of unity8 for testing and validation purposes, and we >>>>> came up with a simple solution for this use case. >>>>> >>>>> >>>> That's a fair point. As I understand it, there is the immediate >>>> requirement to support QA with screenshotting capabilities and the >>>> presented approach can be used to provide the required functionality. >>>> >>> >>> Back to this, providing a screenshotting interface with a default file >>> sink is a matter of... 30 minutes? I believe extending the >>> com.canonical.Unity.Screen interface; as long as you decide on a place >>> to put screenshot files and a default format. >>> >>> I believe we should provide this right away for QA, the rest of the plan >>> seems more broad and therefore not really committable to a strict >>> timeframe. I agree that casting would be great and that we need it, just >>> not sure if its the right time to slot it into the dev plan. >>> >>> However, it seems that people have more use cases for screen capturing >>>>> that require additional complexity. I think we need to discuss a bit >>>>> more about what we really need and when, check what is feasible in our >>>>> time frames and prioritize work. The upcoming sprint seems ideal for >>>>> this. >>>>> >>>>> >>>> +1. >>>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> Thanks, >>>>> Alexandros >>>>> >>>> >>> Regards, >>> >>> >>> Ricardo >>> >>> >>> >> -- >> 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 > > -- Thomi Richards thomi.richa...@canonical.com
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
