Re: Fw: Related to agl-compositor

On Tue, Dec 01, 2020 at 02:44:50AM +0000, Anusha Gugale wrote:
> Hello All,
Hi Anusha,
>
> I want to ask few questions to @Marius
>
> Q.  Is there any plan to modify Weston/clients/simple-egl.c application so that we can run for 'agl-compositor'?
No, not really. simple-egl belongs to upstream (community). That should be
the way to do it.
> Tryout:
> - I tried to run, it just added a particular surface in pending_list, there no log for surface role added and nothing is displayed onscreen.
simple-egl does not set the app id only the title. Modifying it to set
the app_id just like the title is trivial. Could try upstreaming that,
but I do know how to argue about that change. Using app_id is specific
to AGL, but on other hand maybe updating all apps to use it might be
something desirable. Guess it is worth a shoot to see.
> - Also, run for remoting plugin with localhost but it didn't succeed.
This is a bit vague. Specifying which application is streamed to that
output is done by either using config file (in the remote-output section
you use agl-shell-app-id=app_id_of_application) or by
using agl-shell-desktop protocol. You also need a receiver application
that receives the incoming buffers and that connects to the local
compositor.

Using the same machine for this might no be that trivial, one compositor
instance does the streaming and you need another instance of the
compositor (one the same machine) with the receiver connecting to the
last one. You can specify the which wayland compositor to connect to
by using WAYLAND_DISPLAY environmental variable. Probably using
DRM backend might worth while by using ssh. Might be able to use other
backends but you need the DRM backend for dmabuf import/export so unsure
how that might work out.

>
> It will be helpful for checking RBA policy activity if this application run.
>
> Q. To implement RBA policy in agl-compositor, the plan is to use existing policy hooks so further we are thinking to create different 'policy.so'. As in current implementation existing policy code is also included in 'agl-compositor' binary. Is this ok according to the design and implementation perspective?
There's no plan to have compositor plug-ins at the moment. The policy
engine will likely be as is, as that defines the interface so that each
policy implements its own specialized versions. Even so, the ability to
dynamically load policies isn't that far-fetched so I guess that is
worth adding on next meetings to see what others think about it. A
concern here would be about security.

A small note, if you need to extend the policy engine itself (so not the
policy) that will probably need to happen directly in the compositor.

>
>
> Thanks & Regards,
> Anusha Gugale
> ________________________________
>
> SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Technologies Limited ( formerly known as "Sasken Communication Technologies Limited" ) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.
> Read Disclaimer at http://www.sasken.com/mail-disclaimer/
>
> ________________________________
>
>
>
>
>