racarr__RAOF: Ok so I am trying to send you the xmir changes on github...the thing is I had some issue with vladmir and the intel driver and you werent around so I ended up basing them just on the packaging source00:42
racarr__so now I am trying to port them to vladimir, well there isnt much to do, but anyway I think thats done00:42
RAOFracarr__: Ah, cool.00:42
racarr__but how ... should I build it lol00:43
racarr__i.e. what are some reasonable ./configure options00:43
racarr__because there is no deb dir in vladimir00:43
RAOFHm. That's dropped out of my zsh history ;)00:44
racarr__oh no00:44
racarr__we will have to consult the sage atop X11 mountain.00:44
RAOFracarr__: But I'd just build it with --enable-xmir as a first go.00:45
racarr__ahahha ok00:45
racarr__I tried config.log and got ./configure --prefix=/usr --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --build=x86_64-linux-gnu lt_cv_prog_compiler_static_works=no lt_cv_prog_compiler_static_works=no --disable-silent-rules --disable-static --without-dtrace --disable-strict-compilation --enable-debug --enable-unit-tests --with-int10=x86emu --with-extra-module-dir=/usr/lib/x86_64-00:45
racarr__but it doesnt work00:46
racarr__presumably because of quotes but I havent found where to put them all yet00:46
racarr__RAOF: I need a new xtrans presumably I need to update00:49
racarr__to utopic?00:49
RAOFracarr__: Hm, dunno, seems to work for me (on utopic) :)00:54
racarr__ok well enter the unicorn after meeting00:55
racarr__RAOF: Ok I am making a beeline for food then will send you patch that I expect to ork on vladmir and you can try it out02:00
=== chihchun_afk is now known as chihchun
RAOFAre we going to be using EXPECT_THAT for all test expectations, rather than all of the various EXPECT_{GE,TRUE,WHATEVER} specialisations that exist?06:30
dufluRAOF: I hope not. Sometimes the latter is much clearer06:40
dufluAlthough people seem to be converting everything to the former06:41
RAOFYeah. I'm not sure why EXPECT_THAT(foo(), Eq(true)) is any clearer than EXPECT_TRUE(foo()).06:44
dufluRAOF: Coming soon: Lots of EXPECT_DEATH in some of my new tests :)06:49
dufluand EXPECT_EXIT06:49
* RAOF is a fan of EXPECT_DEATH06:49
anpokhm seems like due to a change in initialization order the session manager gets an added surface before the input targeter / input registrar hence it complains that it cannot set the focs to that surface08:26
anpok(on one of my cleanup branches)08:26
anpokhm i think it happens in a different thread have to look again08:32
alan_ganpok: the SurfaceCoordinator ought to be coordinating the surface addition. (Although I was interrupted in that doing cleanup)08:35
anpokthe issue is actually different again08:37
anpokthe moment I now register the input registrar (great names) as observer to the scene, at that moment nobody holds a strong reference to the scene yet08:38
anpokoh scene is not even part of the DisplayServer::Private08:39
anpokinput dispatcher conf had one08:40
anpokshould i make a small mp for DisplayServer::Private to hold the_scene() early in the initialization?08:43
anpokyes, mir::compositor::Scene seems to be wrong.. but that would be another (bigger?) change?08:44
anpoki wanted to say - we should have  mir::scene::Scene and it should look different..08:45
alan_ganpok: if you're writing something that needs the scene then why isn't that keeping a reference?08:50
alan_gIt seems wrong to rely on "someone else" holding ownership for you08:51
anpokwell it does not necissarily need the scene - it is something that is bridging information between the scene and what the droidinput::InputDispatcher sees08:51
anpokthats true08:51
anpoki find the entities that we store in DisplayServer::Private rather arbitrary08:52
anpokat the moment the objects there are objects that need to be informed about stop / start / pause08:52
alan_gThey're the ones that the DS needs to start/pause/resume/stop08:53
alan_gThat's not arbitrary08:53
anpokwe could also make an abstraction for that .. a system state observer .. yes inverting that.. and react on state changes in the components08:53
alan_ganpok: does that help your current lifetime management issue?09:00
anpokno it might unveil further issue09:01
anpoki hestitated to add the scene to the registrar, because the interface of scene requires a shared ptr to register..09:02
anpokso I would have to do something odd like shared_from_this or well rely on the caller to register - just like before09:02
anpokwith my statement above I wanted to stress that ownership (as a keep alive concept) and observation of changes should be somehow separate09:03
anpokand we could redefine the role of starting and stopping as something that needs subsrcription to a state change09:04
anpokand then we would have to define ownership separately and make it more explicit09:04
anpokand more fine grained...09:04
alan_gOK  I agree that if scene owns registrar then registrar can't also own scene09:05
anpokthis is not a solution (explicit ownership) - just another problem :)09:06
alan_gBut registrar could have a pointer to scene - as scene is guaranteed to outlive it09:06
alan_gOr just passing this to the function(s) that need it09:11
anpokthen scene needs to know registrar - which it shouldnt since it is only an impementation detail introduced for droidinput inputdispatcher09:12
anpokyes, before the scene observer we had that reference to registrar inside the scene09:13
alan_g"the interface of scene requires a shared ptr to register"09:13
anpokto register an observer09:14
anpoknot to the registrar (tm)09:14
alan_gOh I misunderstood09:15
dufluAnyone else notice gdb crashes a lot now09:15
dufluIt's really annoying09:16
dufluI just trying gdb gdb and it just shows a stack overflow (and no symbols)09:16
alan_gSo there's the problem: registrar shouldn't implement Observer09:16
alan_gduflu: no09:16
anpokduflu: no gdb worked great recently09:17
alan_gIt should "own" scene and register a distinct observer type09:17
dufluHmm, RAOF was reporting the same problems...09:17
anpokhavent updated... like at least for a week or so09:18
anpokalan_g: ok that would solve it09:18
anpok(just have to check who owns registrar)09:19
alan_gIt also keeps to the single responsibility principle09:19
anpokhm ok the enumerator09:19
anpokwhich is then owned by the droidinput InputDispatcher09:19
anpokwhich is then owned by the mia::AndroidInputDispatcher..09:20
dufluOh, it seems to be program-specific:09:20
duflu mir_unit_tests --gtest_filter="FatalTest.*"09:20
anpokand then we are at DIsplayServer09:20
dufluI mean:09:20
dufluReading symbols from bin/mir_unit_tests...Segmentation fault (core dumped)09:20
* alan_g wonders if we could generate an "ownership" DAG for Mir09:20
anpokduflu: too many symbols - running out or memory? or broken memory?09:20
anpokalan_g: we could trace constructor calls in CachedPtr09:21
anpokwith the symbol name underneath09:21
anpokor maybe it can be extracted from the symbol name of the functor somehow09:21
duflualan_g: I've always thought DAG enforcement should be part of a super-shared_ptr09:24
* alan_g was thinking build time, not runtime. And adding to the generated docs09:24
anpoklibclang \o/ - now i am gone09:32
=== pete-woods is now known as pete-woods-lunch
=== pete-woods-lunch is now known as pete-woods
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== ondra| is now known as ondra
greybackCrazy idea, but is there a way to run mir in such a way that it doesn't connect to the hardware or composite anything, but clients could connect to it and make surface and stuff?15:32
greybackwould be handy for testing IMO15:33
anpokgreyback: there should be an offscreen option15:40
=== ted is now known as tedg
alan_ggreyback: it isn't crazy - it is handy for testing15:41
anpokyou could also disable input then the hosting server would not open any devices.. but it would also disable the dispatch of input hmm15:43
anpokwhat was the intention of the --enable-input option?15:43
anpokto not open input devices, or to not deal with input events of any source ...15:44
greybackanpok: alan_g: offscreen option on my desktop still tries to twiddle the VTs15:47
greybackmir_demo_server_shell --offscreen  =>  std::exception::what: Failed to find the current VT15:47
alan_galf_: you're responsible for the offsceen option aren't you? ^^15:49
alf_greyback: alan_g: the offscreen support is rough still (proof of concept mostly, we were waiting from feedback from interested parties that never came)15:52
* alan_g thinks we have a new "interested party"15:52
anpokand feedback15:54
greybackalf_: yeah, I'd like to have that ability for proper integration testing of unity-mir with mir15:54
greybackso in a test env, I can launch & stop apps15:54
greybacknot a major request mind, but would be nice to have15:54
alf_greyback: ok, so what can we assume about the test environment in terms of display support (e.g. drivers with Mesa/GBM)?15:55
alf_greyback: also do you want to be able to get visual output e.g. through screencasting?15:56
greybackalf_: I guess my initial thought was a null display driver, so nothing gets drawn anywhere15:58
=== chihchun is now known as chihchun_afk
anpokgreyback: and do you want it to open input devices / not open any devices but allow the dispatch of synthetic input events?15:59
greybackanpok: the latter option would be preferred16:00
alf_greyback: perhaps offscreen is not what you are looking for, but an even leaner dumb server (like the ones we use in the mir integration/acceptance tests)?16:01
anpokthere is an option --enable-input that does the former, we could add one for the latter..16:01
greybackalf_: ah, what dumb server is this?16:01
anpokor what alf says - that one does what you want wrt to input testing16:02
alf_greyback: it's not an executable, it's a server configuration with the major components stubbed which we used to instantiate our various test server instances16:03
alf_greyback: tests/mir_test_framework/stubbed_server_configuration.cpp16:03
greybackalf_: sounds handy. Let me play with it. If I find it useful, I might request a package containing it so unity-mir's integration/acceptance tests can use it16:04
greybackalf_: anpok: thanks guys!16:06
alf_greyback: yw16:06
=== beidl_ is now known as beidl
=== dandrader is now known as dandrader|lunch
anpokgreyback: or look at InputTestingServerConfiguration i believe it is the same plus a fake event hub plus the common input dispatching stuff17:03
greybackanpok: ah nice, thanks17:04
=== dandrader|lunch is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
racarr__kdub_: Hey I replied to your comments on cursor-spike btw...fixed the style one...I think shared_ptr really is appropriate though19:41
racarr__because the idea is, surfaces will share ownership of the loaded cursor images19:41
racarr__so, if no one is interested in the magnifying glass image it goes away and on the other hand everyone has the same instance of the default image19:42
racarr__of course the loader can also implement caching by keeping its own strong references19:42
kdub_racarr__, I guess my thought was though that its strange that an observer gets ownership19:43
kdub_like, having the surface have ownership makes sense to me19:43
racarr__oh...for the observer! Aha maybe I misread your comment sorry...19:43
racarr__ok I think you are right19:44
racarr__will fix it up19:45
racarr__sometimes...im not sure what to do in these situations19:45
racarr__because just using shared_ptr EVERYWHERE can get costly19:45
racarr__but whenever I use a reference to something managed by a shared_ptr elsewhere19:45
racarr__I feel like I am laying a trap lol19:45
racarr__ok brb lunch19:48
racarr__...I cant believe its 92 degrees19:48
kdub_racarr__, yeah, hot down here too, 100 tomorrow19:48
bschaeferracarr__, its 82 here :(, i want rain19:49
racarr__Yesterday it kind of made me like woozy and tired19:57
racarr__but today ive been drinking iced coffee all day19:57
racarr__and really like it19:57
bschaefericed coffee....must ... get some now....20:00
=== dandrader is now known as dandrader|afk
racarr__the error message when you only pass 8 arguments to a mock that expects 9 can be quite21:50
racarr__I dont understand what ipc factory is for21:51
racarr__in order to add a new argument to session mediator constructor21:51
racarr__you have to change literally over 10 call sites/declarations21:51
kgunnanyone...i think i'm an over-user of clean (lots of scar tissue from symbian days...using reallyclean), whats kind of your rule of thumb do you make clean ?21:52
racarr__basically never21:54
racarr__I recenetly cleaned over 40 gigs of mir build dirs all at once though21:54
racarr__the only time I make clean is with qmake because...I have had several issues with it lol21:55
racarr__kdub_: Ok passing references in cursor phase 3 now21:55
kdub_racarr__, ack22:01
racarr__phase 4 incoming!22:02
kdub_yknow, i should start naming my branches 'phases'22:02
kdub_one less thing to name :)22:02
racarr__kdub_: http://xkcd.com/1296/22:03
kdub_racarr__, lol, yeah22:05
racarr__kgunn: So if we were to wait on cursor API for 0.2 there is no point in waiting past phase 4 because at that point22:07
racarr__clients could use it etc22:07
racarr__still no themed image loaders, but they can request the images, disable the cursor, etc...it can be tested and once we add the image loader will all just work22:08
racarr__again im really not sure its worth waiting though if we release again in a week or something22:08
racarr__I dont think we really profit much from trying to get certain things22:09
racarr__in certain releases22:09
racarr__and it might be better to just have consistent fast releases22:09
rsalvetikdub_: interesting bug for you: bug 131958222:35
ubot5bug 1319582 in android (Ubuntu) "'Failed to start RenderThread' after opening/closing applications" [Undecided,New] https://launchpad.net/bugs/131958222:35
rsalvetikdub_: basically, eglDestroySurface never gets called when starting/closing apps with ubuntu touch22:35
rsalvetiand as a side effect, the window surface never gets released when running it on the emulator22:36
rsalvetias it allocates a host side gl window surface, and waits that call to happen for it to release it22:36
rsalvetikdub_: we're not calling eglDestroySurface because the app is just normally killed, without any special clean-up22:37
kdub_rsalveti, hmm22:37
rsalvetiany idea on how this could be solved on the client side?22:37
kdub_make sure to clean up resources? :)22:38
rsalvetiright, but which component should take care of that?22:38
rsalvetithe system-compositor?22:38
kdub_which egl context is the one that's leaking?22:39
rsalvetiwhen you open an app, it creates a surface and a color buffer22:39
rsalvetithe color buffer is released just fine, but the surface never gets released22:39
kdub_I guess I don't know the brew of components in play well enough to reason to a solution...22:41
rsalvetitvoss: maybe you have an idea ^22:42
kdub_the emulator is running a mir instance, like usc+unity8, right?22:42
rsalvetikdub_: yeah, exactly as we have on a nexus device22:42
rsalvetibut the egl/gles driver is a translator that uses your host gl22:42
kdub_and there's probably some sort of pass-through driver22:42
kdub_but the translator is an android window surface, right?22:43
rsalvetiright, when you ask for a surface, it sends the message to your host, via qemu pipe, that then creates the surface22:44
rsalvetibut for the client this is just a normal android surface22:44
racarr__RAOF: Email incoming in 1 minute lol23:39
racarr__RAOF: ok 0001-input.patch is a completely untested integration of it in to vladimir23:42
racarr__I mean not even compiled or really looked at lol, but who knows23:43
racarr__and then xmir-deb23:43
racarr__is the working xmir directory from my23:43
racarr__ubuntu xserver patched to work with it23:43
racarr__I did have to delete my input drivers to test it23:43
racarr__als o make sure to replace your xinput driver before rebooting, it can be really disorienting23:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!