[09:28] <alan_g> alf_: anpok_ - do you want to review this? (Or shall I just TA?) https://code.launchpad.net/~alan-griffiths/mir/remove-RTLD_GLOBAL-hack/+merge/277277
[09:30] <alf_> alan_g: feel free to TA, the code change looks sane, but I won't have time to test until later today
[09:31] <anpok_> just did
[09:31] <alan_g> alf_: anpok_ - thanks
[09:32] <anpok_> further messing with clocks spawned https://bugs.launchpad.net/canonical-devices-system-image/+bug/1515515
[09:32] <anpok_> .. hm why does it say in unity8 ..
[09:33] <anpok_> anyhow .. I will probably settle with CLOCK_REALTIME for now.. it seem to be a problem in kernel .. at least glibc just forwards the clock id..
[09:34] <anpok_> now I wonder .. should we also change mir::Clock::SteadyClock to not use steady_clock?
[09:34] <anpok_> or should I .. for now have different clock passed to the input platforms..
[09:43] <alf_> anpok_: Did you see my comments in that bug?
[10:09] <anpok_> alf_: we do now() + some_next_frame_estimate then forward events to it
[10:09] <anpok_> but let me look again..
[10:10] <anpok_> alan_g: I seem to have tested in the wrong build directory... i was about to add another check to the module entry points..
[10:10] <anpok_> with that branch - as opposed to lp:mir it seems to fail while trying to probe the kms platform
[10:11] <alan_g> anpok_: which scenario? (I haven't seen any problems)
[10:15] <anpok_> what i tried was: ./mir_demo_server --vt 2 --file /tmp/mir_host --launch-client './mir_demo_server --host-socket /tmp/mir_host --file /tmp/nested --launch-client "./mir_demo_client_eglplasma -m /tmp/nested "'
[10:17] <anpok_> oh
[10:17] <anpok_> thats the new platform probing
[10:18] <anpok_> it decides to pick dummy platform.. if I remove all by kms .. it claims none found.. while
[10:18] <anpok_> on my old build it did..
[10:18] <anpok_> so we broke probing with nested and thats not related to this branch
[10:19]  * alan_g is nearly as confused as anpok_ 
[10:20] <anpok_> i would guess it fails here:
[10:21] <anpok_> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platforms/mesa/server/kms/platform_symbols.cpp#L181
[10:21] <anpok_> need to look with a vm..
[10:22] <anpok_> and then returns in line 191 ..
[10:22] <anpok_> s/191/194
[10:23] <anpok_> nah not confused .. just stale builds..
[10:25] <anpok_> i mean our current probing logic in mir requires the nested server to launch with a --vt paramter or being at least temporary capable to drmSetMaster while probing.. otherwise the platform isnt considered
[10:29] <alf_> anpok_: alan_g: hmmm... I don't the nested server shouldn't be probing anything, it should select its guest platform to match the host platform the host server is using
[10:29] <alf_> anpok_: alan_g: s/I don't//
[10:29] <alan_g> +1
[10:29] <anpok_> yes, but does that also apply for x11 host and mesa-kms nested?
[10:30] <anpok_> hm does that even work?
[10:35]  * alf_ 's fingers have started hurting from all the proximity sensor (un)covering, and wishes he had some Lego Technic... looks around the house for any kind of mechanism to automate this
[10:36]  * alan_g wonders if, after NBS lands in the client API, we'll even need guest platforms
[10:49] <alan_g> anpok_: I confirm your finding. Did you file a bug?
[11:01] <alan_g> anpok_: https://bugs.launchpad.net/mir/+bug/1515558
[11:04] <anpok_> alan_g: had to run and unconfuse me..
[11:07] <anpok_> alan_g: maybe only for the mesa reload hack :)