[00:42] 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 source [00:42] so now I am trying to port them to vladimir, well there isnt much to do, but anyway I think thats done [00:42] racarr__: Ah, cool. [00:43] but how ... should I build it lol [00:43] i.e. what are some reasonable ./configure options [00:43] because there is no deb dir in vladimir [00:44] Hm. That's dropped out of my zsh history ;) [00:44] oh no [00:44] we will have to consult the sage atop X11 mountain. [00:45] racarr__: But I'd just build it with --enable-xmir as a first go. [00:45] ahahha ok [00:45] 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:46] but it doesnt work [00:46] presumably because of quotes but I havent found where to put them all yet [00:46] lol [00:48] hmm [00:49] RAOF: I need a new xtrans presumably I need to update [00:49] to utopic? [00:54] racarr__: Hm, dunno, seems to work for me (on utopic) :) [00:55] ok well enter the unicorn after meeting [02:00] 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 out [02:01] Wickedcool. [02:01] TO THE COFFEEOTRON! === chihchun_afk is now known as chihchun [06:30] Are 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:40] RAOF: I hope not. Sometimes the latter is much clearer [06:41] Although people seem to be converting everything to the former [06:44] Yeah. I'm not sure why EXPECT_THAT(foo(), Eq(true)) is any clearer than EXPECT_TRUE(foo()). [06:49] RAOF: Coming soon: Lots of EXPECT_DEATH in some of my new tests :) [06:49] and EXPECT_EXIT [06:49] * RAOF is a fan of EXPECT_DEATH [06:49] lol [08:26] hm 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 surface [08:26] (on one of my cleanup branches) [08:32] hm i think it happens in a different thread have to look again [08:35] anpok: the SurfaceCoordinator ought to be coordinating the surface addition. (Although I was interrupted in that doing cleanup) [08:37] hm [08:37] the issue is actually different again [08:38] the 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 yet [08:39] oh scene is not even part of the DisplayServer::Private [08:40] input dispatcher conf had one [08:43] should i make a small mp for DisplayServer::Private to hold the_scene() early in the initialization? [08:44] yes, mir::compositor::Scene seems to be wrong.. but that would be another (bigger?) change? [08:45] i wanted to say - we should have mir::scene::Scene and it should look different.. [08:50] anpok: if you're writing something that needs the scene then why isn't that keeping a reference? [08:51] It seems wrong to rely on "someone else" holding ownership for you [08:51] well it does not necissarily need the scene - it is something that is bridging information between the scene and what the droidinput::InputDispatcher sees [08:51] thats true [08:52] i find the entities that we store in DisplayServer::Private rather arbitrary [08:52] at the moment the objects there are objects that need to be informed about stop / start / pause [08:53] They're the ones that the DS needs to start/pause/resume/stop [08:53] That's not arbitrary [08:53] we could also make an abstraction for that .. a system state observer .. yes inverting that.. and react on state changes in the components [09:00] anpok: does that help your current lifetime management issue? [09:01] no it might unveil further issue [09:01] *issues [09:02] i hestitated to add the scene to the registrar, because the interface of scene requires a shared ptr to register.. [09:02] so I would have to do something odd like shared_from_this or well rely on the caller to register - just like before [09:03] with my statement above I wanted to stress that ownership (as a keep alive concept) and observation of changes should be somehow separate [09:04] and we could redefine the role of starting and stopping as something that needs subsrcription to a state change [09:04] and then we would have to define ownership separately and make it more explicit [09:04] and more fine grained... [09:05] OK I agree that if scene owns registrar then registrar can't also own scene [09:06] this is not a solution (explicit ownership) - just another problem :) [09:06] But registrar could have a pointer to scene - as scene is guaranteed to outlive it [09:06] pointer? [09:07] "SomeType*" [09:07] registrar-scene(this) [09:07] registrar->scene(this) [09:11] Or just passing this to the function(s) that need it [09:11] *"this" [09:12] then scene needs to know registrar - which it shouldnt since it is only an impementation detail introduced for droidinput inputdispatcher [09:13] yes, before the scene observer we had that reference to registrar inside the scene [09:13] "the interface of scene requires a shared ptr to register" [09:14] to register an observer [09:14] not to the registrar (tm) [09:15] Oh I misunderstood [09:15] Anyone else notice gdb crashes a lot now [09:16] It's really annoying [09:16] (?) [09:16] I just trying gdb gdb and it just shows a stack overflow (and no symbols) [09:16] So there's the problem: registrar shouldn't implement Observer [09:16] duflu: no [09:17] duflu: no gdb worked great recently [09:17] It should "own" scene and register a distinct observer type [09:17] Hmm, RAOF was reporting the same problems... [09:18] havent updated... like at least for a week or so [09:18] alan_g: ok that would solve it [09:19] (just have to check who owns registrar) [09:19] It also keeps to the single responsibility principle [09:19] hm ok the enumerator [09:19] which is then owned by the droidinput InputDispatcher [09:20] which is then owned by the mia::AndroidInputDispatcher.. [09:20] Oh, it seems to be program-specific: [09:20] mir_unit_tests --gtest_filter="FatalTest.*" [09:20] Gah [09:20] and then we are at DIsplayServer [09:20] ok [09:20] I mean: [09:20] Reading symbols from bin/mir_unit_tests...Segmentation fault (core dumped) [09:20] bbiab [09:20] * alan_g wonders if we could generate an "ownership" DAG for Mir [09:20] duflu: too many symbols - running out or memory? or broken memory? [09:21] alan_g: we could trace constructor calls in CachedPtr [09:21] with the symbol name underneath [09:21] or maybe it can be extracted from the symbol name of the functor somehow [09:24] alan_g: I've always thought DAG enforcement should be part of a super-shared_ptr [09:24] mir::sp::FTW [09:24] * alan_g was thinking build time, not runtime. And adding to the generated docs [09:32] libclang \o/ - now i am gone === 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 [15:32] Crazy 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:33] would be handy for testing IMO [15:40] greyback: there should be an offscreen option === ted is now known as tedg [15:41] greyback: it isn't crazy - it is handy for testing [15:43] you could also disable input then the hosting server would not open any devices.. but it would also disable the dispatch of input hmm [15:43] what was the intention of the --enable-input option? [15:44] to not open input devices, or to not deal with input events of any source ... [15:47] anpok: alan_g: offscreen option on my desktop still tries to twiddle the VTs [15:47] mir_demo_server_shell --offscreen => std::exception::what: Failed to find the current VT [15:49] alf_: you're responsible for the offsceen option aren't you? ^^ [15:52] 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:54] and feedback [15:54] alf_: yeah, I'd like to have that ability for proper integration testing of unity-mir with mir [15:54] so in a test env, I can launch & stop apps [15:54] not a major request mind, but would be nice to have [15:55] greyback: ok, so what can we assume about the test environment in terms of display support (e.g. drivers with Mesa/GBM)? [15:56] greyback: also do you want to be able to get visual output e.g. through screencasting? [15:58] alf_: I guess my initial thought was a null display driver, so nothing gets drawn anywhere === chihchun is now known as chihchun_afk [15:59] greyback: and do you want it to open input devices / not open any devices but allow the dispatch of synthetic input events? [16:00] anpok: the latter option would be preferred [16:01] 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] there is an option --enable-input that does the former, we could add one for the latter.. [16:01] alf_: ah, what dumb server is this? [16:02] or what alf says - that one does what you want wrt to input testing [16:03] 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 instances [16:03] greyback: tests/mir_test_framework/stubbed_server_configuration.cpp [16:04] alf_: 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 it [16:06] alf_: anpok: thanks guys! [16:06] greyback: yw === beidl_ is now known as beidl === dandrader is now known as dandrader|lunch [17:03] greyback: or look at InputTestingServerConfiguration i believe it is the same plus a fake event hub plus the common input dispatching stuff [17:04] anpok: ah nice, thanks === dandrader|lunch is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [19:41] kdub_: Hey I replied to your comments on cursor-spike btw...fixed the style one...I think shared_ptr really is appropriate though [19:41] because the idea is, surfaces will share ownership of the loaded cursor images [19:42] 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 image [19:42] of course the loader can also implement caching by keeping its own strong references [19:43] racarr__, I guess my thought was though that its strange that an observer gets ownership [19:43] like, having the surface have ownership makes sense to me [19:43] oh...for the observer! Aha maybe I misread your comment sorry... [19:44] right [19:44] Hmm. [19:44] ok I think you are right [19:45] will fix it up [19:45] sometimes...im not sure what to do in these situations [19:45] because just using shared_ptr EVERYWHERE can get costly [19:45] but whenever I use a reference to something managed by a shared_ptr elsewhere [19:45] I feel like I am laying a trap lol [19:48] ok brb lunch [19:48] ...I cant believe its 92 degrees [19:48] racarr__, yeah, hot down here too, 100 tomorrow [19:49] racarr__, its 82 here :(, i want rain [19:57] Yesterday it kind of made me like woozy and tired [19:57] but today ive been drinking iced coffee all day [19:57] and really like it [20:00] iced coffee....must ... get some now.... === dandrader is now known as dandrader|afk [21:50] the error message when you only pass 8 arguments to a mock that expects 9 can be quite [21:50] fabulous [21:51] I dont understand what ipc factory is for [21:51] in order to add a new argument to session mediator constructor [21:51] you have to change literally over 10 call sites/declarations [21:52] anyone...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:54] basically never [21:54] I recenetly cleaned over 40 gigs of mir build dirs all at once though [21:54] :p [21:55] the only time I make clean is with qmake because...I have had several issues with it lol [21:55] kdub_: Ok passing references in cursor phase 3 now [22:01] racarr__, ack [22:02] phase 4 incoming! [22:02] lol [22:02] yknow, i should start naming my branches 'phases' [22:02] one less thing to name :) [22:03] kdub_: http://xkcd.com/1296/ [22:03] MY HANDS ARE TYPING WORDS [22:05] racarr__, lol, yeah [22:07] 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 point [22:07] clients could use it etc [22:08] 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 work [22:08] again im really not sure its worth waiting though if we release again in a week or something [22:09] I dont think we really profit much from trying to get certain things [22:09] in certain releases [22:09] and it might be better to just have consistent fast releases [22:35] kdub_: interesting bug for you: bug 1319582 [22:35] bug 1319582 in android (Ubuntu) "'Failed to start RenderThread' after opening/closing applications" [Undecided,New] https://launchpad.net/bugs/1319582 [22:35] kdub_: basically, eglDestroySurface never gets called when starting/closing apps with ubuntu touch [22:36] and as a side effect, the window surface never gets released when running it on the emulator [22:36] as it allocates a host side gl window surface, and waits that call to happen for it to release it [22:37] kdub_: we're not calling eglDestroySurface because the app is just normally killed, without any special clean-up [22:37] rsalveti, hmm [22:37] any idea on how this could be solved on the client side? [22:38] make sure to clean up resources? :) [22:38] right, but which component should take care of that? [22:38] the system-compositor? [22:39] which egl context is the one that's leaking? [22:39] when you open an app, it creates a surface and a color buffer [22:39] the color buffer is released just fine, but the surface never gets released [22:41] I guess I don't know the brew of components in play well enough to reason to a solution... [22:42] tvoss: maybe you have an idea ^ [22:42] the emulator is running a mir instance, like usc+unity8, right? [22:42] kdub_: yeah, exactly as we have on a nexus device [22:42] but the egl/gles driver is a translator that uses your host gl [22:42] and there's probably some sort of pass-through driver [22:43] right [22:43] but the translator is an android window surface, right? [22:43] https://code-review.phablet.ubuntu.com/gitweb?p=CyanogenMod/android_sdk.git;a=blob;f=emulator/opengl/DESIGN;hb=refs/heads/phablet-trusty [22:44] right, when you ask for a surface, it sends the message to your host, via qemu pipe, that then creates the surface [22:44] but for the client this is just a normal android surface [23:39] OHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH [23:39] RAOF: Email incoming in 1 minute lol [23:39] Wooot! [23:42] RAOF: ok 0001-input.patch is a completely untested integration of it in to vladimir [23:43] I mean not even compiled or really looked at lol, but who knows [23:43] and then xmir-deb [23:43] is the working xmir directory from my [23:43] ubuntu xserver patched to work with it [23:43] um. [23:43] I did have to delete my input drivers to test it [23:44] Bitchn' [23:47] als o make sure to replace your xinput driver before rebooting, it can be really disorienting