[00:12] <kgunn> RAOF: hey, do you happen to know if/how xmir install/enabling changes with unity8-desktop-session-mir ?
[00:12] <kgunn> racarr_: ^ ?
[00:12] <RAOF> kgunn: Yes; is there anything in particular that you want to know?
[00:13] <kgunn> ....so i'm just wondering, unity8-desktop-session-mir installs unity-system-compositor....
[00:13] <kgunn> and installing u-s-c was the mechanism to install xmir
[00:13] <kgunn> ..i assumed it still was ?
[00:13] <kgunn> but guess it must not be true
[00:14] <kgunn> ...wonder, now, one must go modify /etc/lightdm/lightdm.conf.d/unity-system-compositor.conf ?
[00:15] <kgunn> i was thinking to test this...
[00:15] <kgunn> wondered if you knew off the top of your head
[00:20] <racarr_> kgunn: I think ubuntu-desktop-mir enables xmir
[00:21] <racarr_> err
[00:21] <racarr_> which is pulled in by unity8-desktop-session-x11 what?
[00:21] <racarr_> so lets hope not lol
[00:21] <kgunn> racarr_: ah-ha...unless, you already had a usc conf file...? which had #type-unity modified :)
[00:23] <racarr_> kgunn: I dunno, packages can either override or not override conf files...would have to look deeper
[00:24] <RAOF> kgunn: Yeah, if you already had a usc config file lying around it wouldn't overwrite it.
[00:25] <RAOF> kgunn: Assuming that the config file that the package wants to install is exactly the same as the config file at the time you modified it.
[00:27] <kgunn> ok...gonna just see if it still works, rebooting
[00:35] <RAOF> This bodes.
[00:45] <kgunn> uh well...that was unpleasant...
[00:46] <kgunn> usc log says https://pastebin.canonical.com/108519/
[00:55] <kgunn> RAOF: ^ in case something comes to mind...it could easily be something of mine
[00:55] <kgunn> setup incorrect...
[00:56] <kgunn> racarr_: totally...bag o candy, 8o clock...i got a sick belly now :(
[00:57]  * RAOF will check just as soon as his SSO 2fa device finishes being unresponsive.
[01:05] <RAOF> kgunn: Hrm. Looks like we failed to do drm setup there, which we should be able to do. I wonder if things like plymouth are being silly?
[01:06] <kgunn> RAOF: wanna join meeting ?
[01:06] <kgunn> it'll be quick one
[01:06] <RAOF> Sure.
[01:06] <RAOF> Was rather expecting it to be at 13:00
[01:15] <racarr_> kgunn: Oh no :(
[01:15] <racarr_> oh
[01:15] <racarr_> did I miss
[01:15] <racarr_> meeting
[01:16] <racarr_> I guess not that much to say
[01:16] <racarr_> RAOF: I am writing X Input driver
[01:16] <racarr_> I wont be able to get back to it until wednesday but its almost all done
[01:16] <RAOF> racarr_: Hurray!
[01:16] <racarr_> was going to test some basics of it but then had intel driver mis match...and
[01:16] <RAOF> racarr_: Also, meeting is on now. Come on down!
[01:16] <racarr_> I dunno probably just built wrong stuff during sprint
[02:01] <kgunn> thomi: are there specific instructions to the "Run the autopilot functional and unit tests" for desktop ?
[02:02] <kgunn> or just read the readme?
[02:02] <thomi> kgunn: I can show you here, if you like
[02:02] <thomi> you have the packages installed from the landing silo?
[02:02] <kgunn> thomi: just upgrading...will install as soon as that completes
[02:03] <thomi> ok
[02:03] <thomi> well, when that's done, opena  terminal and run:
[02:03] <thomi> autopilot run -o ap_2_results autopilot ; autopilot3 run -o ap_3_results autopilot
[02:04] <thomi> you'll want to double check that all the AP-related packages from the silo have been installed
[02:04] <thomi> especially: python-autopilot python-autopilot-tests python3-autopilot python3-autopilot-tests autopilot-desktop
[02:05] <kgunn> thomi: ok...will do that
[02:06] <kgunn> RAOF: duflu...weird you both expected the meeting to be later, but i updated and saved it earlier today....hmmm
[02:06] <kgunn> is there a google-american-aussie-daylightsavings-bug somewhere?
[02:08] <kgunn> RAOF: any other ideas on my xmir failing to start? (i'm updating just in case)
[02:08]  * kgunn wonders if there's a handy drm debug wiki
[02:12] <duflu> kgunn: Well my timezone never moves. Only the meeting did. Not sure why
[02:13] <RAOF> kgunn: Can you switch to a VT and try restarting lightdm? Can you ssh in and do the same?
[02:14]  * duflu is actually mostly impressed with being awake in the *morning* at all
[02:15] <kgunn> RAOF: i will try...kinda got too many spinning plates atm :)
[02:15]  * duflu mixes fresh XMir with fresh coffee
[02:43] <AlbertA> kgunn: just fyi I built against mir devel r1550 for the mir-0.1.9 branches I sent you
[03:02] <duflu> kgunn: Yeah using that PPA XMir doesn't start (normal X starts fine instead)
[03:03] <duflu> Probably because USC is never started
[03:06] <RAOF> Hm. This test is becoming more complex than the code it's trying to test. Time to rethink.
[03:28] <kgunn> thomi: so...i ran autopilot run -o ap_2_results autopilot
[03:28] <kgunn> and it ran a bunch of stuff...
[03:28] <kgunn> no failures
[03:29] <kgunn> but no summary either
[03:29] <kgunn> normal ?
[03:29] <thomi> kgunn: it'll be in the ap_2_results file
[03:29] <thomi> that's what the -o bit does
[03:30] <kgunn> thomi: thanks (i should've read the command line and thot a little)
[03:30] <thomi> kgunn: :)
[03:30] <kgunn> all pass btw
[03:30] <thomi> kgunn: sweet - now you gotta repeat with 'autopilot3' :)
[03:33] <thomi> kgunn: I gotta head out for 45 minutes or so. If you need anything in the mean time, I'msure veebers can help you in #ubuntu-autopilot
[03:33] <kgunn_> RAOF, racarr_ interesting...so i'm on my clean machine, installing unity8-desktop-session-mir, which in turn installs u-s-c, did not create a /etc/lightdm/lightdm,conf.d/10-unity-system-compositor.conf file
[03:46] <duflu> kgunn_: That would explain why XMir wasn't running either :)
[03:49] <kgunn_> duflu, nope, completely different machine...other machine, i had a 10-usc.conf file....
[03:51] <RAOF> kgunn_: Got ubuntu-desktop-mir installed?
[03:52] <kgunn> RAOF: on the new machine...no
[03:52] <RAOF> kgunn: That is the package with 10-unity-system-compositor.conf in it.
[03:53] <kgunn> huh...not installed on this machine either
[03:53] <duflu> I knew that was true. But it's a problem for Unity8 it seems
[03:53] <kgunn> hmmm....ok, so unity-system-compositor no longer installs ubuntu-desktop-mir ?
[03:53] <RAOF> Apparently so.
[03:54] <duflu> Maybe?... what does "ubuntu-desktop-mir" mean? Does it mean XMir or "XMir or Unity8"?
[03:54] <kgunn> duflu: afaict, unity8-desktop-session-mir....means unity8
[03:54] <kgunn> on mir
[03:54] <kgunn> but unity7 still on x (no mir)
[03:54] <duflu> kgunn: So we either need to depend on ubuntu-desktop-mir or move the conf file to another package...
[03:54] <kgunn> whereas ubuntu-desktop-mir means xmir (guessing there)
[03:55] <kgunn> or just change the instructions ?
[03:55] <duflu> Ah but ubuntu-desktop-mir isn not XMir-specific, is it?
[03:55] <kgunn> RAOF: ^ ?
[03:56]  * duflu checks package contents
[03:56] <RAOF> kgunn: Dunno; I didn't do those packages :)
[03:57] <duflu> kgunn: The only purpose (only content) of ubuntu-desktop-mir is to provide 10-unity-system-compositor.conf. Unfortunately it depends on xserver-xorg-xmir, which I think we should uncouple
[03:59] <duflu> ... and then unity8 can cleanly depend on ubuntu-desktop-mir. As should xserver-xorg-xmir (i.e. reverse the current dependency)
[04:00]  * duflu now wonders why the USC conf is not included in USC packages
[04:00] <duflu> That would make more sense -- I have USC installed and therefore I expect it to start\
[04:01] <RAOF> I don't know if unity8-desktop-session-mir is expected to work on a raw VT or not.
[04:01] <kgunn> so on my clean machine, just installed ubuntu-desktop-mir...still no conf file installed
[04:01] <RAOF> I don't know why unity8-desktop-session-x11 depends on ubuntu-desktop-mir, though.
[04:01] <kgunn> ok..i'll try again tomorrow...i need to tie loose ends and go to bed
[04:01] <kgunn> RAOF: duflu ...btw, silo3 ppa may actually build (...making it sucessfully thru usc now)
[04:01] <kgunn> so if you wanted to test xmir with https://launchpad.net/~ci-train-ppa-service/+archive/landing-003
[04:01] <kgunn> and send a mail...that'd be great
[04:01] <duflu> kgunn: I think we should abolish ubuntu-desktop-mir. It's confusing and it's only contents (the conf file) would be better placed in the USC package
[04:02] <duflu> -it's +its
[04:02] <kgunn> duflu: might file a bug and flag bregma to stay in sync
[04:04] <RAOF> That seems sensible.
[04:04] <duflu> Well as usual it's a simple change to make... if only I can find the branches (often the greatest challenge)
[04:06] <duflu> On second thoughts, I don't know lightdm that well. Might be missing something
[05:24] <duflu> RAOF, all: Please?https://code.launchpad.net/~vanvugt/mir/version-0.1.9/+merge/215804
[05:25] <duflu> There's more to come too
[09:45] <alf_> Saviq: Hi! Where does unity8 keep its log on the phone (e.g. if I print to stderr from the unity8 process)?
[10:11] <anpok> alf_: ~/.cache/upstart/unity8.log.*
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== greyback_ is now known as greyback|lunch
=== greyback|lunch is now known as greyback
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
[15:52] <josharenson> When I try to cross compile mir (in my own feature branch) get an error about the boost libs not being found. Compiling any other branch works just fine... Any pointers? I have changed a lot of cmakefiles, but nothing that should have affected libboost
[15:54] <alan_g> josharenson: are the boost libs in your cross-compilation environment and not being found or are they not being installed there?
[15:55] <josharenson> alan_g not being found I believe
[15:55] <josharenson> http://pastebin.ubuntu.com/7256002/  shows the first of several errors
[15:58] <alan_g> josharenson: You're setting CMAKE_PREFIX_PATH to somewhere useful?
[15:58] <alan_g> Oops PKG_CONFIG_PATH
[15:59] <josharenson> alan_g never had to do that before... should I try setting it to /usr/bin ?
[15:59] <alan_g> No, to wherever you're installing your target libraries
[16:00] <josharenson> ok
[16:00] <alan_g> s/libraries/packages/
[16:00] <alan_g> E.g. from cross-compile-chroot.sh : export PKG_CONFIG_PATH="${MIR_NDK_PATH}/usr/lib/pkgconfig:${MIR_NDK_PATH}/usr/lib/arm-linux-gnueabihf/pkgconfig"
[16:03] <josharenson> alan_g yes I tried that manually and via the script
[16:03] <josharenson> re-downloading some deps over airplane wifi right now.....
[16:07] <josharenson> hummm seem to be getting 404s for all armhf repositories
=== dandrader is now known as dandrader|lunch
=== alan_g is now known as alan_g|EOD
=== dandrader|lunch is now known as dandrader
[19:26] <kgunn> racarr_: kdub ...so that whole "scene observer" discussion going on, is that going to be another hit on server api ?
[19:26] <kgunn> i'm just starting to wonder if we should just plan on cherry picking the non-blocking egl (...feels like an endless api update exercise otherwise)
[19:35] <racarr_> kgunn: Yeah it would be
[19:37] <kgunn> racarr_: so do you think we're killing ourselves trying to work this particular item at high priority while also keeping step with all the other churn ?
[19:39] <kgunn> AlbertA: thots ^ ? guess you suffered y'day...
[19:39] <AlbertA> kgunn: I've rebased the branches to tip again locally
[19:40] <AlbertA> kgunn: well actually only papi was affected
[19:40] <AlbertA> kgunn: trying to cross-compile to test
[19:41] <kgunn> AlbertA: on papi was it the removal of the placement strategy ?
[19:41] <AlbertA> kgunn: yeah
[19:46] <racarr_> kgunn: Ah sorry. It's
[19:46] <racarr_> server ABI
[19:46] <racarr_> but not sever API
[19:46] <kgunn> AlbertA: ok..just worrying there's more to come e.g. "scene observer" , cursor stuff, input dispatcher,
[19:46] <racarr_> cursor stuff also breaks ABI but not API
[19:46] <kgunn> racarr_:  true..that makes it less churn-y
[19:47] <AlbertA> kgunn: for 0.1.9?
[19:47] <AlbertA> kgunn: when do we expect to tag?
[19:47] <kgunn> AlbertA: yeah...since its not really tagged
[19:47] <kgunn> well...that's just it, if we take a "wholesale" approach...we need to tag _after_ we get mir good to go for non-blocking swap
[19:48] <kgunn> if we take a cherry pick approach...it'll just be rework pain for alf
[19:49] <racarr_> ok well all this stuff doesnt have to land quite let
[19:49] <racarr_> yet
[19:49] <racarr_> no one minds MPs sitting around if everything is an approve
[19:49] <kdub> kgunn, I have something for the android overlays to work on that shouldn't hit much server api, I can switch to that for a bit so there's less churn from me for a few days
[19:49] <racarr_> imo
[19:50] <AlbertA> kgunn: yeah theres's only 4 MPs ready to land which should not break api
[19:50] <AlbertA> kgunn: I'm holding off on the one that does (add uid/gid) after tagging
[19:54]  * kdub to lunch
[19:55] <kgunn> thanks AlbertA, kdub, racarr_ ...if we can keep it a bit more "calm" for some days it'll help for sure
[19:55] <kgunn> i might still get my arm twisted
[19:55] <kgunn> by rel team to cherry pick
[20:02] <racarr_> ok well keep it cool
[20:48] <racarr_> hmm
[20:49] <racarr_> this scene observer + register surface observer approach ends up being really annoying for the compositor
[20:49] <racarr_> because its hard to unregister
[20:49] <racarr_> oh nvm I can just move the
[20:49] <racarr_> started/stopped check in to the callback, it already owns the right lock
[20:50] <racarr_> so its the same
[20:50] <racarr_> lalala
[21:13] <AlbertA> racarr-
[21:13] <AlbertA> racarr_: note that logic is about to change a little bit
[21:13] <AlbertA> racarr_: the compositor start/stop state
[21:15] <racarr_> AlbertA: Mm..I think it will be fine
[21:15] <racarr_> we will find out soon :p almost to that part
[21:26] <AlbertA> kgunn: there's a deadlock issue with non-blocking
[21:26] <kgunn> AlbertA: awesome :-/
[21:26] <kgunn> how is that possible ?
[21:26] <kgunn> ....its non blocking :)
[21:26] <kgunn> lol
[21:26] <AlbertA> kgunn: he yeah It does sound ironic
[21:26] <kdub> haha
[21:26] <kgunn> at least it made me laugh a little...
[21:27] <AlbertA> kgunn: if you turn off the screen
[21:27] <AlbertA> kgunn: and try to turn it back on it will never turn back on
[21:27] <AlbertA> kgunn: it's waiting for allthe compositors to stop
[21:28] <AlbertA> kgunn: but at the same time, the display is waiting on a power on  condition so it can unblock
[21:28] <AlbertA> kgunn: so deadlock
[21:29] <AlbertA> kgunn: what was the issue alexandros was looking at? that or something else?
[21:31] <kgunn> AlbertA: so is it basically that it needs your powerd change to land first?
[21:31] <AlbertA> kgunn: no it's real deadlock
[21:31] <AlbertA> kgunn: just trying to understand how we can fix it
[21:31] <kgunn> AlbertA: he was looking at 2 things...1 was apps in background still blocked
[21:32] <kgunn> and then 2 some apps seemed to not render (or render beneath the shell)
[21:34] <AlbertA> kgunn: ah I see what's happening...
[21:35] <AlbertA> we turn stop the compositors, turn off the display, start the compositors again
[21:35] <AlbertA> the display buffer compositors then try to post to display buffer
[21:36] <AlbertA> which will be locked
[21:36] <AlbertA> waiting for a power on change
[21:36] <AlbertA> press the power button again, we try to stop compositors
[21:36] <AlbertA> and we wait forever since one of them is blocked
[21:37] <kgunn> you mean even with the change we "stop the compositors" ?
[21:37] <AlbertA> the display buffer compositor yeah
[21:37] <AlbertA> which makes sense
[21:37] <AlbertA> well
[21:37] <kgunn> b/c they can't touch FB's at that time ?
[21:38] <AlbertA> kgunn: yeah
[21:38] <racarr_> RAOF: Can you review cursor spike phase 1 again when you have time?
[21:38] <kgunn> AlbertA: i'd agree with that...yeah, you gotta stop, to just "release" the FB's
[21:39] <AlbertA> kgunn: I guess I can fix it in usc
[21:40] <kgunn> AlbertA: i guess its "after display off, compositors start again"...why does it try to post to FB ?
[21:40] <AlbertA> kgunn: if we are going to power on, power on display first
[21:40] <kgunn> AlbertA: oh, you're assuming a rapid sucession of power button striking...e.g. this specific case is its "going to on"
[21:41] <AlbertA> kgunn: why? because the multi threaded compositor has no idea about the display buffer power state
[21:41] <AlbertA> kgunn: so it just receives start/stop
[21:41] <AlbertA> kgunn: this is specific to going off then going on, it happens all the time for me
[21:42] <AlbertA> kgunn: I don't see how it cannot actually
[21:42] <AlbertA> kgunn: unless you are really fast yeah...then you shoulnd't see it :)
[21:42] <kgunn> AlbertA: oh wait...you mean its not rapid...reaching steady state for off
[21:42] <AlbertA> kgunn: yeah just a normal power off
[21:43] <AlbertA> kgunn: then a casual power on
[21:46] <kgunn> AlbertA: so when pressing the button to go to "on"...why do we try to "stop the compositors" again ?...e.g. aren't they in effect already stopped ?
[21:46] <kgunn> i guess state-wise, they're technically not
[21:46] <kgunn> ?
[21:47] <AlbertA> kgunn: yeah that's what I'm changing now
[21:47] <AlbertA> kgunn: if on = just turn on the display
[21:47] <kgunn> right
[21:47] <AlbertA> kgunn: if off = stop compositors, change display state, turn compositors back on
[21:50] <AlbertA> kgunn: that will mean that we'll still have at least one stale buffer though
[21:51] <AlbertA> kgunn: but I suppose we can work on that issue
[21:51] <AlbertA> kgunn: later
[21:51] <kgunn> AlbertA: yeah...its no worse than what we have at the moment
[21:51] <kgunn> which is like a whole pipeline :)
[21:53] <AlbertA> kgunn: ok this works
[21:53] <AlbertA> kgunn: anything in particular I need to test for non-blocking?
[21:54] <kgunn> AlbertA: hit power button, screen off with music playing, try volume
[21:54] <kgunn> if volume keys work, then gui thd is svcing events
[21:55] <AlbertA> kgunn: send mp3 through adb?
[21:55] <kgunn> AlbertA: shamefully, i dunno :)
[21:59] <AlbertA> kgunn: well volume keys not working
[22:00] <kgunn> damnit
[22:01] <AlbertA> kgunn: btw yeah sending mp3 through adb to /home/phablet/Music worked fine
[22:01] <kgunn> AlbertA: this all seems strange...i don't think alf_ & greyback ever saw the display off deadlock, and the volume keys worked
[22:02] <AlbertA> kgunn: strange..let me see the mir history
[22:02] <kgunn> just thinking with them specifically testing screen off....they would see that
[22:06] <kgunn> almost sounds like the compositors didn't "turn back on" in the sequence of comp-off, change-dpy-state, comp-on
[22:08] <AlbertA> kgunn: I was testing with the fix proposed today, let me back that up
[22:16] <AlbertA> kgunn: well I don't know what I'm missing...
[22:16] <AlbertA> kgunn: I'm using the updated 0.1.9 branches for umir/usc/papi
[22:17] <AlbertA> kgunn: and mir r1557 with alf's patch on top
[22:20] <AlbertA> kgunn: oh I think I may need a unity change no? I think by default they pause when they receive the display off
[22:20] <AlbertA> notification
[22:20] <AlbertA> Shell.qml?
[22:30] <kgunn> AlbertA: yeah...actually i thikn greyback commented out his changes in qtubuntu right before he EOD'd
[22:30] <kgunn> he said something about it not doing what he thot
[22:31] <AlbertA> kgunn: well I took out the greeter.show after a power off is received
[22:31] <kgunn> hmmm...
[22:31] <kgunn> https://code.launchpad.net/~gerboland/qtubuntu/surface-visible-hidden-side-channel/+merge/215884
[22:31] <AlbertA> kgunn: that did the trick
[22:31] <kgunn> he has attempt 2
[22:31] <kgunn> oh cool...
[22:32] <AlbertA> kgunn: in Shell.qml
[22:33] <AlbertA> kgunn: I guess that triggers Qt's window management
[22:34] <kgunn> AlbertA: does it do that pre-emptively ?
[22:34] <kgunn> oh...yeah, maybe ?
[22:34] <kgunn> mterry: might know ^
[22:34]  * mterry  looks
[22:35] <kgunn> mterry: mainly, the greeter.show from shell in a display off case
[22:36] <mterry> kgunn, er, what problems does the greeter.show cause?
[22:37] <AlbertA> mterry: the volume keys didn't work with the non-blocking egl swapbuffers branches
[22:37] <AlbertA> mterry: after greeter.show
[22:37] <AlbertA> mterry: if I take it out, during screen on, the volume keys work while playing music
[22:38] <AlbertA> sorry screen off
[22:38] <mterry> AlbertA, OK...  so the shell is trying to render frames while screen off, and it can't take input as a result...
[22:39] <mterry> AlbertA, I wouldn't say that would involve Qt's window management, unless you mean a low-level window.  The greeter is just a Qml object being slid offscreen and on
[22:39] <AlbertA> mterry: but it should be able to render now with the non-blocking implementation
[22:40] <mterry> AlbertA, right...  Is it greeter specific?  Like, if you show something else..  Like maybe the launcher or something
[22:41] <AlbertA> mterry: you mean do that in Shell.qml?
[22:41] <AlbertA> mterry: of just leave the launcher on, hit power off
[22:41] <mterry> AlbertA, yeah, keep greeter.show() commented out, but maybe do launcher.show() instead
[22:41] <AlbertA> mterry: let me see
[22:42] <mterry> AlbertA, just as a test to see if it's just anything with frames, or if greeter is doing something insane
[22:42] <AlbertA> kgunn: I'm wondering now if eglSwapBuffers is blocking at the driver this time
[22:43] <kgunn> AlbertA: very well would....at the driver level it would
[22:43] <kgunn> most likely
[22:45] <AlbertA> kgunn: oh...maybe we are hitting autosuspend
[22:46] <AlbertA> kgunn: nah but then the music wouldnt' play
[22:46] <racarr_> *not entirely sure I undewrstand the context*
[22:47] <racarr_> but in this case eglSwapBuffers is mir egl swap buffers right so
[22:47] <racarr_> I mean it only blocks if we block it?
[22:47] <AlbertA> racarr_: it still goes through the driver first though
[22:47] <kgunn> AlbertA: the music can play ok...it just won't advance to the next song or vol change
[22:48] <kgunn> gotta restart....
[22:49] <AlbertA> mterry: launcher.show() doesn't do anything, It doesn't show the launcher
[22:49] <mterry> AlbertA, oh really?  let me see Shell.qml
[22:49] <AlbertA> mterry: should that me showNow()?
[22:50] <mterry> AlbertA, how about launcher.tease() then
[22:50] <mterry> AlbertA, show() is not used, because the launcher is always dragged, not programmatically shown
[22:52] <AlbertA> racarr_: so it goes through the driver then the driver calls us through AnativeWindow methods for android drivers
[22:52] <racarr_> yes. I guess I just assumed it doesnt do any direct
[22:53] <racarr_> hardware access itself or
[22:53] <racarr_> try and do anything fancy but who knows
[22:53] <AlbertA> well you never know, it's an egl context after all
[22:53] <AlbertA> mterry: yeah that worked
[22:53] <mterry> AlbertA, volume worked too?
[22:54] <AlbertA> mterry: nah same issue
[22:54] <AlbertA> mterry: which means we really do need Gerry's side channel branch
[22:54] <mterry> AlbertA, OK, well good that greeter isn't doing something weird.  Just general qml stuff then
[22:54] <AlbertA> mterry: right
[22:56] <AlbertA> kgunn_: so it looks like it still blocks when qml tries to render things
[22:58] <AlbertA> kgunn_: maybe I'm not pushing the correct libraries for mir nested
[22:58] <AlbertA> kgunn_:I 'll check that
[22:58] <kgunn_> ack
[23:03] <AlbertA> kgunn_: well that wasn't it, I can see in the log the fake compositor is posting
[23:03] <AlbertA> kgunn_: both in usc and unity8
[23:04] <AlbertA> kgunn_: I guess time for gdb
[23:07] <kgunn_> man....
[23:07] <kgunn_> definitely leave the findings in a mail for gerry & alf
[23:16] <AlbertA> kgunn_: the good news is that it doesn't seem to be blocked at the driver
[23:16] <AlbertA> kgunn_: it's blocked at the client side waiting for the next buffer
[23:16] <AlbertA> kgunn_: yeah I'll put all this on an e-mail
[23:17] <AlbertA> kgunn_: ah I think I know why
[23:18] <kgunn_> ....cliffhanger....why ?
[23:18] <AlbertA> kgunn_: well since the display compositors are blocked
[23:19] <AlbertA> kgunn_: they are never going to release the buffer they are holding
[23:19] <AlbertA> kgun__: so eventually we consume all buffers from client but we have to return in sequence
[23:19] <kgunn_> so it just blocks on buffers being full...
[23:19] <AlbertA> kgunn: and that only happens when all compositors release their reference
[23:20] <AlbertA> kgunn: so we probably need a way to just start the fake compositor only
[23:21] <AlbertA> kgunn: at display off
[23:21] <kgunn_> this is what duflu was hinting at i think...wrt unsync'd swapinterval0
[23:22] <AlbertA> kgunn: uhhh, yeah we have to guarantee sequence
[23:23] <AlbertA> kgunn: but that's ok, the fake compositor will guarantee that