> -----Original Message----- > From: Puustinen, Ismo > Sent: Thursday, November 27, 2014 12:42 AM > To: Schaufler, Casey > Cc: [email protected]; [email protected] > Subject: Re: [Dev] [RFC] AUL UI request for multi-process applications > (ICO/Crosswalk...) > > Hi Casey, > > In IVI domain the car manufacturers may want to place "regulations" that > limit the applications that can be shown on the screen in different car > use cases. For instance: > > * When the car is moving, applications that play video are not allowed > on the screen. > * When the car is in reverse gear, the application that shows reverse > camera video must be shown on the screen. > * When the car is not moving, all applications are allowed on the > screen. > > You can easily think up a large number of possible use cases such as > these ones. > > It's "easy" to enforce similar audio policies since we have a pretty > good idea who is playing audio to PulseAudio.
Having a "pretty good idea" is not secure. > In order to do such screen > policy enforcement (even in collaborative way, when the application is > announcing it's true capabilities in the manifest file) we have to > somehow know which surface belongs to which application. Identifying the application making a request is easy, that's what we have Cynara for. What is a "surface", and who manages surfaces? In this discussion I see the terms "window", "surface" and "screen". Are they the same? Are they related? Are they controlled by the same service? Who is ultimately responsible for making the decision? > > Ismo > > > On Wed, 2014-11-26 at 17:00 +0000, Schaufler, Casey wrote: > > Why does the package name get used to determine if a window gets > > displayed? What policy do you really want to enforce? There has got to > > be a less convoluted way to get what you want than this. > > > > > > > > > > > > From: Dev [mailto:[email protected]] On Behalf Of Manuel > > Bachmann > > Sent: Wednesday, November 26, 2014 5:10 AM > > To: [email protected] > > Subject: [Dev] [RFC] AUL UI request for multi-process applications > > (ICO/Crosswalk...) > > > > > > > > > > Hi folks, > > > > > > This RFC is about bug TC-1691, TC-159... > > > > > > > > > > > > (The problem happens with Crosswalk today, but it could happen with > > any other application) > > > > > > AUL provide somes function calls, like "aul_app_get_pkgname_bypid > > ()", which permit to get the application package name associated with > > a running PID. > > > > > > Under IVI, the ICO Homescreen (profile/ivi/ico-uxf-homescreen) uses > > these calls to determine if it should show a window, by getting the > > PID of its process, and then comparing it will the package name. If if > > does not match, the window stays hidden. > > > > The problem is : > > > > > > In Crosswalk, the process which creates the window (the GPU process) > > is *not* the same that the one (the browser process) which registers > > itself as a Tizen application. > > > > > > Crosswalk has a dedicated process for UI operations, which is > > different of the one that does the application logic. > > So, the name is never found, and Web applications never show. > > > > > > > > > > > > In this respect, we need a way for an application to "pass" its > > application identifier to the graphical layer (in this case, ICO).Here > > are 2 options : > > > > 1) in Crosswalk itself, have a package name passed from application > > layer to the UI/GPU one (won't probably be upstream). Then, have a > > Weston plugin "receive" and store the information. When requested by > > the "aul_app_get_pkgname_bypid ()" call, AUL will also request the > > plugin for this information and respond. > > > > > > Requires modifications in : 3 packages (crosswalk, weston, aul-1) > > > > > > > > > > > > 2) in Crosswalk itself, have a package name passed from application > > layer to the UI/GPU one (won't probably be upstream). Then, store this > > data in a local database or specific tmpfs. When requested by the > > "aul_app_get_pkgname_bypid ()" call, AUL will also request this base > > or tmpfs for this information and respond. > > > > > > Requires modification in : 2 packages (crosswalk, aul-1) > > > > > > > > > > > > The 2nd idea modifies less packages but may be trickier to implement. > > Any opinion on this ? > > > > > > > > > > -- > > > > Regards, > > > > Manuel BACHMANN > > Tizen Project > > VANNES-FR > > > > > > _______________________________________________ > > Dev mailing list > > [email protected] > > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
