[00:04] <RAOF> Hm. When I'm blowing up code in 3rd_party I should probably move it under src/ shouldn't I.
[00:25] <kdub_> RAOF, tough call
[03:27] <RAOF> Oh, *that's* why you don't move anything from 3rd_party to src/
[03:27] <RAOF> It doesn't compile, because it generates hundreds of warning from ten or more different constructs. Hurray!
[04:46] <RAOF> “I killed him, cha cha cha”
[06:59] <RAOF> Alright. That's EOW for me. See yall Tuesday!
[08:31] <anpok_> alf_: would moving null, logging and lttng into report also imply that as another namespace level
[08:31] <anpok_> alf_: good morning
[08:56] <alf_> anpok_: good morning :) I would imagine something like mir::report in which null,logging,lttng implementation are all implementation details
[08:57] <alf_> anpok_: but not necessarily
[09:09] <anpok_> hi alan_g
[09:09] <alan_g> anpok_: ho
[09:09] <anpok_> alf_: implementation details - as there are no public headers? or no further namespaces?
[09:10] <alan_g> as in not needed by users of the class
[09:12] <anpok_> sure we will get there..
[09:13] <anpok_> just wanted to be sure about the details
[09:14] <alf_> anpok_: primarily the first, but also the second i.e., mir/report/default_configuration.cpp would implement all the_*_report() methods using class internal to the reporting component (logging, lttng)
[09:20] <anpok_> ah ok, I can see why, so all dependencies are in one direction..
[09:49] <alan_g> alf_: anpok_ any opinions?  https://code.launchpad.net/~alan-griffiths/mir/SwitchingBundle-controls-completion-of-client_acquire-without-blocking/+merge/204294
[09:57] <alf_> alan_g: looking
[10:22] <anpok_> i am a bit puzzled by having multiple compositors
[10:22] <anpok_> what would happen if we turn one screen off
[10:23] <anpok_> i mean we have one compositor per output?
[10:26] <greyback> alan_g: will you have a chance to look at bug 1276704 any time soon?
[10:27] <alan_g> greyback: I've just put it on today's list
[10:27] <greyback> alan_g: thanks
[10:54] <alf_> anpok_: we have multiple compositors (running in different threads) because 1. each output is backed by a different framebuffer that we need to draw to (exception: clone mode) 2. outputs have different vsync rates and vsync start offsets
[10:56] <anpok_> but when one compositor is stopped it will release all buffers?
[10:57] <anpok_> btw will you kill me for having mrn and mrl (mir::report::logging?
[10:58] <alf_> anpok_: we have one MultiThreadedCompositor that coordinates composition on all outputs, and each output is then handled by a (Default)DisplayBufferCompositor instance
[10:58] <alf_> anpok_: so which compositor are you referring to? :)
[11:02] <anpok_> alf_: ok puzzle solved
[11:03] <anpok_> it happens through the temporary compositor buffer being consumed as a shared ptr for the short time during composition
[11:06] <alf_> anpok_: @mrn,mrl, I don't mind as long as they are internal to report (although Alan may not share this preference?)
[11:08] <alan_g> Does "internal to report" mean in the same src directory?
[11:08] <anpok_> no in another directory underneath
[11:08] <anpok_> i just moved everthing below report
[11:09] <anpok_> yeah this time everything
[11:09] <anpok_> only lttng logging and null_*
[13:17] <alf_> rsalveti: Hi! I was thinking, for the dynamic backends, do you need runtime selection or package time selection (e.g., have a libmirplatformandroid and libmirplatformmesa that both provide libmirplatform)?
[13:19] <alf_> rsalveti: (runtime selection = being able to install both libmirplatformandroid and libmirplatformmesa at the same time and select the actual library at runtime)
[13:19] <rsalveti> alf_: any would do for now (as we have different seeds for desktop and touch), but later on it might be good to do that in runtime
[13:20] <rsalveti> in case someone installs the android one, and ends up breaking his desktop
[13:24] <alf_> rsalveti: the difference in mir code is minimal (since we will load server/clients backends at runtime), it's more of a packaging decision
[13:26] <rsalveti> ogra_: what do you think^?
[13:26] <alan_g> alf_: in case you've not noticed - there's still a little android/mesa code in frontend (chosen at build time).
[13:27] <rsalveti> ogra_: I don't think we have an official way yet to decide if we're in desktop or touch during runtime
[13:27] <alf_> alan_g: thanks, there is also a lot of code on the client that is chosen at build time :) (I am fixing both)
[13:29] <alan_g> :)
[13:30]  * ogra_ reads
[13:31] <ogra_> no, we dont have such a way *yet* but we will need one in the future ... for the time being selection via seeds will be fine
[13:31] <ogra_> as long as we dont tie us in with that for the future (i.e. if it still stays an easy switch i guess it is fine to re-visit in 15.04 or 15.10, whatever will have the merged seeds)
[14:17] <kgunn> rsalveti: atm isn't there at least some android version/value that can be interrogated ?
[14:18] <kgunn> e.g. we have hwc1.0, 1.1 as well...and if no android present you're on desktop...couldn't that be the logic ?
[14:18] <kgunn> alf_: ^
[14:28] <alf_> kgunn: probably
[14:34] <alan_g> greyback: https://code.launchpad.net/~alan-griffiths/mir/fix-1276704/+merge/205357
[14:34] <greyback> alan_g: nice, thank you
[15:07] <alf_> rsalveti: is the fix for bug 127662 enough to unblock you until we get dynamic backends?
[15:07] <alf_> rsalveti: hmm, bug 1276621
[15:09] <anpok|lunch> alf_: alan_g: I need a name - a factory that creates reports based on the program options / server options ..
[15:09] <rsalveti> alf_: yeah, trying that today
[15:09] <rsalveti> alf_: ogra_: but it should just be easier for now to have a separated package
[15:10] <rsalveti> and we can land it faster as well
[15:10] <alf_> rsalveti: sure
[15:10] <alf_> anpok|lunch: ReportFactory ?
[15:12] <alan_g> I understand the reluctance to use "Factory" - if there's something less generic than a pattern name it should be preferred
[15:13] <alan_g> is this an function, a class interface, an implementation, ...?
[15:13] <alan_g> *a function
[15:17] <ogra_> yeah, shiny is for later :)
[15:17] <anpok|lunch> alf_: thats the interface
[15:18] <anpok|lunch> alan_g: it is just an aggregation of three of those implementations .. for null reports logging and lttng..
[15:18] <anpok|lunch> it just delegates to the real ones ..
[15:20] <alan_g> Then surely the interface is AbstractFactory?
[15:20]  * alan_g winces
[15:21] <alan_g> ReportSelector?
[15:22] <anpok> yes that would be fine for me, but thats like the generic version of the "er"-rule for turning verbs into nouns
[15:23] <anpok> but since you proposed it, the rule cannot be applied by yourself
[15:24] <anpok> oh... thank you!
[15:24] <anpok> that thing does not need to implement the factory interface.
[17:13] <alf_> kdub: Is mga::FBTargetLayerList::reset_composition_layers() going to be generally useful in the future? It's only used in the tests right now.
[17:38] <alan_g> kgunn: looks like you're getting ready to land stuff. I think greyback would like this included if it gets reviewed: https://code.launchpad.net/~alan-griffiths/mir/fix-1276704/+merge/205357
[17:41] <greyback> kgunn: that I would, but landing it will demand a unity-mir rebuild since it changes server API
[18:40] <anpok> alan_g: still there?
[21:02] <bregma> hey guys, I'm trying to run Unity8 on the desktop and I don't have any kind of cursor anywhere ... is there something I need to do in Mir or is it the shell layer that's expected to handle that in software now?