[08:51] <duflu> greyback: Hey I spent a brief while relearning how QtMir does compositing today. And I suspect it's holding buffers longer than it should. Although I need to re-check Mir's logic before I can suggest something better. Are you sure you can't release your buffer pointer held in the texture earlier?
[08:53] <greyback> duflu: you're correct in your suspicion. We only release a buffer when we acquire a new one, which is not ideal.
[08:53] <duflu> greyback: I think the phone will be noticeably smoother if we release earlier :)
[08:54] <greyback> duflu: we could improve this by releasing the buffer if we're notified a new one has been created, and we've fiished rendering that frame
[08:54] <greyback> duflu: I don't disagree
[08:55] <duflu> greyback: I need to re-check Mir again. I know cachine just the GL texture is fine for software surfaces but hardware surface safety is dependent on the EGL extensions we use :P
[08:55] <duflu> *caching
[08:56] <greyback> duflu: I don't understand what you mean by caching here.
[08:57] <greyback> caching the whole buffer while it's being composited, so buffer can be released?
[08:57] <duflu> greyback: For traditional texture uploads at least, it gets copied to the GPU. So you can reclaim the buffer immediately
[08:58] <duflu> Although I think our hardware surfaces don't get copied. So need more care
[08:59] <duflu> Never mind. If I have a promising idea I'll propose it
[08:59] <greyback> duflu: understood
[09:05] <duflu> greyback: Are there any software buffers used in practice on a phone, or all hardware?
[09:06] <greyback> duflu: sdl-based apps use software buffers I believe
[09:06] <duflu> greyback: OK, yeah I know about those. Same on desktop
[09:06] <greyback> yep
[09:09] <duflu> Does image 263 work for anyone else or am I being over-ambitious?
[09:15] <duflu> I guess that's why it's called "proposed"
[09:22] <alan_g> alf_: I'm deciding what to do for the rest of the sprint. Is "Fix fd leaks in acceptance tests" something I could take on?
[09:23] <alf_> alan_g: yes, feel free to do so
[10:08] <alf_> anpok_: ^^ See Daniel's comment about image 263
[10:08] <alf_> duflu: Did you find an image that boots?
[10:09] <alan_g> duflu: lp:1477051
[10:10] <alf_> alan_g: thanks
[10:14] <anpok_> alf_: I think I have an older image here too
[10:14] <alf_> anpok_: and it fails too?
[10:15] <anpok_> rc-proposed or devel-proposed
[10:15] <anpok_> hmm I flashed 280 it seems
[10:15] <ogra_> bug 1477051 FWIW
[10:16] <alf_> anpok_: so that's not devel-proposed then
[10:18] <alf_> anpok_: ah, sorry, ubuntu-touch/devel-proposed/ubuntu has a 280 image for krillin
[10:18] <alf_> anpok_: which is the latest
[10:19] <alf_> anpok_: the latest for ubuntu-touch/devel-proposed/ubuntu mako is 263
[10:21] <alf_> anpok_: I will try with 262
[10:28] <anpok_> ok i am on krillin #277 and spinner spins now
[10:30] <duflu> alf_: Yes, vivid works. But that doesn't help me right now
[10:31]  * duflu wanders off
[10:35] <alf_> anpok_: ubuntu-touch/devel-proposed/ubuntu mako 261 boots, will test silo with that
[10:36] <ogra_> only the latest images dont boot (see the bug i posted above)
[10:36] <ogra_> yesterdays builds should be fine
[10:36] <alf_> ogra_: ack
[15:07] <camako> vogons, after latest wily upgrade, my wifi doesn't work on my laptop (doesn't wired connection). Can't join standup.
[15:07] <camako> ... (doesn't have wired connection)
[16:25] <racarr> Morning!
[16:38] <conyoo> um.. it's 19:38 o_O
[16:39] <racarr> California \o/
[16:52] <conyoo> hehe :P
[21:03] <robert_ancell> kgunn, do you use a bluetooth mouse/keyboard in combination with a "slimport cable" (not sure of the actual term for it, i.e. the HDMI connector)
[21:03] <kgunn> robert_ancell: yes
[21:04] <kgunn> robert_ancell: yeah, it's "slimport"
[21:04] <kgunn> soon it will be replaced by mhl
[21:04] <kgunn> Mobile High-Definition Link
[21:05] <robert_ancell> kgunn, do neither of those options allows audio/video AND USB?
[21:06] <kgunn> robert_ancell: yeah, mhl is supposed to support audio i think...altho might depend on oem support/drivers
[21:06] <robert_ancell> kgunn, yeah, but by switching to MHL/slimport mode does it no longer do USB on those pins?
[21:06] <robert_ancell> So you could have a USB hub + HDMI connected
[21:07] <robert_ancell> i.e. a complete docking station
[21:07] <kgunn> robert_ancell: uh, that i don't know, altho at least with slimport there is a hub on a lot of cables....
[21:07] <kgunn> not sure if that's power only
[21:08] <kgunn> never check
[21:08] <kgunn> ed
[21:08] <robert_ancell> It appears to be just for power (so you can charge the phone while using the slimport)
[21:10] <robert_ancell> It appears an OTG cable will give you USB and a slimport gives you HDMI but you can't get both :(
[21:11] <robert_ancell> I wonder if any phone supports using an OTG + a DisplayLink device
[21:12] <anpok> robert_ancell: the mhl solutions should allow both
[21:14] <anpok> robert_ancell: can get an android buffer displayed on a drm device...?
[21:15] <robert_ancell> anpok, sounds difficult! I guess the Android driver spec doesn't require anything like this (yet)
[21:15] <anpok> http://support.displaylink.com/knowledgebase/articles/557853-how-do-i-connect-my-displaylink-device-to-my-andro
[21:15] <anpok> hmm
[21:16] <anpok> robert_ancell: we could just copy the contents in usc?
[21:17] <robert_ancell> anpok, yeah, I guess that's what the app is doing more or less