[02:11] <Saviq> duflu, re: bug #1255045 - it's very difficult to see on maguro the difference between black and turned off
[02:11] <Saviq> duflu, but I can see completely no reaction on the screen when pressing the power button
[02:15] <Saviq> duflu, and indeed the patch didn't help
[02:19] <duflu> Saviq: Can you look from a wide angle? A backlight usually bleeds through even a black screen from a sufficient angle
[02:19] <Saviq> duflu, yeah, problem is maguro is AMOLED - no backlight...
[02:19] <duflu> I suspect I've seen a similar bug on either Nexus 4 or Nexus 7. Can't remember which
[02:19] <duflu> Saviq: Oh, AMOLED FTW :/
[02:20] <Saviq> duflu, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1255045/comments/13 for some syslog activity
[02:21] <Saviq> duflu, so yeah, the lack of activity between power button and touch does not... prove anything... but also does not rule out your "it's black, not blank" suspicion
[02:21]  * Saviq tries surfaceflinger
[02:21] <duflu> Saviq: We might have to start with one of the Nexus's where it's more obvious on the traditional LCD
[02:22] <Saviq> duflu, yeah, except that bug is only happening on maguro isn't it?
[02:23] <duflu> Saviq: Maybe... I don't have maguro but am sure I saw a similar wake-on-touch problem on Nexus 4/7 some time recently
[02:24] <duflu> Hmm... and then there's the question; if the screen is truly asleep why power the touch sensor?
[02:24] <Saviq> duflu, ok, under surfaceflinger I managed to see the difference between blank and black... shite it's subtle, trying again under mir
[02:25] <Saviq> doesn't help it's past 3am here..
[02:30] <Saviq> so yeah, one step closer... I'm gonna go now... o/
[09:45] <Saviq> didrocks, https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016 seems to work!
[09:45] <didrocks> oh
[09:45] <didrocks> really?
[09:46] <Saviq> didrocks, just doing some more tests, but yeah
[09:46] <Saviq> as in... waiting 1 minute ;)
[09:46] <didrocks> Mirv: ^
[09:46] <didrocks> Mirv: so, if all planet aligns, can you publish Mir?
[09:47] <Saviq> didrocks, Mirv, I've unity-mir packages, but building unity8, too, as they need to be released together this time
[09:47] <tvoss_> Saviq, happy to test, too
[09:49] <Saviq> didrocks, Mirv, tvoss_ http://people.canonical.com/~msawicz/mir-maguro-blank/
[09:49] <Saviq> echo "expect stop" > ~phablet/.config/upstart/unity8.conf
[09:51] <Saviq> didrocks, Mirv, tvoss_, oh and yeah, that with ppa:ubuntu-unity/daily-build
[09:51] <Mirv> didrocks: Saviq: so the Mir landing actually becomes Mir + unity-mir + platform-api + u-s-c + unity8 landing?
[09:52] <Mirv> but yeah, preparing at least for such a beast
[09:52] <Saviq> Mirv, ultimately yes, but we still have a commit missing in unity8 before that can happen
[09:53] <Mirv> Saviq: ok
[09:53] <Saviq> ah crap
[09:53] <tvoss_> Saviq, ?
[09:53] <Saviq> didrocks, Mirv, tvoss_ the above ↑↑ not to .conf, but to .override
[09:54] <Mirv> Saviq: and that unity-mir fix too
[09:54] <Saviq> Mirv, right, that too
[09:54] <Mirv> ok, just updated the landing plan to reflect
[09:55] <Saviq> Mirv, could we publish Mir first, then land stuff in unity and unity-mir (as we're blocked on unity8 due to bug #1255578)
[09:55] <Saviq> Mirv, and then land unity8, unity-mir, unity-scopes-shell?
[09:55] <Mirv> Saviq: land mir, platform-api, unity-mir, unity-system-compositor, unity8 is the current list
[09:56] <Mirv> Saviq: only what is absolutely required, is unity-scopes-shell part of it too?
[09:56] <Saviq> Mirv, no, not absolutely required
[09:56] <Saviq> Mirv, https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212 is though
[09:56] <Mirv> ok, a separate landing item for that then please
[09:56] <Mirv> right, marking that to the sheet too
[09:56] <Saviq> Mirv, was already there
[09:57] <Mirv> Saviq: so is that MP "a commit missing"?
[09:57] <Saviq> Mirv, but "waiting for code"
[09:57] <Saviq> Mirv, not sure what you mean?
[09:58] <Mirv> Saviq: you said that unity8 is missing a commit, so is thar raise-sigstop the only commit needed still for unity8, similar to maguro fix being the only commit needed for unity-mir?
[09:58] <Saviq> Mirv, yes
[09:58] <Mirv> ok :)
[09:58] <Mirv> and yes the scopes is there in the landing asks
[09:59] <Saviq> Mirv, but we can't merge into unity8 until Mir is published, due to the above bug
[09:59] <Saviq> Mirv, or well, we can force it in
[09:59] <Mirv> Saviq: aha, ok, then a manual merge would be needed
[09:59] <Saviq> Mirv, ok, will do once there's more people +1'd
[10:00] <Mirv> yep, that's useful. bzr branch lp:unity8, bzr merge, bzr commit --author , bzr push. but yeah, only in very special cases, after enough +1:s and with landing team's approval I'd say :)
[10:00] <Saviq> or well, we can add daily build to it temporarily
[10:01] <Saviq> will run -ci with daily build on them, then
[10:01] <Mirv> oh right that technique too
[10:13] <Saviq> Mirv, hrm, any idea why that'd have failed http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/29/console ?
[10:13] <Saviq> libmirclient-dev (>= 0.1.2) but 0.1.1+14.04.20131120-0ubuntu1 is to be installed. :/
[10:14] <Saviq> Mirv, ah, Mir building in daily-build?
[10:15] <Saviq> seems we'll have to wait for that
[10:25] <Saviq> alan_g, re: https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016/comments/456116
[10:25] <Saviq> alan_g, http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/unity-mir/dbusscreen.cpp#L45
[10:26] <Saviq> wouldn't configure_output take care of pause/resume?
[10:26] <Saviq> or well, display->configure(), for that matter?
[10:28] <alan_g> Saviq: it just seems strange to pick out compositing
[10:29] <Saviq> alan_g, sure, I agree (bear in mind, I dunno Mir enough), but since we're already configuring the display, couldn't it do pause/resume internally, if there's no screens enabled?
[10:30] <alan_g> Saviq: I know the infrastructure isn't in place, but there should be a change notification for the display area covered by the screen
[10:30] <alan_g> At present it is a pretty brutal "there are changes somewhere"
[10:32] <Mirv> Saviq: seems not using daily-build PPA the 0.1.2 was already there
[10:32] <Saviq> Mirv, yeah, it's weird, but I think it got superseded by the new build already
[10:33] <Saviq> Mirv, and it's only libmirclient-dev that complained about the version, although that, by apt dep error standards, might not mean anything...
[10:33] <Saviq> Mirv, will restart once the new build gets published
[10:34] <Saviq> alan_g, ok understood
[10:35]  * alan_g disgs through the code...
[10:41] <alan_g> Saviq: OK, I suspect this is a hack around the absences of a schedule_compositing() call in compositor - and not really intended as a pause()/resume() cycle
[10:42] <Saviq> alan_g, sounds right, compositor should know when display comes on and schedule then, right?
[10:45] <alan_g> Saviq: well, I think it should be notified (and, in theory, told what area needs display) - unless the idea really is to pause the server
[10:46] <Saviq> Mirv, grrr, dep fail again :/
[10:47] <Saviq> Mirv, the hook name is definitely added http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/30/console
[10:47] <Saviq> Mirv, but indeed it doesn't seem to be executed??
[10:48]  * Saviq goes to -ci-eng
[10:49] <Mirv> Saviq: yeah, probably a job for CI team to check
[10:57] <Saviq> alan_g, FWIW, we would actually need a frame composited before turning the display back on, as now you can see the previous frame for a split second when turning the device on
[10:57] <alan_g> Saviq: ack
[11:00] <alan_g> Saviq: is the code we're looking at executing after the device is turned on or before?
[11:02] <Saviq> alan_g, I'd say after
[11:02] <Saviq> alan_g, i.e. we get notified that the screen was turned on, not that it's going to be turned on
[11:02] <Saviq> alan_g, that's something that will be better when we move the responsibility on that from powerd to unity-mir/unity8
[11:03] <alan_g> Saviq: that makes it hard to composite a frame beforehand
[11:03] <Saviq> alan_g, i.e. it will be told "you need to turn on now", and it will decide what to do and when to actually turn on
[11:03] <Saviq> alan_g, yeah of course
[11:03] <tvoss_> Saviq, do we have updated packages, yet?
[11:03] <alan_g> Although, I gather there wasn't a flash and then black
[11:04] <Saviq> tvoss_, still the same http://people.canonical.com/~msawicz/mir-maguro-blank/
[11:04] <Saviq> tvoss_, + daily-build ppa + unity8.override
[11:04] <alan_g> alf_: thoughts? https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016 (and ^^)
[11:04] <Saviq> tvoss_, although I have a unity8 package now
[11:04] <tvoss_> Saviq, okay, those work for me
[11:04]  * Saviq adds
[11:04] <tvoss_> Saviq, will give that package a spin, too
[11:05] <Saviq> tvoss_, pushed
[11:05] <Saviq> tvoss_, drop the .override for good measure
[11:05] <tvoss_> Saviq, ack
[11:06] <Saviq> /food
[11:10] <alf_> Saviq: alan_g: the DisplayChanger class holds the logic for properly reconfiguring the display (pausing/resuming), so that's what we should expose (or a similar interface), i.e., I don't think display->configure() should pause resume internally
[11:14] <alf_> Saviq: alan_g: about whether we should pause/resume or schedule_compositing() instead, it depends on how well our display classes deal with posting buffers if the display is off (right now not very well it seems)
[11:16] <alf_> Saviq: alan_g: and whether it actually makes sense to disable communications and input
[11:16] <alan_g> alf_: I also wonder if we should be processing input when the display is off
[11:17] <alf_> alan_g: don't we need to handle some kind of input event to wake up (e.g. power button press)?
[11:18] <alan_g> Hmm. but touch events going to apps?
[11:21] <alf_> alan_g: Turning off communications would solve that.
[11:22] <alan_g> alf_: maybe not - there was a time input bypassed the thread pool. I don't remember that changing.
[11:24] <alf_> alan_g: yes, so turning off communications _properly_ would solve that :)
[11:26] <alf_> alan_g: and then there is also the issue of showing previous state when we wake up (because the buffer contents are obsolete)...
[11:26] <alan_g> Anyway, it does look like code around patch is a cut down version of MediatingDisplayChanger
[11:27] <alan_g> Which, like you say is what we should expose
[11:39] <dandrader> any reason why all shell::Surface methods are virtual whereas surfaces:Surface are not. Both are concrete classes.
[11:41] <alan_g> dandrader: insanity
[11:41] <dandrader> lol
[11:41] <alan_g> dandrader: you're also looking at an old version
[11:42] <dandrader> alan_g, hmm, true!
[11:43] <dandrader> I'm playing with gerry's "qt scene graph" mir branch
[11:44] <alan_g> The newer version doesn't fix all the insanity, but is a step in a right direction.
[11:44]  * alan_g remembers he wants to look at that before next week
[12:25] <Saviq> Mirv, tvoss_, didrocks, ok so bug #1255948 will not let us through upstream merger, OK to force land those two commits before release?
[12:25] <didrocks> let me look, one sec
[12:25] <Saviq> greyback, can we have your ACK on https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016 ?
[12:26] <Saviq> didrocks, it's:
[12:26] <Saviq> https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212
[12:26] <Saviq> and https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016
[12:26] <didrocks> Saviq: if it's tested and really ready to land (with the whole Mir stuff), +1
[12:26] <greyback> Saviq: looking
[12:26]  * greyback confused why he doesn't get mail when a unity-mir MR is made
[12:27] <Saviq> greyback, there's a lot of confusion about LP mails if you ask me...
[12:28]  * Saviq installs the packages on mako and maguro, too
[12:29] <Saviq> s/maguro/manta/
[12:49] <Saviq> didrocks, pushed a fix to debian/control in https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212
[12:50] <alf_> Reading the meaningless (to most people) Android codenames, I think we should use mythical monsters for Ubuntu Touch codenames: Ubuntu Touch 2.0 Kraken, 3.0 Hydra etc :P
[12:50] <Saviq> tvoss_, Mirv, I can has more +1s?
[12:50] <Saviq> alf_, who would you get the billions of $$ from then?
[12:50] <didrocks> Saviq: looks good for packaging change
[12:50] <Saviq> alf_, like android did with KitKat? ;)
[12:52] <tvoss_> Saviq, installing too
[13:04] <tvoss_> hmmmm, what did I do to my nexus? Saviq, have you seen INFO:phablet-flash:Device detected as
[13:04] <tvoss_> ERROR:phablet-flash:Unsupported device, autodetect fails device
[13:04] <tvoss_> before?
[13:05] <Saviq> tvoss_, that happens when your device isn't booted
[13:05] <Saviq> tvoss_, -d <codename>
[13:05] <Saviq> tvoss_, to skip autodetection
[13:06] <tvoss_> Saviq, thx, works
[14:04] <Saviq> tvoss_, any updates?
[14:04]  * Saviq is tempted to just push the button
[14:05] <tvoss_> Saviq, works here
[14:05] <Saviq> ok, /me pokes the buttons
[14:09] <Saviq> Mirv, ready
[14:10] <Saviq> Mirv, hope it's not too late for you :/
[14:10] <Saviq> Mirv, both MPs are in trunks
[14:15] <Saviq> didrocks, ↑↑
[14:21] <didrocks> \o/
[14:21] <didrocks> I guess Mirv left
[14:21] <didrocks> Mirv: ?
[14:43] <didrocks> ok, no more Mirv I guess :)
[14:43] <didrocks> Saviq: so, mir, platform-api, unity-mir, unity-system-compositor + unity8, right?
[14:44] <didrocks> Saviq: do you know if the u-s-c FTBFS fix was merged?
[14:44] <Saviq> didrocks, no
[14:44] <Saviq> don't know
[14:44] <didrocks> seems, is was
[14:44] <didrocks> it*
[14:45] <Saviq> didrocks, looks like it, yeah
[14:45] <Saviq> https://code.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk
[14:45] <didrocks> Saviq: so, I'm adding that to robru's list
[14:45] <Saviq> didrocks, thanks
[14:45] <didrocks> Saviq: any particular thing to look at in unity8 trunk?
[14:45] <Saviq> didrocks, that it starts ;)
[14:46] <didrocks> well, that's a given :p
[14:46] <Saviq> didrocks, other than that there's a lot happened... 3 weeks no release almost
[14:50] <didrocks> ok
[16:41] <alan_g> alf_: are you fixing the the merge conflicts? https://code.launchpad.net/~afrantzis/mir/mir-client-ensure-global-symbol-resolution/+merge/196110
[16:42] <alf_> alan_g: I think I will wait for lp:~afrantzis/mir/build-options-for-tests to be merged, so I can follow the same scheme for special linkage tests build options
[16:43] <alf_> alan_g: do you want me to mark as WIP?
[16:43] <alan_g> alf_: fair enough
[16:43] <alan_g> alf_: No. Nobody's around anyway
[16:43] <alf_> alan_g: ok