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