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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8014): https://lists.automotivelinux.org/g/agl-dev-community/message/8014 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] -=-=-=-=-=-=-=-=-=-=-=-
Attachment:
signature.asc
Description: OpenPGP digital signature
