[06:43] <duflu> RAOF: Another mini-fix... https://bugs.launchpad.net/xmir/+bug/1233044
[08:22] <alf_> alan_g: greyback: Good morning! I remember you had a conversation about _suspend vs _connection_lost. Did you reach a conclusion?
[08:23] <greyback> alf_: hey, I was happy with alan_g's proposal to have separate signal
[08:23] <alan_g> alf_: yes greyback agreed that a separate event was warranted
[08:24] <alf_> alan_g: greyback: great, thanks
[08:31] <budgee> Good morning team
[08:33] <budgee> I just plugged in an external monitor to my X301 and Xmir ?? appeared to crash and then restart with the external correctly recognised.  I was able to use displays to change the location of the external and launcher placement and am typing this message now using the configuration.
[08:33] <budgee> ie. I had to log back into Ubuntu and restart my apps after pluggin in the external.
[08:34] <budgee> If there is some loggin i can send through that would be useful, please let me know.
[08:34] <budgee> ps. Good morning here in SA - Good day wherever else you might be.
[08:35] <budgee> Also, unplugging the external worked fine - reconfigured to laptop display only with no problem.
[08:46] <alf_> budgee: https://bugs.launchpad.net/xmir/+filebug , please include at least the Xorg log of the crashed run (probably /var/log/Xorg.*.log.old). Note that xmir multimonitor support is under development, so not all issues have been ironed out yet.
[08:51] <duflu> budgee: Try "ubuntu-bug mir"
[10:55] <tvoss> good morning/afternoon/evening
[10:55] <alan_g> tvoss: hello there
[10:56] <tvoss> alan_g, hey :) back in service after my vacation
[11:05] <alf_> tvoss: welcome back
[11:05] <tvoss> alf_, thank you :)
[11:13] <alan_g> tvoss_: welcome back (again)
[11:13] <tvoss_> alan_g, yup :)
[11:21] <alan_g> tvoss_: beyond using another process can you think of any way to remove the Mir endpoint when Mir dies with prejudice? (kill -9 and the like)
[11:25] <tvoss_> alan_g, let me think
[11:32] <alf_> alan_g: tvoss_: Do we care about the SIGKILL case (which we can't catch in-process)? We could handle at least SIGSEGV and SIGABRT in process. The only other solution I can see is handling this in a wrapper script (e.g. unity-system-compositor.sleep).
[11:33] <tvoss_> alf_, fair point, I wonder if upstart is able to handle that scenario
[11:41] <alan_g> alf_: tvoss_ I'm just wondering: if some cases require handling elsewhere anyway how much Mir should try to do?
[11:47] <tvoss_> alan_g, my vote would be: as much as possible, perhaps defining a std::at_exit handler
[11:50] <alan_g> tvoss_: Ok, I've been playing with that. But with SIGSEGV we are getting into "undefined behaviour" territory and can't make guarantees
[11:50] <tvoss_> alan_g, sure, that's what I meant with "as much as possible" under usual constraints. Makes sense?
[11:50] <alf_> alan_g: tvoss_: mir can catch all of the signals that are caused by internal malfunction, so it makes sense to do the little it can (probably just unlink("/tmp/mir_socket") and _exit()) in the handler
[11:51] <tvoss_> alf_, yup, +1
[11:52] <alan_g> tvoss_: alf_ - OK. I just hoped someone knew of a magic API that said "this endpoint only lasts as long as this process"
[11:56] <davmor2> out of interest when wir becomes the default on the phone will there be the ability to do /home/user/.display-surfaceflinger for comparison of issues?
[11:56] <davmor2> s/wir/mir
[11:57] <ogra_> davmor2, no, but rm /home/phablet/.display-mir
[11:58] <ogra_> the switch means in the beginning that we'll just put that file in place by default
[11:58] <davmor2> ogra_: ah right so you are just enabling it like that initially then that's great
[11:58] <ogra_> lool, oh, the livecd-rootfs change wont be enough btw
[11:59] <ogra_> lool, it wont affect OTS updates ... probably a good first test scenario for the upgrade hooks :)
[11:59] <ogra_> *OTA
[11:59] <lool> ogra_: that's a good point
[12:00] <ogra_> and we only want to set it once indeed
[12:19] <budgee> alf_: duflu: ubuntu-bug mir bombs on package name.  What package name should I use? Output here: http://pastebin.com/HUf8qPes
[12:20] <budgee> alf_: duflu: xserver-xorg-xmir ?
[12:22] <alf_> budgee: yes, try with xserver-xorg-xmir, and we will retarget to mir if needed (but probably xmir is the right package anyway)
[13:10] <budgee> alf_: done as https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1236353
[13:10] <alf_> budgee: great, thanks
[13:10] <tvoss_> ogra_, ping
[13:11] <budgee> alf_: the XXorgLogOld.txt has a segfault it in
[13:11] <tvoss_> ogra_, is upstart able to clean up after a service? e.g., remove a stale socket?
[13:12] <ogra_> yeah, do it in a "post-stop script"
[13:12] <tvoss_> ogra_, got a documentation link handy?
[13:13] <ogra_> tvoss_, http://upstart.ubuntu.com/cookbook/#post-stop
[13:14] <tvoss_> alan_g|lunch, alf_ http://upstart.ubuntu.com/cookbook/#post-stop
[13:14] <tvoss_> ogra_, thanks
[13:30] <alesage> hi all, investigating a hang while changing wallpapers on phone, reproduces without fail under mir, any suggestions?  https://bugs.launchpad.net/ubuntu-system-settings/+bug/1234733
[13:45] <alf_> alesage: this sounds like it's related to https://bugs.launchpad.net/mir/+bug/1234609 which has a lot of duplicates (like the one you mention 1235195)
[13:48] <alesage> alf_ ok although I don't get the noted crash FWIW; will wait for a resolution of your linked bug and test again
[13:49] <alesage> alf_, thx
[13:51] <alan_g> tvoss_: I'd guess pre-start would be better - the real difficulty is that the stale endpoint interferes with starting a new process
[13:52] <alf_> alesage: it could be something different indeed, but with 1234609 in the middle it's difficult to say
[14:07] <tvoss_> alan_g, I think both might be a good idea
[14:07]  * alan_g wonders where to put an upstart script
[14:33] <tedg> alan_g, /usr/share/upstart/sessions
[14:34] <alan_g> tedg: I meant where in which project. ;)
[14:34] <tedg> alan_g, Ah, which ever has the binaries you're executing :-)
[14:35] <kgunn> kdub: so, gerry & duflu reporting we actually didn't fix the "unable to screen blank" prob after all
[14:35] <kgunn> https://bugs.launchpad.net/mir/+bug/1188504
[14:35] <kgunn> kdub: ^ can you take a look today ?
[14:36] <kgunn> tvoss_: o/ welcome back
[14:37] <tvoss_> kgunn, o/
[14:37] <mlankhorst> wb
[15:03] <kdub> kgunn, there are two issues (last i saw) that result in that error
[15:50] <kgunn> racarr: ping
[15:56] <kgunn> kdub: so, i just flashed latest, left it read only...enabled mir...and when screen idles/blanks...i can wake it no problem ?
[15:56] <kgunn> kdub: is the problem still limited to killing/restarting unity8 ?
[15:56] <kgunn> kdub: someone earlier said it was failing to "wake" when just idling...
[15:57]  * kgunn hates bug rumors, prefers real data written down :-/
[15:57] <kgunn> kdub: or maybe its intermittent... ?
[15:57] <kdub> kgunn, i've seen a bug that happens when the screen times out, then you push power button
[15:57] <kdub> you get 'cannot blank screen'
[15:57] <kgunn> kdub: hmmm....but i'm sitting here doing that
[15:58] <kdub> i also was seeing mir just not starting
[15:58] <kdub> which i'm trying to verify now
[15:59] <kgunn> kdub: i'm on mako, build 83
[15:59] <kgunn> channel devel-proposed
[15:59] <kgunn> fwiw i also do --no-backup
[15:59] <kdub> let me verify that's what i'm using, that's what i flashed with
[16:01] <kdub> kgunn, yes, 83, with channel devel-proposed
[16:03] <kgunn> kdub: did you do --no-backup ? (wonder if that could be related)
[16:04] <kdub> yes, all these flash switches are flummoxing though
[16:10] <kgunn> kdub: ...even after i reboot, its still waking like a champ
[16:11] <kgunn> kdub: just thinking of other deltas you and i might have...i don't have a sim card in my phone
[16:12] <kdub> kgunn, mir was working for me without writable mode, so i don't think that's a factor
[16:13] <kdub> i probably just wasn't controlling for the power button state
[16:14] <kgunn> racarr: ping
[16:25] <tvoss_> kdub, ping
[16:25] <kdub> pong
[16:26] <alan_g> alf_: does this make sense? https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376
[16:30] <kgunn> tvoss_: hey  i know Saviq asked you to look at  mir  being suddnely slow 1235190, did you have something specific you were chasing?
[16:31] <tvoss_> kgunn, I was more or less bisecting Mir changes
[16:31] <kgunn> racarr: when you get on, can you please check in with dandrader|lunch for mir input 1233245
[16:32] <kgunn> tvoss_: ack... if you conclude could also use help on the mir input 1233245
[16:32] <kgunn> tvoss_: that is, unless racarr shows up and just says "oh i know..." :)
[16:32] <tvoss_> kgunn, there are only 2 changes to mir that might affect rendering performance
[16:39] <racarr> Morning
[16:39] <racarr> kgunn: Yes willcheck it out in just a sec
[16:40] <alan_g> Evening
[16:40] <kgunn> racarr: thanks!
[16:40] <kgunn> brb
[17:04] <racarr> ok back
[17:04] <racarr> dandrader|lunch: What went wrong with the input injector approach to
[17:05] <racarr> 1233245?
[17:14] <racarr> kgunn: Also on my plate is #1233564 (the stuff about compositor empty queue)
[17:14] <racarr> and back to ABI stuff
[17:14] <racarr> should I run with 1233245?
[17:16] <racarr> alf_: Can you look at input-injecter-api again and at least needs fixing->abstain? I think I fixed your bits
[17:25] <dandrader> racarr, Saviq said that such approach doesn't suffice. that we need unity8/shell to be the focused surface shen it's no foreground so that things like key events generated from autopilot reaches it, etc
[17:25] <dandrader> s/shen/when
[17:25] <dandrader> s/no/on
[17:25] <dandrader> so many typos
[17:26] <dandrader> and then the sheer number of interfaces, indirections, abstractions in mir regarding focus scared me off :)
[17:26] <dandrader> intimidating
[17:26] <racarr> ok
[17:26] <racarr> but focus doesn't fix
[17:26] <racarr> the volume keys unfortunately
[17:27] <racarr> because unity8 needs to get volume keys when an app is focused
[17:27] <racarr> so we have two issues I guess
[17:27] <dandrader> racarr, but that's not importand
[17:27] <racarr> really unity8 needs to use the event filters....
[17:27] <dandrader> important
[17:27] <racarr> ok.
[17:27] <dandrader> for now, according to Saviq
[17:30] <racarr> ok
[17:30] <racarr> unity8 will need like an event filter
[17:30] <racarr> that gives focus to touched surfaces
[17:30] <racarr> and that should be enough
[17:31] <dandrader> racarr, hmm. user swipes away foreground app. unity8 qml calls unfocusCurrentApplication() in unity-mir (or something like that)
[17:31] <dandrader> at some point there unity8 should get focus in place of the unfocused app
[17:32] <dandrader> without the user having to touch dash
[17:32] <dandrader> if I understand you correctly
[17:32] <racarr> oh
[17:32] <racarr> so is it only
[17:32] <racarr> replace:     m_mirServer->the_session_manager()->set_focus_to(NULL); //FIXME(greyback)
[17:32] <racarr> with m_mirServer->the_session_manager->set_focus_to(shell_surface)
[17:33] <racarr> except
[17:33] <racarr> set_focus_To on the session manager
[17:33] <racarr> takes
[17:33] <racarr> a session
[17:33] <dandrader> man, I spent quite a bit trying to find you how does unity-mir distinguish apps surfaces from the unity8 one :) (looked at qtubuntu, platform-api....)
[17:33] <dandrader> s/you/out
[17:35] <racarr> mm the surface source hack
[17:38] <racarr> ok I need to think about the session thing
[17:40] <tvoss|quick_dinn> dandrader, the key codes you pasted into https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1233245
[17:40] <tvoss|quick_dinn> are weird
[17:41] <tvoss|quick_dinn> either it's 114 (down) and 115(up) or 24(up) and 25(down)
[17:44] <dandrader> tvoss|quick_dinn, you mean here? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1233245/comments/6
[17:44] <dandrader> it's code 114 there
[17:44] <dandrader> tvoss|quick_dinn, so it matches your expectations
[17:56] <kgunn> racarr: sorry, went for a run...right, hate that its stacking up...but i would say bug 1233245
[17:56] <kgunn> then bug  1233564
[17:57] <kgunn> then api/abi
[17:57] <racarr> kgunn: Ok.
[17:57] <racarr> that's fine :) I am just trying to get the picture
[17:57] <kgunn> racarr: no prob... its like a salvador dali painting that changes
[17:58] <kgunn> kdub: unable to blank made the list (of blockers)
[17:58] <kgunn> kdub: just to verify...you actually can see this at your desk on mako, on the the latest image ?
[17:58] <kdub> kgunn, lets sync on this
[17:58] <kdub> via hangout
[17:58] <kgunn> cool
[17:59] <racarr> kgunn: You mean unable to unblank?
[17:59] <kgunn> racarr: wrt questions to kdub...yeah unblank
[17:59] <racarr> kdub: The only times I have seen this
[18:00] <racarr> is when the display was already on
[18:00] <kgunn> kdub: https://plus.google.com/hangouts/_/eb454b829a446623ced641778cf81d1c2ed71e11?pqs=1&authuser=0&hl=en
[18:00] <racarr> when mir tried to start
[18:00] <racarr> is it possible just that
[18:00] <racarr> unblank returns an error
[18:00] <racarr> when the screen is already unblanked
[18:06] <davmor2> kgunn: this is probably already a bug but under mir whenever you select a text input point there is a random character deposited in the test field on maguro
[18:57] <kdub> alf_, still around?
[19:09] <tvoss_> kgunn, ping
[19:23] <kgunn> tvoss_: pong
[19:44] <dandrader> racarr, so, can I help you with anything regarding those input bugs that are blocking the "unity8-mir by default" story?
[20:02] <racarr> dandrader: Back from lunch...hmm well it looks like
[20:02] <racarr> fix-inputarea is ok (thanks for reviewing) I will double check it asap
[20:03] <racarr> I think I have a plan on key events now.
[20:03] <racarr> so not off the top of my head...unless I am missing an extra bug
[20:08] <dandrader> ok