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.


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()`.

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.

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?

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.

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.

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

(snip)

On a closely related subjection, or more in the form of permissions.

agl-compositor requires root as to vt switch (it needs to put the tty
in graphics mode), but homescreen can be start as agl-driver. Problem
is that I get a reply with "insufficient-scope" when trying to start
applications. Only if a ran homescreen as root I'm able to start
other
apps.

I can not find "insufficient-scope" in any source. Do you know what
emits that message?

It looks like `afb_xreq_reply_insufficient_scope()` from af-binder. My
speculation is that it comes from
`afb_auth_check_and_set_session_x2()`,
but I haven't traced it so far.

I believe that when using the proxy daemon (D-bus talked to
afm-user-daemon) that wasn't an issue as it as coming from D-bus and
not
straight from/with the unix socket.

I should have found it (me or grep)! strange! but ok I'm hand on now.
The term "scope" comes from OAuth2 specifications and translates to
permission in config.xml world. So yes look at how the config.xml file
of homescreen-service requires permissions to start widgets.
https://git.automotivelinux.org/apps/agl-service-homescreen/tree/package/root/config.xml

Roger that.

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).

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).

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).

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é

--
Marius Vlad

On Mon, 20 Jan 2020 16:49:27 +0200
"Marius Vlad" <marius.vlad@collabora.com> 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é