af-binder and af-main start-up issues and windowmanager/libhomescreen dependencies
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:Regarding this part, on launching applications, I've been having someHi Jose,Hi Marius,
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
Launcher application also seems to use this agl-service-homescreen for
it, as to retrieve the runnables applications array and also calls into
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)Regarding the policy manager, been having some chats with Daniel, and weThe wayland architectural pitchRoger that.I should have found it (me or grep)! strange! but ok I'm hand on now.It looks like `afb_xreq_reply_insufficient_scope()` from af-binder. MyOn a closely related subjection, or more in the form of permissions.I can not find "insufficient-scope" in any source. Do you know what
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).
Yeah, apologies. There's a strong "no" there. But I think I've clearedDo note that the authentication part is also in limbo for weston at theIs there a missing (important) word in that previous sentence? Like a
this as well (in the previous meeting and it seems it relies on the
policy specified by SMACK).
Yeah, I think I got a few points as well from the previous meet about itAnd indeed, homescreen being the shell is the windowmanger. We get lostNice to share that state of work.
as well: clients have to be able to show windows as they please.
On Mon, 20 Jan 2020 16:49:27 +0200
"Marius Vlad" <firstname.lastname@example.org> wrote:
Hi Jose,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:These service are designed to run on top of the AGL framework binderOn 10/01/2020 17:45, Marius Vlad wrote:Regarding this part, on launching applications, I've been having someHi Jose,Hi Marius,
(/usr/bin/afb-daemon) and are coded as AGL bindings. It use the
interface that the binder offers to them. Here the function
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 withYou 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'tI 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 modifyingSeveral 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
To give you a better view of the things, if agl-service-homescreenThen 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? IfIt depends on what Wayland/Weston/agl-shell expects. But it should work
with pointer's values.
AckRegarding the policy manager, been having some chats with Daniel, andThe wayland architectural pitchIMO the policy manager needs to be a distinct entity where otherSee above. But I'm not telling that your homescreen-serviceOn current AGL, homescreen does not run as root. So it isAlright I'll check to see, but it kinda seems it needs to be
For now, I resorted to add a switch in the ini file of theAgreed.
In the context of AGL, Smack label is used to identify the clientYeah, apologies. There's a strong "no" there. But I think I've clearedDo note that the authentication part is also in limbo for westonIs there a missing (important) word in that previous sentence? Like
application and/or its domain. So it is used to check permissions. We
recently added a parallel mechanism for authorization that use tokens.
Yeah, I think I got a few points as well from the previous meet aboutAnd indeed, homescreen being the shell is the windowmanger. We getNice to share that state of work.