| kdub_ | color me annoyed | 00:44 |
|---|---|---|
| * kdub_ has to go bump the android headers package | 00:45 | |
| === chihchun is now known as chihchun_afk | ||
| * RAOF resists the urge to write std::zip and std::infinite_seq | 02:24 | |
| 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:41 |
| vila | anpok_: hey ! | 06:42 |
| RAOF | anpok_: Yes, ish. | 06:42 |
| anpok_ | ok, ish | 06:43 |
| RAOF | anpok_: We certainly want to let _clients_ render with egl/gles2 | 06:43 |
| 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:44 |
| anpok_ | yeah, but there is still usc.. | 06:45 |
| RAOF | Right. usc shouldn't use EGL in the swrast case. | 06:46 |
| 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:47 |
| anpok_ | hm or we make it a separate platform, but share a lot of code with the mesa platform .. | 06:49 |
| anpok_ | and if we want to provide the same for android .. come up with something similar | 06:50 |
| anpok_ | hm but that could be a per-output decision | 06:51 |
| RAOF | I don't think it's a per-output decision? | 06:59 |
| RAOF | Although you're right; it both is and isn't a new platform. | 07:00 |
| 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:01 |
| 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:08 |
| anpok_ | ack | 07:09 |
| alan_g | dednick: welcome back. Got time to discuss "trust[ed] [prompt] session" terminology? | 10:24 |
| dednick | alan_g: hi. sure | 10:25 |
| 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:28 |
| alan_g | dednick: ^ | 10:37 |
| 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:39 |
| dednick | and tvoss started to use the terminology of "trusted particiapant" a while later. | 10:40 |
| 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:41 |
| dednick | the participant(s) is the "trust promp provider" in the wiki as far as i understand | 10:42 |
| alan_g | BRB | 10:43 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| dednick | alan_g: well if it's helping to make sense of it, I can't really complain. | 10:49 |
| alan_g | dednick: the problem is that when the code doesn't match the documentation people don't trust either | 10:50 |
| alan_g | And the Wiki and "Application Embedding & Trusted Helpers" documents are what people look at to make sense of the MP | 10:51 |
| 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:52 |
| 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:55 |
| 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:56 |
| 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 | 10:58 |
| alan_g | So there's significance to the order things are processed in for_each_participant_in_trust_session()? | 11:00 |
| dednick | in the shell there is. | 11:01 |
| alan_g | OK, then we need an acceptance test that spells out that requirement. | 11:02 |
| alan_g | But wouldn't it be simpler to just query the App and the TPP? Like we do the trust helper? | 11:03 |
| 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:04 |
| 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:05 | |
| dednick | alan_g: as far as I understood, all part of one TPS. see page 4/5 of the google doc. | 11:06 |
| dednick | the gallery, content hub and FB will all have surfaces. | 11:07 |
| alan_g | I see it. But don't really follow how to make it work. | 11:09 |
| 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:10 |
| 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:11 |
| 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:13 |
| 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:14 |
| 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:16 |
| dednick | alan_g: i'm not really sure how this fits into the trust store model though... | 11:17 |
| 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:18 |
| alan_g | Yes. I'm starting to think we have "prompt client", "prompt session", "prompt helper" and "prompt provider" - and trust is implicit. ;) | 11:20 |
| dednick | indeed. | 11:21 |
| dednick | i've been implementing application embedding using security terminology. | 11:23 |
| alan_g | The terminology used is a big hurdle to understanding what the code supports. | 11:25 |
| dednick | right. but this was supposed to be an initial phase of something that is "trust" related. | 11:27 |
| alan_g | But really, the "trust" part isn't implemented in Mir. And "trust"/"trusted" in the names is confusing every reviewer. | 11:31 |
| 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:34 |
| 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:36 |
| dednick | perhaps the shell. | 11:38 |
| alan_g | dednick: I assume the same place that decides who can connect, configure_display, or screencast | 11:39 |
| 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:41 |
| dednick | but since we dont call them "trusted_screencast"... | 11:42 |
| 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:43 |
| alan_g | Well, maybe. | 11:44 |
| 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:46 |
| alan_g | than what we have now | 11:47 |
| dednick | +1 | 11:49 |
| alan_g | alf_: anpok_ Opinions? ^^ | 11:49 |
| alf_ | alan_g: dednick: what about "interactive session"? Does it make sense to differentiate between the two in mir? | 11:50 |
| 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:51 |
| 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:52 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| === alan_g is now known as alan_g|lunch | ||
| alan_g|lunch | If Saviq agrees then we can convince tvoss | 11:58 |
| 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:03 |
| alf_ | dednick: assuming that what is expected from mir doesn't change for each use case | 12:04 |
| alf_ | anpok_: alan_g|lunch: ^^ | 12:05 |
| 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:09 |
| 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:29 |
| 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:30 |
| 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:31 |
| anpok_ | but I am all for not using trust - as it seems to be a distraction of what this functionality is about.. | 12:32 |
| anpok_ | which is providing and dealing with some sort of grouped session based on | 12:33 |
| anpok_ | existing sessions.. | 12:33 |
| alf_ | anpok_: it is an unfortunate and confusing coincidence that we are using the term 'session' in Mir to represent mir clients. | 12:35 |
| anpok_ | why is it unfortunate? I think we should try to treat (trust*) session like a session. | 12:37 |
| anpok_ | ah ok .. that would not reflect the nesting | 12:38 |
| === alan_g|lunch is now known as alan_g | ||
| 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:43 |
| 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". | 12:49 |
| === danielg4 is now known as DonkeyHotei | ||
| === pete-woods is now known as pete-woods-lunch | ||
| === olli_ is now known as olli | ||
| camako | alan_g, it seems we are finally getting somewhere with the terminology | 14:18 |
| 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:19 |
| camako | alan_g, but I don't remember reading abt "interaction session"... Could you provide a link to the doc? | 14:20 |
| alan_g | camako: https://wiki.ubuntu.com/Security/TrustStoreAndSessions | 14:21 |
| alan_g | "Trusted Interaction Session" | 14:21 |
| === chihchun_afk is now known as chihchun | ||
| camako | Oo this doc.. | 14:22 |
| alan_g | Too many documents not enough acceptance tests | 14:23 |
| camako | alan_g, ok now I remember reading about it... | 14:25 |
| 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:26 |
| alan_g | "chrome" is shiny stuff | 14:27 |
| 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:28 |
| alan_g | alf_: ^^ | 14:29 |
| === pete-woods-lunch is now known as pete-woods | ||
| camako | "prompt" is somewhat limiting though... | 14:29 |
| alan_g | dednick: anpok ^^ | 14:30 |
| === alan_g is now known as alan_g|tea | ||
| 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:31 |
| DonkeyHotei | alf_: bug 1304959 | 14:32 |
| ubot5 | 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:32 |
| camako | "Prompt" also sort of means "on top of everything" | 14:33 |
| alf_ | DonkeyHotei: We are working on using software GL rendering through Mesa/llvmpipe if no HW accel is available | 14:35 |
| alf_ | anpok: ^^ | 14:35 |
| DonkeyHotei | alf_: how soon? | 14:36 |
| dednick | "embedding/ed session" ? | 14:36 |
| === alan_g|tea is now known as alan_g | ||
| * anpok waves | 14:39 | |
| 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:40 |
| === dandrader is now known as dandrader|afk | ||
| 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:43 |
| alan_g | True - it implies the implementation, not the requirement | 14:44 |
| camako | How about "cooperative session"? | 14:44 |
| 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:45 |
| 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:46 |
| dednick | possibly could be deriving from a common focusable object in the future. but it hasn't really been discussed. | 14:47 |
| * 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:48 |
| 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:50 |
| 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:51 |
| dednick | i hadn't noticed! :) | 14:52 |
| alan_g | find -name \*.cpp -or \*.h | xargs sed --in-place ... | 14:52 |
| 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:54 |
| alan_g | I don't mind doing the renames - if we are agreed on the naming scheme | 14:55 |
| kgunn | is tvoss hiding ? :P | 14:56 |
| kgunn | wonder if tvoss cares about the naming... | 14:56 |
| alan_g | kgunn: we spoke to tvoss yesterday. And he's been absent from here ever since | 14:57 |
| 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:58 |
| 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 | 14:59 |
| dednick | alan_g: are we going for "prompt session participants", or "application + prompt provider"? | 15:00 |
| alan_g | dednick: I'd suggest application() helper() and for_each_provider() | 15:03 |
| alan_g | but that's a slightly independent change | 15:03 |
| dednick | alan_g: sure. | 15:05 |
| 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:07 |
| === dandrader|afk is now known as dandrader | ||
| DonkeyHotei | anpok: i believe mine is n450 with i945 graphics | 15:08 |
| anpok | intel has some intersting naming schemes ther gma950 i945 .. 945G .. but yes.. i will try this evening | 15:10 |
| DonkeyHotei | i already tried, black screen | 15:12 |
| DonkeyHotei | it tries to use libegl which fails | 15:13 |
| 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:54 |
| ubot5 | Ubuntu bug 1328952 in Mir "Compositing with invisible surfaces" [High,Fix committed] | 15:54 |
| DonkeyHotei | anpok: bug 1304959 | 15:55 |
| ubot5 | 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 | 15:55 |
| 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:09 |
| kdub_ | specifically, I need to use the hwc_layer_1_t::planeAlpha field introduced in android-4.3 | 16:10 |
| kdub_ | https://android.googlesource.com/platform/hardware/libhardware/+/android-4.3.1_r1/include/hardware/hwcomposer.h | 16:11 |
| 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:15 |
| kdub_ | rsalveti, great, anything I can do to help? | 16:18 |
| 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:19 |
| ogra_ | kgunn, will reverting split greeter also revert the boot animation ability ? (that came in alongside) | 16:24 |
| kdub_ | rsalveti, here's the bug: https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1328971, can't assign/set priority on it though | 16:26 |
| ubot5 | Ubuntu bug 1328971 in libhybris (Ubuntu) "android 4.4 headers needed for hwc_layer_1_t::planeAlpha field" [Undecided,New] | 16:26 |
| 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:34 |
| 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:35 |
| 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:36 |
| kdub_ | cool, just curious | 16:37 |
| mterry | That the USC knows about especially | 16:37 |
| === alan_g is now known as alan_g|EOD | ||
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|lunch | ||
| rsalveti | kdub_: thanks | 17:39 |
| === dandrader|lunch is now known as dandrader | ||
| kdub_ | AlbertA, we don't have a way to discern whether abgr_8888 has premultiplied alpha or not, do we? | 18:41 |
| 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 | 18:50 |
| anpok | kdub_: but if it is a buffer from a client | 19:02 |
| anpok | we are safe to assume that | 19:02 |
| kdub_ | we probably assume that, but aren't safe to do so | 19:04 |
| anpok | well safer than assuming the opposite | 19:12 |
| === dandrader is now known as dandrader|afk | ||
| AlbertA | kdub_: no | 19:28 |
| AlbertA | kdub_: you need to? | 19:28 |
| kdub_ | AlbertA, eh, probably will go on the 'todo' pile | 19:33 |
| AlbertA | kdub_: in any case, we now assume pre-multiplied instead of straight alpha | 19:34 |
| AlbertA | kdub_: which makes more sense | 19:34 |
| kdub_ | right | 19:40 |
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!