Re: [agl-dev-community] af-binder and af-main start-up issues and windowmanager/libhomescreen dependencies

["Jose Bollo" <jose.bollo@xxxxxxx>]

On Mon, 20 Jan 2020 16:49:27 +0200
"Marius Vlad" <marius.vlad@xxxxxxxxxxxxx> wrote:

> Hi Jose,
> 
> Thanks for the replies!
> 
> I've CC'ed the mailing list as well to engage more audience
> if needed, hope you don't mind.

Hi Marius,

I agree to open the audience. I can add that the discussion is about
integration of collabora's work on the agl-shell.

> On 1/20/20 3:56 PM, José Bollo wrote:
> > On 10/01/2020 17:45, Marius Vlad wrote:  
> >> Hi Jose,
> >>
> >> See my replies below. Btw, thanks for your time and patience to
> >> answer my questions!
> >>
> >> On 1/10/20 2:37 PM, José Bollo wrote:  
> >>> On 09/01/2020 23:50, Marius Vlad wrote:  
> >>>> Hi Jose,
> >>>>
> >>>> See below for another round of inline replies from my part.  
> >>>
> >>> Hi Marius,
> >>>
> >>> let run another round of snipping
> >>>
> >>> (snip)
> >>>  
> >>>>>    
> >>>>>> I've added some C++ wrappers on top of my "launcher" code that
> >>>>>> uses libafbswc, so that could be used in that launcher
> >>>>>> application as well.  
> >>>>>
> >>>>> I have in draft some C++ wrapper for it (see branch
> >>>>> sandbox/jobol/wscpp
> >>>>> -from a trainee work-). As I wrote before, it could be of worth
> >>>>> to have
> >>>>> a library independent of systemd.  
> >>>>
> >>>> Alright, fair enough. We'll see how to tackle this before I
> >>>> start to upstream some of the parts I have.  
> >>>
> >>> I have no agenda on that topic. When do you expect something?
> >>> Yesterday?  
> >>
> >> I'm in yesterday mode for over two weeks now. At least that is
> >> what I've been informed. Once I have converted
> >> mediaplayer/hvac/navigation/launcher and polish a bit current
> >> homescreen code I'll start sending patches. Hoping by middle/end
> >> of the next week. It will give me some time to test it a bit more.
> >>
> >> Looked briefly on what you have, and mine looks like C with
> >> classes, not CPP, but yeah, but it serves as a PoC for now.  
> > 
> > Hi Marius,
> > 
> > Yes C and C++ present a big gap in there management of IOs and also
> > the idea was to have the basis in C.
> >   
> 
> Regarding this part, on launching applications, I've been having some
> talks with the guys in the meeting, last week, and they've revealed
> something equivalent to what I was trying to achieve, that resides in
> agl-service-homescreen. In the homescreen binder there are calls
> towards afm-system-daemon using `afb_api_call()`. These are all quite
> hidden, such that  'showWindow()' (or something equivalent to that)
> calls into this, if the application is not already started, which is
> not obvious at first hand.
> 
> Launcher application also seems to use this agl-service-homescreen for
> it, as to retrieve the runnables applications array and also calls
> into `afb_api_call()`.

These service are designed to run on top of the AGL framework binder
(/usr/bin/afb-daemon) and are coded as AGL bindings. It use the
interface that the binder offers to them. Here the function
afb_api_call.
https://docs.automotivelinux.org/docs/en/master/apis_services/reference/af-binder/reference-v3/func-api.html#afbapicall

Advantage is that the setup (connections) is made for them, the binder
knows how to connect code to system.

> On my end, I've used `afb_proto_ws_client_call()` coupled with
> `afb_ws_client_connect_api()` and yeah, a few more layers on top to
> call those verb commands directly.

You are not running on top of the AGL framework binder so you can not
use its features. Instead you have to manage connections by yourself.
To achieve it you are using the library libafbwsc that hides details of
the protocol and provide a more convenient API but still a bit raw.
That library allows to communicates with AGL framework binders on
both of the available protocols: WSJ1 or WSAPI. In your case, because
you want to access the API afm-main by connecting directly to its
socket, you connect using protocol WSAPI protocol.

> It seems that `afb_api_call()` is a bit more generic, but if you don't
> me asking what are the differences between these two?

I perhaps already answered. The use of `afb_api_call()` is possible in
bindings. Bindings are skill-component built as shared library, loaded
by the binder.

> On the same page, I'm currently in the process of modifying
> agl-service-homescreen as to be able to expose some of the requests
> from agl-shell, and I'm wondering how feasible is it to serialize
> object (a.k.a pointers) over JSON.

Several algorithms exist. I have no special advice.

However if you intend to use pointer values directly, note that the used
JSON library is able to handle 64 bits integers but to be as safe as
possible, it is probably better to use a string (hexa? %p?), it will
ensure that the accuracy is kept (no unexpected conversion to lower bit
capacities).

