[00:44] color me annoyed [00:45] * kdub_ has to go bump the android headers package === chihchun is now known as chihchun_afk [02:24] * RAOF resists the urge to write std::zip and std::infinite_seq [06:41] hi vila [06:41] RAOF: do we actually want to use egl/gles2 in cases which we would have to fall back to swrast? [06:42] anpok_: hey ! [06:42] anpok_: Yes, ish. [06:43] ok, ish [06:43] anpok_: We certainly want to let _clients_ render with egl/gles2 [06:44] You're correct that we don't particularly want EGL on the final composition pass, though. [06:44] Except that Unity8 uses it for that :) [06:45] yeah, but there is still usc.. [06:46] Right. usc shouldn't use EGL in the swrast case. [06:47] It should instead be using something designed for it, like pixman. [06:47] but that cpu based composition pass is not really a new graphics platfrom, but rather a fall back option for all our platforms [06:49] hm or we make it a separate platform, but share a lot of code with the mesa platform .. [06:50] and if we want to provide the same for android .. come up with something similar [06:51] hm but that could be a per-output decision [06:59] I don't think it's a per-output decision? [07:00] Although you're right; it both is and isn't a new platform. [07:01] It shares the ‘how do we get this buffer to the physical display’ part of an existing platform, while adding a shared ‘how do I composite these things’ bit. [07:01] boost::asio is maddeningly documented. [07:08] RAOF: hm in case of an usb display [07:08] ...you want to render on the gpu, and shuttle buffers to the usb display. [07:09] ack [10:24] dednick: welcome back. Got time to discuss "trust[ed] [prompt] session" terminology? [10:25] alan_g: hi. sure [10:28] You seem to disagree with the terminology in https://wiki.ubuntu.com/Security/TrustStoreAndSessions - or do I misunderstand? [10:28] Which do you think is the right document to base the terminology on? [10:37] dednick: ^ [10:39] alan_g: ... well i think the whole "prompt" thing may be a bit specific, which is why I dropped it. I thought that was more directed to the use case of a dialog popping up asking the user if it wants to allow access to a resource (UAC) [10:40] and tvoss started to use the terminology of "trusted particiapant" a while later. [10:41] dednick: OTOH a discussion of "trust sessions" and "trusted sessions" is confusing for everyone. It would make sense as "trusted prompt sessions" and "trusted prompt providers" [10:42] the participant(s) is the "trust promp provider" in the wiki as far as i understand [10:43] BRB === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [10:49] alan_g: well if it's helping to make sense of it, I can't really complain. [10:50] dednick: the problem is that when the code doesn't match the documentation people don't trust either [10:51] And the Wiki and "Application Embedding & Trusted Helpers" documents are what people look at to make sense of the MP [10:52] alan_g: sure. [10:52] Also, you seem to have both the app and the TPP as "trusted session" without distinguishing them. Can that be right? [10:55] I've seen "trusted participant" in the code (but not noticed it in the docs) - is it just a TPP or can it be the App too? [10:55] alan_g: i didn't see any reason for distinguishing the participants of the trust session. [10:56] both app and tpp are participants of a trust session. [10:56] "According to the description given before, three participants of a trust prompt session can be identified" [10:56] dednick: but they have different roles - the tpp is overlaid on the app [10:58] alan_g: right, but when we're talking about layering, it's just an order. app first, then tpp. [10:58] ack. But I take that as descriptive not introducing it as a term [11:00] So there's significance to the order things are processed in for_each_participant_in_trust_session()? [11:01] in the shell there is. [11:02] OK, then we need an acceptance test that spells out that requirement. [11:03] But wouldn't it be simpler to just query the App and the TPP? Like we do the trust helper? [11:04] alan_g: hm. i guess putting that kind of assumption in is not really a great idea, but it's a bit of a necessity when dealing with multiple layers of tpp's. Perhaps we should add another "type" of participant (as we did for trust_helper). [11:05] when inserting/querying in the container/manager i mean [11:05] * alan_g doesn't grok "multiple layers of tpp's" - are they all part of one TPS, or are they nested TPS's? [11:06] alan_g: as far as I understood, all part of one TPS. see page 4/5 of the google doc. [11:07] the gallery, content hub and FB will all have surfaces. [11:09] I see it. But don't really follow how to make it work. [11:10] fyi, at the moment, i believe the "select dest" is done by the gallery, so there aren't any surfaces on the content hub. [11:11] I can see race conditions adding the different TPPs (they need not be added in the order the TPH adds them if they've not connected to Mir.) [11:13] Although that probably doesn't matter - I imagine each would be added in response to a user action and that will serialise them. [11:14] 1) gallery initiates content hub though dbus/whatever [11:14] 2) content hub creates trust session with gallery app id. [11:14] 3) content hub calls new fd for trust session (2 fds) [11:14] 4) content hub creates session for dest picker (with fd from 3) [11:14] 5) user see's dest picker overlayed on top of gallery (due to trust session) [11:14] 6) user picks face book as destination [11:14] 7) content hub intiates facebook app with second fd from 3 [11:14] 8) FB starts and is overlayed on top of content hub session. [11:16] alan_g: yeah, race will exist if you add 2 participants for apps which we start. but the use cases for app starts are in response to user action. [11:17] alan_g: i'm not really sure how this fits into the trust store model though... [11:18] LOL [11:18] theres a bit of a disconnect between the security side of this, and the user side of it. [11:20] Yes. I'm starting to think we have "prompt client", "prompt session", "prompt helper" and "prompt provider" - and trust is implicit. ;) [11:21] indeed. [11:23] i've been implementing application embedding using security terminology. [11:25] The terminology used is a big hurdle to understanding what the code supports. [11:27] right. but this was supposed to be an initial phase of something that is "trust" related. [11:31] But really, the "trust" part isn't implemented in Mir. And "trust"/"trusted" in the names is confusing every reviewer. [11:34] yeah. i have no idea how the security bit is supposed to hook into this. perhaps we should drop the "trust" for "prompt". Trust(ed)Session/Helper/Participant -> PromptSession/Helper/Participant [11:36] I assume it "hooks in" by controlling which connections can create a prompt session. [11:36] alan_g: i meant where it's going to live if not mir. [11:38] perhaps the shell. [11:39] dednick: I assume the same place that decides who can connect, configure_display, or screencast [11:41] alan_g: right. but at that point, it does become "trusted" [11:41] Yes, the shell provides a custom SessionAuthorizer to control session permissions. (Or Mir defaults to being trusting.) [11:42] but since we dont call them "trusted_screencast"... [11:43] ...we should call it "prompt_session_is_allowed()" [11:43] but now we don't match the documentation anymore :) [11:43] so lets change the documentation! [11:44] Well, maybe. [11:46] But it would be easier to explain [11:46] "application" => "application" [11:46] "trusted prompt session" => "prompt session" [11:46] "trusted helper" => "prompt helper" [11:46] "trusted prompt provider" => "prompt provider" [11:47] than what we have now [11:49] +1 [11:49] alf_: anpok_ Opinions? ^^ [11:50] alan_g: dednick: what about "interactive session"? Does it make sense to differentiate between the two in mir? [11:51] s/interactive session/interaction session/ [11:51] which two? [11:51] alan_g: dednick: in the docs there is also an "trusted interaction session" [11:52] alan_g: dednick: so "trusted interaction session" vs "trusted prompt session" [11:52] * alan_g thinks there are two many docs to remember [11:52] alan_g: hm: i would have said embedded before "interaction" [11:52] is prompting the user for decisions the only relavant use case? [11:52] alf_: ^ [11:54] anpok_: at the moment, yes; can't say about the furture though. [11:54] I like "embedding session" - but worry where to find it in the docs (without rewriting them all) [11:55] It is always good to stick with the use cases we know about. [11:55] funny - then the overall purpose - the reason why focus management/surface order needs to be aware of it - suddenly becomes obvious [11:56] so I would really prefer that naming, if it is not a simplification or only a small aspect of the problems to solve. [11:57] I've got to go make lunch (it is my turn) please reach a consensus. [11:57] I'll catch up when I get back [11:57] i think we should check with tvoss before making the decision though. Since he has the grander plan in mind. === alan_g is now known as alan_g|lunch [11:58] If Saviq agrees then we can convince tvoss [12:03] dednick: I wasn't proposing "interaction session". I was referring to "trusted interaction session" use case presented in the docs, and whether it would be make sense to have a "prompt session" in mir instead of something that would cover all use cases. [12:04] dednick: assuming that what is expected from mir doesn't change for each use case [12:05] anpok_: alan_g|lunch: ^^ [12:09] dednick: (repeating since you probably missed this) I wasn't proposing "interaction session". I was referring to "trusted interaction session" use case presented in the docs, and whether it would be make sense to have a "prompt session" in mir instead of something that would cover all use cases. [12:09] dednick: assuming that what is expected from mir doesn't change for each use case [12:29] alf_: hm looking at the docs it is hard to see whether a (trust*) session for prompts behaves different than a (trust*) session for 'interaction' [12:30] i think they might differ in the used surface properties/window types? [12:30] anpok_: yeah that was my point, they seem similar enough not to warrant a special distinction (sorry I think I expressed this the other way around than I meant) [12:31] anpok_: i.e., we shouldn't have a "prompt session" in mir, but rather something more general [12:31] so introducing prompt as a term for both is maybe not the right solution [12:31] yes [12:32] but I am all for not using trust - as it seems to be a distraction of what this functionality is about.. [12:33] which is providing and dealing with some sort of grouped session based on [12:33] existing sessions.. [12:35] anpok_: it is an unfortunate and confusing coincidence that we are using the term 'session' in Mir to represent mir clients. [12:37] why is it unfortunate? I think we should try to treat (trust*) session like a session. [12:38] ah ok .. that would not reflect the nesting === alan_g|lunch is now known as alan_g [12:43] Anyone that thinks "it is a an unfortunate and confusing coincidence that we are using the term 'session' in Mir to represent mir clients" should join the "scene::Session => scene::Application" discussion. [12:49] I'm afraid that "interaction session" might be premature generalization. If when we come to "interaction session" use cases we find that we can implement a "prompt session" using it then we can provide a new API and deprecate the old one. If we use "interaction session" now and when we come to the non-prompt use cases we we cannot generalise then we have "painted ourselves into a corner". === danielg4 is now known as DonkeyHotei === pete-woods is now known as pete-woods-lunch === olli_ is now known as olli [14:18] alan_g, it seems we are finally getting somewhere with the terminology [14:19] camako: I hope so. I don't think it is quite settled yet. [14:19] can the reliance on libegl be eliminated? [14:20] alan_g, but I don't remember reading abt "interaction session"... Could you provide a link to the doc? [14:21] camako: https://wiki.ubuntu.com/Security/TrustStoreAndSessions [14:21] "Trusted Interaction Session" === chihchun_afk is now known as chihchun [14:22] Oo this doc.. [14:23] Too many documents not enough acceptance tests [14:25] alan_g, ok now I remember reading about it... [14:26] alan_g, I don't know what this phrase means, "Potentially system chrome"? [14:26] Dammit! "Reading symbols from bin/mir_unit_tests...Segmentation fault (core dumped)" [14:27] "chrome" is shiny stuff [14:28] My feeling is we should go with the use case we understand (prompt session) [14:28] At least we all agree to drop "trust(ed)".. [14:29] alf_: ^^ === pete-woods-lunch is now known as pete-woods [14:29] "prompt" is somewhat limiting though... [14:30] dednick: anpok ^^ === alan_g is now known as alan_g|tea [14:31] could get obsolete/nonsensical as soon as another use-case emerges [14:31] DonkeyHotei: @libegl, no, at least not at the moment... we depend on EGL throughout Mir [14:31] DonkeyHotei: what do you want to do? [14:31] ... which interaction session is another use-case but a bit nebulous [14:32] alf_: bug 1304959 [14:32] bug 1304959 in mir (Ubuntu) "No support for older intel hardware, or no clear message about not being supported." [Medium,Confirmed] https://launchpad.net/bugs/1304959 [14:33] "Prompt" also sort of means "on top of everything" [14:35] DonkeyHotei: We are working on using software GL rendering through Mesa/llvmpipe if no HW accel is available [14:35] anpok: ^^ [14:36] alf_: how soon? [14:36] "embedding/ed session" ? === alan_g|tea is now known as alan_g [14:39] * anpok waves [14:40] I'm afraid that "embedding/ed session" might be premature generalization. If when we come to "embedding/ed session" use cases we find that we can implement a "prompt session" using it then we can provide a new API and deprecate the old one. If we use "embedding/ed session" now and when we come to the non-prompt use cases we we cannot generalise then we have "painted ourselves into a corner". === dandrader is now known as dandrader|afk [14:43] But if we feel we know enough for confidence about the future I'll wait and see. [14:43] yeah embedded/ing also has the connotation that things are inside other stuff.. In a general sense, it may not always be the case [14:43] alan_g: camako: dednick: I can vote for using prompt now and having a rename while we add new stuff to it... the only thing I am still missing is that the functionality is about some sort of created by multiple processes.. and prompt does not say that [14:44] True - it implies the implementation, not the requirement [14:44] How about "cooperative session"? [14:45] I think it 'd cover both the interaction and prompt [14:45] That's so general it says very little [14:45] hm. bit too general [14:45] the other thing ..are we going to see further changes that will make sessions and sessions look the same from the server side api? [14:46] a session looks pretty much like a session to me :)_ [14:46] you mean a trust session and a session? [14:46] i erased the word trust already :) [14:46] A [trusted] prompt session [14:47] possibly could be deriving from a common focusable object in the future. but it hasn't really been discussed. [14:48] * alan_g has tried to persuade tvoss that "session" was a bad name for it. And persuade mir developers that "session" is a bad name... [14:48] DonkeyHotei: there is no mesa dri driver for n450? [14:48] should be [14:48] "trust session" and "interaction session" have little in common, so whatever term we choose, it will have to be pretty general - and won't explain either... [14:50] I vote for "prompt session" now [14:50] "prompt session" for me too . mainly because I want the pain to end. :) [14:51] dednick: who said the pain would end? [14:51] ;^) [14:51] well. actually it will just begin since, that's when the renaming game starts. [14:51] Renaming is easy. I do it all the time. [14:52] i hadn't noticed! :) [14:52] find -name \*.cpp -or \*.h | xargs sed --in-place ... [14:54] prompt session sounds good, then [14:54] there's a lot of trust around. trust session, trusted session, [trusted] participants, trust session manager, trust helper, trust listener, trust session container. trust session events, blah blah [14:55] I don't mind doing the renames - if we are agreed on the naming scheme [14:56] is tvoss hiding ? :P [14:56] wonder if tvoss cares about the naming... [14:57] kgunn: we spoke to tvoss yesterday. And he's been absent from here ever since [14:58] camako: alan_g dednick ...so basically, we're scrubbing trust, replacing with prompt...in all instances of trust [14:58] alan_g: it's ok. it'll ease me back into working after a bit too long in the sun :) [14:58] kgunn, my understanding is that [14:58] we are using this name in our code [14:59] kgunn: for mir yes [14:59] not changing tvoss' doc [14:59] kgunn: not quite that simple. But that's a big chunk of it [14:59] ack...i figure some paradigms won't match quite that easy [14:59] gotta get a coffee, i'll be on standup in minutes [15:00] alan_g: are we going for "prompt session participants", or "application + prompt provider"? [15:03] dednick: I'd suggest application() helper() and for_each_provider() [15:03] but that's a slightly independent change [15:05] alan_g: sure. [15:07] DonkeyHotei: ok - I think I have an even older netbook than that, which uses a similar gpu [15:07] but havent tried mir on it yet. === dandrader|afk is now known as dandrader [15:08] anpok: i believe mine is n450 with i945 graphics [15:10] intel has some intersting naming schemes ther gma950 i945 .. 945G .. but yes.. i will try this evening [15:12] i already tried, black screen [15:13] it tries to use libegl which fails [15:54] DonkeyHotei: so egl/glesv2 usage would always fail on 945? [15:54] heh, a fix committed before the an external bug: https://bugs.launchpad.net/mir/+bug/1328952 yippeee [15:54] Ubuntu bug 1328952 in Mir "Compositing with invisible surfaces" [High,Fix committed] [15:55] anpok: bug 1304959 [15:55] bug 1304959 in mir (Ubuntu) "No support for older intel hardware, or no clear message about not being supported." [Medium,Confirmed] https://launchpad.net/bugs/1304959 [16:09] rsalveti, any plans to get the android 4.3 headers from libhardware into the android-headers package? hit a snag with the api between 4.2 and 4.4 when trying to enable hwc alpha blending [16:10] specifically, I need to use the hwc_layer_1_t::planeAlpha field introduced in android-4.3 [16:11] https://android.googlesource.com/platform/hardware/libhardware/+/android-4.3.1_r1/include/hardware/hwcomposer.h [16:15] kdub_: goal is to update it to be based on 4.4, just never spent cycles on it as we didn't have any request for the update til now :-) [16:18] rsalveti, great, anything I can do to help? [16:19] kdub_: mind creating a bug and assigning that to me [16:19] ? [16:19] can take care of that later today [16:19] rsalveti, will do [16:19] thanks [16:24] kgunn, will reverting split greeter also revert the boot animation ability ? (that came in alongside) [16:26] rsalveti, here's the bug: https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1328971, can't assign/set priority on it though [16:26] Ubuntu bug 1328971 in libhybris (Ubuntu) "android 4.4 headers needed for hwc_layer_1_t::planeAlpha field" [Undecided,New] [16:34] ogra_: initially, we'd have to ask mterry about adding that animation into inproc greeter [16:34] suppose it might actually be easier [16:34] kgunn, i think u-s-c ships it atm, we could just not rip it out [16:34] kgunn, ogra_, no doesn't affect our ability there [16:34] (in terms of transitions) [16:34] mterry, great ! [16:34] ogra_, kgunn: we don't need to rip out any part of it, and animation doesn't care if it stops at split greeter or user session [16:35] yeah [16:35] thats what i thought [16:35] would be a shame to do RTM with a black screen through the whole boot [16:36] mterry, is boot animation that a usc client? or does it override the compositor for a bit [16:36] kdub_, it's written as a USC client [16:37] cool, just curious [16:37] That the USC knows about especially === alan_g is now known as alan_g|EOD === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|lunch [17:39] kdub_: thanks === dandrader|lunch is now known as dandrader [18:41] AlbertA, we don't have a way to discern whether abgr_8888 has premultiplied alpha or not, do we? [18:50] Another new GCC CI failure https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/385/console [18:50] syncfence.cpp:68 [19:02] kdub_: but if it is a buffer from a client [19:02] we are safe to assume that [19:04] we probably assume that, but aren't safe to do so [19:12] well safer than assuming the opposite === dandrader is now known as dandrader|afk [19:28] kdub_: no [19:28] kdub_: you need to? [19:33] AlbertA, eh, probably will go on the 'todo' pile [19:34] kdub_: in any case, we now assume pre-multiplied instead of straight alpha [19:34] kdub_: which makes more sense [19:40] right === dandrader|afk is now known as dandrader