[03:19] <duflu> RAOF: Your rootless work... is that a whole new DDX?
[03:19] <RAOF> duflu: No; it's the same set of DDXen.
[03:20] <RAOF> duflu: It's basically “hook into all non-root-window setup” rather than “hook into only the root-window setup”
[03:20] <duflu> RAOF: Oh. So same number of copies as XMir? (one too many)
[03:20] <RAOF> duflu: Correct.
[03:21] <RAOF> Our design ensures we cannot do better (barring optimisations for GLX apps, which are easier for rootless)
[03:21] <duflu> RAOF: Wouldn't glamor do better?
[03:22] <RAOF> No? Why would it do better?
[03:22] <duflu> RAOF: I thought it might be more efficient but now realize you'd just have an extra texture upload, in a different place
[03:23] <duflu> Hey, I just realized the texture cache should really help XMir multimonitor
[03:23] <duflu> maybe
[03:25] <duflu> Hmm, scrap that. XMir will typically always use bypass. So no textures anyway
[03:25] <RAOF> Yeah, I'd hope so.
[07:08] <RAOF> To the EOWatron!
[07:37]  * duflu waves to RAOF
[07:38] <duflu> perhaps too late
[07:59] <anpok> hi
[08:00] <alf_> anpok: hi
[12:34] <timp> hello
[12:35] <timp> we are having some crashes in autolanding that seem mir-related, can someone have a look at the crash logs? I cannot make sense from them - https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4710/
[12:35] <timp> we saw the same here in this MR https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906
[12:36] <timp> three times autolanding failed for that MR, and then suddenly it passed. So the failures seem not consistent
[12:52] <alf_> timp: looking
[12:57] <timp> alf_: thanks
[13:07] <dandrader> when a bug fix goes into lp:mir/devel, what's the process to have it cherry-picked into lp:mir (trunk)?
[13:10] <alf_> dandrader: ideally we merge lp:mir/devel into trunk, but depending on what else has landed this may not be possible at that point, so you can propose a separate MP for the fix targeting lp:mir
[13:12] <alf_> timp: how can I get a stack trace from the .crash file? apport-retrace doesn't work for me (but perhaps I am doing it wrong)
[13:13] <dandrader> alf_, sure. Because I noticed (correct me if I'm wrong) that trunk and devel are ABI-incompatible at the moment
[13:14] <alf_> dandrader: right, so in this case, either wait or propose a separate MP if it's urgent
[13:15] <dandrader> alf_, I'll make a separate proposal targeting trunk. thanks
[13:15] <dandrader> (it's a critical bug)
[13:18] <timp> alf_: I don't know. I was hoping to get help here
[13:18]  * timp in a meeting now
[15:38] <anpok> kdub: didnt you recently fix an issue in which frames where jittering on nexus 10?
[17:05] <dandrader> gl newbie needing help: what would make mir_demo_client_egltriangle block indefinitely on the glDrawArrays(...) of its render loop? I suppose it's waiting for the mir server to do something it was supposed to do?  like giving him a new buffer to draw on?
[17:06] <dandrader> for context: I'm updating gerry's "qml mir compositor" prototype to use the latest mir version
[17:22] <alan_g> dandrader: you may get some clue which call is blocking from  MIR_CLIENT_RPC_REPORT=log
[17:22] <dandrader> alan_g, thanks, will try it now
[17:29] <dandrader> alan_g, my bad. I wans't fflushing after the printf. it's actually hanging in mir_eglapp_swap_buffers(), which makes more sense
[17:29] <dandrader> alan_g, the last line from the RPC report is "(DD) rpc: Invocation succeeded: id: 4 method_name: next_buffer"
[17:33] <dandrader> more precisely, eglSwapBuffers(egldisplay, eglsurface);
[17:42] <kdub> alan_g, alf_ updated https://code.launchpad.net/~kdub/mir/workaround-qcom-display-request/+merge/201859
[17:42] <kdub> should now check the array length in a less-objectionable way
[17:51] <kdub> thanks alan_g
[18:37] <rsalveti> kdub: hey, any branch for me to try?
[18:38] <kdub> rsalveti, oh yeah https://code.launchpad.net/~kdub/mir/hwc12-support/+merge/202015
[18:38] <kdub> something wish screen blanking is still funny, but one step at a time
[18:38] <kdub> that at least gets unity8 to the screen
[18:40] <rsalveti> kdub: great
[18:40] <rsalveti> kdub: did it worked fine with hwcomposer 1.1 when using 4.2 on mako as well?
[18:41] <kdub> rsalveti, still have to test that
[18:41] <rsalveti> right, because I expect us to merge this first before doing the 4.4 switch
[18:42] <rsalveti> but will give it a try in a few
[19:00] <kdub> starting to like the 'post_update(renderlist, render_fn)' better than 'filter_out_optimized_renderables'