> To give you a better view of the things, if agl-service-homescreen
> will be one binding to the agl-shell interface it needs to be able to
> use wayland objects (wl_surface/wl_output) and they have be passed
> from homescreen to libhomescreen and from there serialized to
> agl-service-homescreen. Clients can create on their own wayland
> objects and call into the binder service.
> 
> Then, agl-service-homescreen has to de-serialize those to wayland type
> of data, and use those in the requests for agl-shell interface.
>
> This kind of reflection is obviously not available in C/C++ and only
> passing pointers disguised as ints does not seem to do the "trick",
> though I haven't really tried (but will soon). Will have a look to
> other potential ways of doing this, maybe there is a way to identify
> them, but not sure what could be atm.

Then I have to assume that Wayland/Weston/agl-shell enforces use of
pointers that can be passed from on process to an other process. In
that case, just use it that way with the caution I pointed out.

> So my question here can this be achievable in some sort, or not? If
> so, are there any examples for doing this?

It depends on what Wayland/Weston/agl-shell expects. But it should work
with pointer's values.

(snip)

> >>>>> On current AGL, homescreen does not run as root. So it is
> >>>>> strange... 
> >>>>>> I suspect that I can tweak config.xml to allow agl-driver to
> >>>>>> start applications?  
> >>>>>
> >>>>> Yes seems to be the solution.  
> >>>>
> >>>> Alright I'll check to see, but it kinda seems it needs to be
> >>>> root in order do that (see my above reply).  
> >>>
> >>> See above. But I'm not telling that your homescreen-service
> >>> equivalent have to start the applications.
> >>>
> >>> (snip)
> >>>  
> >>>>> I realize that a lexicon is missing! It is so easy to confuse
> >>>>> things here. Current AGL has:
> >>>>>
> >>>>>    - the IVI-shell
> >>>>>    - the windowmanager service
> >>>>>    - the homescreen service
> >>>>>    - the homescreen application
> >>>>>
> >>>>> My understanding was that you, collabora, rework the shell and
> >>>>> the windowmanager service. It implies modification to other
> >>>>> services and applications, of course.  
> >>>>
> >>>> That's correct. I guess I'm also mashing the notion of a service
> >>>> with that of an application while you seem to make a clear
> >>>> separation of those. So far, current design removes the IVI
> >>>> shell the window manager service entirely and for now homescreen
> >>>> is just an application, which serves the role of the shell.
> >>>>
> >>>> Your description is missing the compositor which is still
> >>>> present, albeit in a stripped down form. The compositor is the
> >>>> one handling the switching but the command to spawn/switch apps
> >>>> comes from homescreen. Do
> >>>> note that there's no code in the compositor for launching apps.
> >>>>
> >>>> That is why it seems quite peculiar to me to have the compositor
> >>>> chat with the policy manager if it can display or not the
> >>>> surface. As homescreen serves the role of the shell, it *should*
> >>>> always be present, even if you start apps manually. I'm not 100%
> >>>> sure at this moment, but I
> >>>> don't believe you can display anything atm without homescreen
> >>>> being present. It then stands that the policy check should also
> >>>> happen in homescreen and not the compositor itself. But for now
> >>>> this is something that I need verify, before making any other
> >>>> speculation :-).  
> >>>
> >>> Understood, but... So what you call homescreen is the policy
> >>> manager or more clearly speaking, the window manager. I'm not
> >>> sure of how you intend to separate that from homescreen. IMHO the
> >>> homescreen should not be the window manager. I mean that policy
> >>> should not be in the homescreen. You need to clarify things
> >>> because I'm getting lost.  
> >>
> >> IMO the policy manager needs to be a distinct entity where other
> >> services (like homescreen, for instance) is able to talk to. It
> >> should also be connected to policy database (which seems to be
> >> represented by cynagorad).
> >>
> >> I'm advocating for a distinct entity as I don't think it is a good
> >> design to encompass mostly related graphic parts with security
> >> management, or security at all for that matter. I understand the
> >> need to have this integration and I agree with it, but I also get
> >> the feeling you might want to have independent services. And
> >> services/daemon talking to each other using some kind of a channel
> >> seems the unix way of doing things.
> >>
> >> In this sense I believe the shell needs to delegate the permission
> >> check to the policy manager. The shell only needs to "translate"
> >> the resources being accessed to that the policy manager
> >> understands.  
> > 
> > The wayland architectural pitch
> > https://wayland.freedesktop.org/architecture.html !!! I'm thinking
> > that it is very blur: it probably presume that window manager (WM)
> > is a client that pilots the compositor and implement a policy
> > engine (PE), also probably but not mandatory. In that case, the
> > WM/PE has to identify clients. How? Either the client establishes a
> > connection to the WM/PE or the compositor helps.  
> 
> Regarding the policy manager, been having some chats with Daniel, and
> we agreed that if there's distinct code-separation we can integrate
> the policy manager bit in the compositor (which we should be able to
> do, so there's no issue with it).

Ack

> For now, I resorted to add a  switch in the ini file of the
> compositor, such that if enabled, will  by default, switch to newly
> created applications. But this can only happen if there's a agl-shell
> client binded and has a background set (in other words: homescreen
> has to be started/on, or clients have to have a background set).

Agreed.

> >> Do note that the authentication part is also in limbo for weston
> >> at the moment of speaking. If you think you have some spare hours
> >> to go over I invite you to browse:
> >> https://gitlab.freedesktop.org/wayland/weston/issues/206. Properly
> >> identifying clients (authentication) is the most hard thing to do.
> >> I'm mostly hoping that smack could be answer here but I have
> >> literally knowledge about it.  
> > 
> > Is there a missing (important) word in that previous sentence? Like
> > a "no"? I'm about to read the thread that seems clearly in our
> > scope of interest.  
> 
> Yeah, apologies. There's a strong "no" there. But I think I've cleared
> this as well (in the previous meeting and it seems it relies on the
> policy specified by SMACK).

In the context of AGL, Smack label is used to identify the client
application and/or its domain. So it is used to check permissions. We
recently added a parallel mechanism for authorization that use tokens.

Best regards
José Bollo

> >> And indeed, homescreen being the shell is the windowmanger. We get
> >> lost in the terminology due the fact that wayland works
> >> differently than X. Another example, or analogy is that
> >> gnome-shell is the window manager of gnome, with mutter being the
> >> wayland compositor (which is the compositor for gnome3).
> >> gnome-shell is the one responsible for launching apps and
> >> switching between windows which is exactly what homescreen is at
> >> this stage.
> >>
> >> Due to time constrains I never got the chance to check and dive
> >> deeper into windowmanager and previous homescreen version, their
> >> purpose and how they were integrated.
> >>
> >> Here's a short demo of what it looks like now:
> >> https://drive.google.com/file/d/1WxRBM_vkxpdDUQ3W4n253vNAuhv59Qlp/view?usp=sharing
> >>
> >>
> >> (homescreen with a background, top panel, bottom panel, all of them
> >> being assigned individually from Qt QMLs). A few apps are started
> >> by homescreen and switched to using the top panel.  
> > 
> > Nice to share that state of work.
> >   
> >>>> As we talk about services, the compositor allows only *one*
> >>>> client to bind to the agl-shell interface (I guess the reason
> >>>> for only allowing one client to do this is because otherwise
> >>>> other apps can hijack the functionality as they please), which
> >>>> means we can't have homescreen both
> >>>> being an application and as service (assuming that service means
> >>>> actually to be that binding library).  
> >>>
> >>> Agreed. 2 components are better.
> >>>  
> >>>> So this is another point which should be clarified. The only way
> >>>> to expose the request for switching  applications and in the
> >>>> same bind to the protocol interface translates to the fact that
> >>>> homescreen can only be a binding library.  
> >>>
> >>> That is a matter of choice. It can also be a wayland interface.  
> >> Yeah, you could. Not sure if that's a good design though. This
> >> kinda forces the compositor to chat with the policy manager to
> >> determine if the application is indeed allowed to bind to the
> >> interface.
> >>
> >> Do you have some examples here where this could be useful? A more
> >> palpable example, real use-case scenario? I gather that for
> >> demo/debugging purpose you might want this, but this can disabled
> >> in production entirely.
> >>
> >> And in production aren't vendors going to use homescreen (by that
> >> I also mean the wrappers for starting/switching apps?) directly?  
> > 
> > Pure display applications, let say a game, should be easily ported
> > to AGL. Using the wayland standard interface mechanism is probably
> > easier in that case for tinkering the app to AGL.
> > 
> > Anyway I am not expert of the subject and would be very happy to
> > read the discussion on the mailing list of AGL -and possibly
> > participate-.  
> 
> Yeah, I think I got a few points as well from the previous meet about
> it as well: clients have to be able to show windows as they please.
> 
> > 
> > Best regards
> > José
> >   
> >>>> There's also the elephant in the room: authenticating
> >>>> homeescreen with the compositor would be something worthwhile to
> >>>> keep in mind. Compositor
> >>>> with homescreen would be ideal (so each against eachother). I'd
> >>>> say to burn this bridge when we get there.  
> >>>
> >>> Agreed.
> >>>
> >>> (snip)
> >>>  
> >>>> For the moment, I would say to have this option configurable
> >>>> from the [shell] section in the ini file. That is, when this
> >>>> option is on, XDG surface will be automatically shown by the
> >>>> compositor, otherwise it requires a switch either exposed by
> >>>> homescreen or done by homescreen directly. See also my previous
> >>>> comment about this, as it it most likely require homescreen to
> >>>> be running as well. We'll get back on this once I have another
> >>>> look.  
> >>>
> >>> I like the proposal  
> >>
> >> Sounds like a plan. Will look into it.
> >>  
> >>>
> >>> Best regards
> >>> José  
> >>  
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8023): https://lists.automotivelinux.org/g/agl-dev-community/message/8023
Mute This Topic: https://lists.automotivelinux.org/mt/69932650/2167316
Group Owner: agl-dev-community+owner@xxxxxxxxxxxxxxxxxxxxxxxxx
Unsubscribe: https://lists.automotivelinux.org/g/agl-dev-community/leave/4543822/883735764/xyzzy  [list-automotive-discussions82@xxxxxxxxxxx]
-=-=-=-=-=-=-=-=-=-=-=-