[08:40] Oh, that's fun. Just got a double-free in a Mir demo for the first time [08:44] curious. [08:48] 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] We have something being overloaded without overloading the CPU or GPU [08:50] Hmm, happens very quickly when double buffered. Sounds again like something in the stack is holding buffers too long [08:53] Is this on both driver stacks or just the phone? [08:56] 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] 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] I'm clearly not running out of power [08:57] 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] *we're somehow [08:59] Lysdexic keyboard TWF [09:40] * alan_g wonders why DefaultInputConfiguration [09:53] alf__: Here's a fun one :) ... https://bugs.launchpad.net/mir/+bug/1377853 [09:53] Ubuntu bug 1377853 in Mir "Nested Mir server crashes on exit ("corrupted double-linked list")" [High,New] [09:53] Might be the new Mesa to blame actually [09:54] duflu: ack, I will take a look [10:15] alan_g: why it still exists? [10:16] anpok: why it was ever perpetrated too [10:17] One step forward, two steps back. [10:17] But that was only Monday [10:17] alan_g: it would otherwise spill ugly droidinput adapter code into serverconfiguration.. [10:17] * duflu runs off [10:17] 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] that is the case now [10:18] before it had a lot of more pieces it stiched together [10:18] anpok: I know you have cleaned it up a lot [10:19] alan_g: but I also dislike the consequence (even though it is better than before) [10:19] But it is still ugly [10:19] 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] anpok: sure. And we have problems with DefaultSeverConfiguration too. (From the API/ABI stability front) [10:21] which is only relevant now because we expose that.. if we wouldnt.. i wouldnt care.. [10:21] yes [10:22] If it were all neat it would be easy to tidy up. ;) [10:22] hehe [10:42] 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] alan_g: Feel free to TA, unless you strongly feel that we should take a look. [10:49] alf__: Thanks. I don't feel a need for your approval on this one. [11:10] 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] mardy: as a prompt provider? Or as a shell? [11:16] The shell could iterate over all sessions looking for the PID. But why would it matter if there's a connection open? [11:16] alan_g: asa prompt provider [11:17] mardy: not through a Mir API [11:17] alan_g: would mir_connection_create_prompt_session_sync() return NULL if the initiator pid does not have a mir connection open? [11:20] 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] alan_g: thanks [11:26] yw And thanks for highlighting a gap in our test coverage. === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [14:19] 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!) === cyphermox_ is now known as cyphermox === mhall119_ is now known as mhall119 === dandrader_ is now known as dandrader|lunch === alan_g is now known as alan_g|EOD