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