[08:40] <duflu> Oh, that's fun. Just got a double-free in a Mir demo for the first time
[08:44] <alan_g> curious.
[08:48] <duflu> alan_g: I also (happily) discovered that loading a Mir server till it drops to 30 FPS has nothing to do with either CPU usage or compositor render time (because both are low, as expected).
[08:48] <duflu> We have something being overloaded without overloading the CPU or GPU
[08:50] <duflu> Hmm, happens very quickly when double buffered. Sounds again like something in the stack is holding buffers too long
[08:53] <alan_g> Is this on both driver stacks or just the phone?
[08:56] <duflu> alan_g: Only the desktop I'm playing with right now. But if it is buffer-holding or some other non-power-consuming roadblock then it could apply to both
[08:57] <duflu> I'm glad I found that, because my quad-core i7 should not reasonably be dropping back to 30Hz that quickly. It has to be a bug
[08:57] <duflu> I'm clearly not running out of power
[08:57] <alan_g> duflu: ack. It has to be contention of some sort.
[08:58]  * duflu suspects we're someone holding two buffers for the frame duration instead of 0 or 1
[08:58] <duflu> *we're somehow
[08:59] <duflu> Lysdexic keyboard TWF
[09:40]  * alan_g wonders why DefaultInputConfiguration
[09:53] <duflu> alf__: Here's a fun one :) ... https://bugs.launchpad.net/mir/+bug/1377853
[09:53] <duflu> Might be the new Mesa to blame actually
[09:54] <alf__> duflu: ack, I will take a look
[10:15] <anpok> alan_g: why it still exists?
[10:16] <alan_g> anpok: why it was ever perpetrated too
[10:17] <duflu> One step forward, two steps back.
[10:17] <duflu> But that was only Monday
[10:17] <anpok> alan_g: it would otherwise spill ugly droidinput adapter code into serverconfiguration..
[10:17]  * duflu runs off
[10:17] <alan_g> It is the cause of LL635-645 in https://code.launchpad.net/~alan-griffiths/mir/fix-libmirserver-symbols/+merge/237101 (where overriding the_event_hub() is all that is really needed)
[10:17] <anpok> that is the case now
[10:18] <anpok> before it had a lot of more pieces it stiched together
[10:18] <alan_g> anpok: I know you have cleaned it up a lot
[10:19] <anpok> alan_g: but I also dislike the consequence (even though it is better than before)
[10:19] <alan_g> But it is still ugly
[10:19] <anpok> we have odd items inside the configuration class we only need to support the implementation details of the android input reading and dispatching
[10:21] <alan_g> anpok: sure. And we have problems with DefaultSeverConfiguration too. (From the API/ABI stability front)
[10:21] <anpok> which is only relevant now because we expose that.. if we wouldnt.. i wouldnt care..
[10:21] <anpok> yes
[10:22] <alan_g> If it were all neat it would be easy to tidy up. ;)
[10:22] <anpok> hehe
[10:42] <alan_g> anpok: alf__ - do either of you feel a need to review this before I TA? https://code.launchpad.net/~alan-griffiths/mir/fix-libmirserver-symbols/+merge/237101
[10:47] <alf__> alan_g: Feel free to TA, unless you strongly feel that we should take a look.
[10:49] <alan_g> alf__: Thanks. I don't feel a need for your approval on this one.
[11:10] <mardy> hi! Is there a way to know if a given PID has a mir connection open (what I need to know, is if I can open a trust session having this PID as initiator)?
[11:15] <alan_g> mardy: as a prompt provider? Or as a shell?
[11:16] <alan_g> The shell could iterate over all sessions looking for the PID. But why would it matter if there's a connection open?
[11:16] <mardy> alan_g: asa  prompt provider
[11:17] <alan_g> mardy: not through a Mir API
[11:17] <mardy> alan_g: would mir_connection_create_prompt_session_sync() return NULL if the initiator pid does not have a mir connection open?
[11:20] <alan_g> mardy: IIRC it ought to return an error object. I.e. mir_prompt_session_is_valid will return false
[11:23]  * alan_g can't see a test for that scenario but thinks there should be one.
[11:24] <mardy> alan_g: thanks
[11:26] <alan_g> yw And thanks for highlighting a gap in our test coverage.
[14:19] <alan_g> mardy: While I (and dednick) think mir_connection_create_prompt_session_sync() should fail as I described, the current code doesn't (it creates a prompt session and then silently doesn't add the non-existent participant to it - ugh!)