Sorry - I'm rambling a bit If I add an API to create a 'secondary surface' by extending the IWindowSession and adding the requisite calls to WindowManagerService.java it looks like I have something that works correctly (many thanks for the pointer).
One thing I'm puzzling over though is this: - The new 'Surface' gets created in WindowManagerService.jave a using 'new Surface..' - Should I be creating it using a SurfaceSession provided by the client or one in the WindowManagerService (or does it matter)? - Should I be using the pid of the client or the pid of the current process (i.e. the WindowManagerServer) when creating the surface? - If the Surface is created in the WindowManager and passed back to the client using something like outSurface.copyFrom(newly created surface) do I end up with a surface that has multiple references to it and do I need to call myNiceNewSurface.clear() multiple times to tear it down? On Thu, Mar 26, 2009 at 6:28 PM, Dianne Hackborn <[email protected]>wrote: > Sorry I am not following what you are trying to do. > > > On Thu, Mar 26, 2009 at 10:16 AM, F H <[email protected]> wrote: > >> Thanks Dianne/Mathias >> >> - I want any class I create to look indistinguishble from any other kind >> of Surface - e.g. supporting SurfaceHolder, so that it can be locked and >> drawn to, or passed to a media API for video playback. >> >> - Presumably, the way Android would specify which display a surface were >> to be placed on would be to add a property that can be set on SurfaceHolder >> before the thing is laid out - e.g. setDisplay (along with setFlags, >> setType...). >> >> >> >> >> >> On Mon, Mar 16, 2009 at 7:16 PM, pixelflinger <[email protected]>wrote: >> >>> >>> Also note that SurfaceFlinger will be largely overhauled in future >>> releases, as well as its client library and protocol to both create >>> surfaces and talk to real h/w. We are not ready to share these changes >>> yet, as they are not finalized, but they will most likely make your >>> applications incompatible and integrating your SF changes, >>> challenging, to say the least. >>> >>> I don't think that supporting multiple displays should be done using >>> SF at this time. A simple way, could be to simply open /dev/fb1, >>> create a Canvas on it, or, directly blast video into there. You could >>> achieve this with a small server on the side of surfaceflinger and a >>> simple binder interface to access it as well as minimal API changes to >>> the system. >>> >>> Mathias >>> >>> >>> >>> On Mar 16, 10:37 am, F H <[email protected]> wrote: >>> > Thanks Dianne, >>> > >>> > I'm trying to figure out the best way of creating a Surface that can be >>> > displayed on an alternative display. I know that Android doesn't >>> support >>> > multiple displays. Our version of SurfaceFlinger does though, so I >>> was >>> > hoping to talk to it using a low-level interface in order to obtain a >>> > Surface on the alternative display. The Surface in question being one >>> that >>> > is suitable for using in a media player for example. >>> > >>> > The WM doesn't manage multiple displays and from what I can tell, >>> unless you >>> > have low-level access you can't tell SF to create a Surface on a >>> different >>> > display. >>> > >>> > Do you have any thoughts on the best way of implementing such a feature >>> > without contaminating any of Android's API's. >>> > >>> > On Mon, Mar 16, 2009 at 4:51 PM, Dianne Hackborn <[email protected] >>> >wrote: >>> > >>> > > On Mon, Mar 16, 2009 at 8:28 AM, F H <[email protected]> >>> wrote: >>> > >>> > >> Is it intended that low level access to Surface Flinger is granted >>> only to >>> > >> components that a part of the system and not to applications >>> developed using >>> > >> the SDK and signed using an arbitrary certificate? >>> > >>> > > Yes. >>> > >>> > >> Is it the intention that an Android platform be signed with a >>> certificate >>> > >> unique to an android provider, >>> > >>> > > Yes. >>> > >>> > >> who if they wished could enable applications to be signed by the >>> same >>> > >> certificate. >>> > >>> > > No, this would allow you to write third party applications that are >>> either >>> > > significant security vulnerabilities and/or break across platform >>> releases. >>> > > The platform certificate is intended to be exclusive to the device >>> > > manufacturer, and something they keep private. >>> > >>> > >> When an android system is built - where is the certificate that is >>> used >>> > >> for signing the system and does it need to be generated in a >>> particular way >>> > >> (e.g. does it need to be generated by some signing authority). >>> > >>> > > No it can be generated the normal way you general one for an SDK >>> developer. >>> > >>> > > The development certs are here: >>> > >>> > > >>> http://android.git.kernel.org/?p=platform/build.git;a=tree;f=target/p... >>> > >>> > > I don't know off-hand how you sign with your "real" certs; but a >>> basic rule >>> > > is that these are not checked in to any source repository but done as >>> a >>> > > separate step as part of making a final release image, and only >>> accessible >>> > > to a few select people. >>> > >>> > >> Presumably applications that connect up to surface flinger are >>> routed >>> > >> through something that has the requisite permission. (Or is it that >>> apps in >>> > >> general do not use low-level access?). >>> > >>> > > Applications do not get to use surface flinger. The window manager >>> uses >>> > > surface flinger, and provides the higher-level access that can be >>> kept >>> > > stable across releases. >>> > >>> > > -- >>> > > Dianne Hackborn >>> > > Android framework engineer >>> > > [email protected] >>> > >>> > > Note: please don't send private questions to me, as I don't have time >>> to >>> > > provide private support. All such questions should be posted on >>> public >>> > > forums, where I and others can see and answer them. >>> >>> >> >> >> > > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. > > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
