[01:37] pfew, finally done with the Mir MIR :) thanks everyone for your help to bring me up to C++11 speed quickly. :) === chihchun_afk is now known as chihchun [03:31] * duflu reboots for live image testing === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:12] good morning [05:12] RAOF, ping [05:12] tvoss_: Pong. [05:12] Good afternoon. [05:13] RAOF, good morning :) how is it going? [05:13] Pretty well. [05:13] It's getting quite hot in my office. [05:13] Which is nice at the moment. [05:13] Ask again in a month or two ☺ [05:17] RAOF, ;) it's becoming quite chilly here in the morning, I would rather prefer some hot weather [05:17] RAOF, catching up after vacation, what is our current status on radeon? [05:19] Working [05:20] With some glitches on multihead, but I don't think I've rechecked that after some of the multiple-surfaces fixes landed. [05:23] RAOF, ack, will try it on my netbook :) [05:25] RAOF: Frame ordering is all good. Since about Friday :D [05:29] tvoss: There is a lingering radeon corruption bug, but it's much rarer this one --> bug 1233545 [05:29] bug 1233545 in xserver-xorg-video-ati (Ubuntu) "XMir screen corruption on radeon chipset" [Critical,Confirmed] https://launchpad.net/bugs/1233545 [05:29] tvoss_ ^ [05:36] duflu, is that "than this one"? [05:37] tvoss_: Oops. It's much rarer than the stripes bug. The remaining radeon bug is 1233545 [05:37] duflu, ack [05:37] duflu, RAOF do we have a theory where the corruption bug arises from? [05:37] tvoss_: No idea. AFAIK we don't have hardware that reproduces that one [05:38] duflu, okay [05:38] But multi-monitor glitches/ordering is fixed. Did I mention that enough times? :) [05:38] duflu, yup, you did :) what was the final fix? [05:38] duflu, or better: the underlying issue? [05:39] tvoss_: The SessionMediator was not designed to handle multi-surface sessions --> https://code.launchpad.net/~afrantzis/mir/fix-out-of-order-buffers-1216472/+merge/187841 [05:41] duflu, great, thanks [05:43] Boo. The Radeon glitches haven't been magically fixed by fixing the out-of-order buffers. [05:44] RAOF: Oh, you see glitches like the remaining open bug? [05:44] Yes. [05:44] Cool [05:44] Kind of [05:44] Under GPU load. [05:45] I suspect we're hitting a sort of synchronisation problem Intel magically handles for us in the kernel. [05:49] * tvoss_ wishes for some standardized tracing information exported via lttng from the gpu drivers [06:21] racarr, you around? === chihchun_afk is now known as chihchun [06:34] tvoss_: Hey [06:34] am now [06:34] Was out at an open mic :D [06:34] what's up? [06:41] a crash easy to reproduce with Mir and latest build on mako (build #86), bug 1236705 . Could anyone have a look? [06:41] bug 1236705 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Critical,Confirmed] https://launchpad.net/bugs/1236705 === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === _morphis is now known as morphis [08:22] another Mir only crash easy to reproduce bug 1234152 [08:22] bug 1234152 in qtdeclarative-opensource-src (Ubuntu) "qmlscene crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [High,Confirmed] https://launchpad.net/bugs/1234152 [08:23] the initial crash was with calendar-app but it is easier to reproduce with music-app [08:27] greyback: I swear someone told me that touch apps were all fullscreen. Surely that's not true with the panel always visible... ? [08:28] duflu: every app's surface is a fullscreen surface. The panel draws over the surface. To stop overlap, applications make sure not to draw where the panel is [08:29] greyback: Oh. Is that a temporary approach? [08:30] duflu: Yes. When we get resizeable surfaces we can fix it === davmor2_ is now known as davmor2 [10:07] duflu, hikiko: could you re-review https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376 [10:09] alan_g: Oh. I was about to log off, but seem to be blocking it [10:09] sure alan_g [10:09] duflu: Your life is more important than work [10:15] alan_g: Sorry about that. The proposal is more important than I have time to commit tonight... [10:15] I don't want to rush that one [10:15] duflu: np === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [11:08] kdub, ping [11:09] I'm getting http://paste.ubuntu.com/6208867/ when I try to run unity8 from an ssh terminal, after calling "stop unity8" [11:09] any ideas? [11:09] alf_, ^ [11:10] dandrader: looking [11:10] not even a "start unity8" works after that. only rebooting solves it. [11:11] dandrader: haven't come across that before, which image/pkg versions are you? [11:11] just flashed it around an hour ago with devel-proposed [11:11] + those packages http://people.canonical.com/~msawicz/mir-input/ [11:12] but I don't think those extra packages have anything to do with it. I've been suffered from it before... [11:12] alf_, and I'm using a galaxy nexus (maguro), if that's make any difference [11:12] dandrader: ah, probably, I only have n4 [11:13] :( [11:14] * alan_g hates it when he has to reboot [11:20] alan_g, it works fine if I send the signals one by one [11:20] now I ll check the seg fault case [11:21] alan_g: Could we get a SIGPIPE under normal circumstances when a client disconnects abruptly? [11:21] hikiko: you do see there's a test case that does that? [11:22] alf_: I'm not certain [11:27] alan_g: in any case, I don't think we should be handling SIGPIPE,SIGALRM (i.e. non-fatal signals) [11:28] yes alan_g :) [11:28] cool! [11:28] let me link my bug report to your branch [11:29] alan_g: I would also argue against SIGILL, since I know of at least one library (libcrypto) that uses SIGILL to check for the presence of special ARM instructions, and is used by unity8. [11:30] alf_: Posix says they are "Term" signals - so I thought there was an case for handling them [11:31] But I'll reduce the set. We can add more easily later [11:31] Gotta go now === alan_g is now known as alan_g|lunch === hikiko is now known as hikiko|lunch [11:51] alf_, FYI stopping powerd solved my problems with unity8 not initializing [11:52] dandrader: thanks [11:55] dang it! now the problem is back again [11:55] celebrated too early === dandrader is now known as dandrader|lunch === Mirv_ is now known as Mirv === alan_g|lunch is now known as alan_g [12:28] alf_: you happy with these? SIGQUIT, SIGABRT, SIGFPE, SIGSEGV, SIGBUS [12:29] alan_g: yes [12:35] alf_: updated === hikiko|lunch is now known as hikiko === yofel_ is now known as yofel === dandrader|lunch is now known as dandrader [13:39] Can anyone review https://code.launchpad.net/~mterry/unity-mir/permissions/+merge/189718 today? That would be great [14:21] greyback: In unity-mir MirSurfaceManager::sessionDestroyingSurface() is there a reason we .erase() the MirSurface before sending the surfaceDestroyed() signal? [14:39] tsdgeos: ^^ (see question above) [14:39] i'm not very much into unity-mir architecture tbh [14:40] but i'll have a quick look [14:40] alf_: is it causing any ptoblem? [14:41] from the "i know nothing about this" [14:41] it makes sense to me [14:41] kill it and then say "destroyed" [14:41] but otoh it's connected to something that is called destroyingSurface [14:42] so maybe the expectation from whoever calls here is that you warn before the surface is gone [14:42] can't really say much more than this without an extra mile of guessing :D [14:42] alf_: you probably want Gerry, but he's away at Qt Dev Days, shall be back on thursday i think [14:43] tsdgeos: thanks === dandrader is now known as dandrader|afk [15:02] ping om26er [15:02] jfunk, pong [15:03] kdub: ^ i think om26er gonna check if holding "performance" on pm policy is reasonable work around....finding out a) does system idle/screen blank if you hold perfromance? [15:03] b) how long does battery last/does it get hot ? [15:04] om26er, there you have it [15:04] kgunn, I have been using it that way for the whole day. The phone does not get hot. I do think the battery drain is a bit faster [15:04] om26er, we're checking on this bughttps://bugs.launchpad.net/mir/+bug/1235190 [15:04] Ubuntu bug 1235190 in mir (Ubuntu Saucy) "[mako] Unity8 on Mir got slow" [High,Confirmed] [15:04] kgunn, om26er, yes, i'd expect the battery to drain a bit faster [15:05] om26er: so does the screen blank/go dark ? [15:05] kgunn, kdub at the same time, I am also not seeing bug 1233257 anymore [15:05] bug 1233257 in powerd (Ubuntu Saucy) "[mako] waking from deep sleep, phone is pretty slow, takes a while to get back to normal speed" [High,Confirmed] https://launchpad.net/bugs/1233257 [15:05] e.g. its allowed to idel [15:05] kgunn, yes, The screen does turn off fine, automatically [15:06] ogra_: lool ^...so holding pm policy to performance does seem ok [15:06] tvoss: ^ [15:06] kgunn, ack and thx for testing [15:07] ogra_: ^ [15:07] kgunn, well, if you ignore the fact that battery life goes from 12-18h to ~5h [15:07] ogra_: hey man...you want performance or what ? :) jk [15:07] whats a couple of hours between friends [15:07] ogra_, I don't think it goes to ~5h because I was out of the house for more than 6 hours and the battery was in a pretty good shape by then [15:08] kgunn, i would prefer if someone could actually properly research the issue instead of plastering a patch over it that just hides the fact that it is broekn [15:08] om26er, i can usually use my mako for about 12h with scren on [15:08] ogra_, we cannot afford investing the time to dive into the memory bus/cpu performance governors present [15:08] ogra_: more than happy to if you can convince people to give us the breathing ropom [15:08] om26er, after 30min with performance set and screen on i'm at 87% [15:08] ogra_, at least right now [15:08] tvoss, what does cpufreq to do with it [15:09] tvoss, you *abuse* cpufreq to hide a problem you dont want to research [15:09] ogra_, cpufreq to performance ensures that all subcomponents like memory bus speed, gpu speed etc. operate at full speed [15:09] ogra_, I *want* to research it, would love to do it, but not right now [15:09] tvoss, right, it forces everything to full speed [15:10] and keeps it there (unles powerd forces it off) [15:10] tvoss, it also doesnt change the issue at all on maguro [15:10] it still persistes there [15:10] ogra_, right, I'm totally aware of the implications, but we just don't have the breathing room right now for researching into the clean solution [15:11] ogra_, the bug report talks about mako, though, iirc [15:11] right just dont let it off the radar please [15:11] tvoss, well, i was asked to force performance on all devices based on that bug [15:11] lool, mind clarifying here? [15:11] (and i know for sure that this will break grouper ... performance is broken there due to android hackery) [15:12] lool, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235190 is talking about mako only [15:12] Ubuntu bug 1235190 in mir (Ubuntu Saucy) "[mako] Unity8 on Mir got slow" [High,Confirmed] [15:12] (or probably nviodia hackery) [15:12] though given that Mir doesnt run at all on grouper thats surely ignorable [15:13] ogra_, it comes down to the nvidia driver using a process-shared pthread mutex, which we cannot support via hybris [15:13] tvoss, yeah [15:13] just saying that change wont fix your world ... it will only hide the issue on mako but wont help on others [15:13] * tvoss avoids thinking about the sizeof differences for glibc and bionic pthread mutexes [15:14] ogra_, fair point, but it's not only a mir issue, everything else in the system should experience worse performance, too [15:14] kgunn, ^, thoughts? [15:15] tvoss, well, surely not the cpufreq governor :) === dandrader|afk is now known as dandrader [15:15] tvoss: agreed... === chihchun is now known as chihchun_afk [15:16] yes, other things would be affected too [15:16] tvoss: altho...graphics is the one area we're ripping out the most of what was natively android and replacing [15:16] kgunn, fair [15:16] others might get lucky...like daft punk [15:17] ogra_, https://code.launchpad.net/~thomas-voss/location-service/refactor-packaging/+merge/189878 [15:17] tvoss: lool it is a mistake to force performance on cpufreq [15:17] bad idea [15:18] ChickenCutlass, we only do it on mako [15:18] tvoss: bad idea [15:18] tvoss: -1 [15:18] can we prove with data that it actually helps? [15:18] ChickenCutlass, alternative proposals? [15:18] tvoss: fix the problem [15:18] :-) [15:18] ChickenCutlass, not enough time right now [15:18] tvoss: we can not throttle the cpu at max [15:19] ChickenCutlass, seriously: we haven't experienced the issue with sf as powerd was just hanging with sf [15:19] tvoss: seriously do not do that [15:19] ChickenCutlass, what else then? [15:19] tvoss: not sure -- but can't do this [15:19] tvoss: battery will suck [15:19] the phone will get hot [15:21] and this bug is a regression right? [15:21] ChickenCutlass, fair point, but: we need to investigate how we can selectively pull the memory bus and GPU back to full speed [15:21] seems it was faster before [15:21] pushing gpu is one thing [15:21] rsalveti, after we enabled support for powerd actually talking to u8/mir, yes [15:21] pushing CPU is another thing [15:21] rsalveti, true, but we just don't have the infrastructure available right now to selectively pull the gpu [15:22] right, but pushing CPU won't help much [15:22] will cost at *lot* [15:22] rsalveti, it helps according to testers [15:22] it turns up the axi bus on the phone, which is why it helps [15:23] right, but we get a lot of side effect as well [15:24] anyway, -1 [15:25] tvoss: so help me understand -- why is this not a problem with SF but with mir? [15:25] tvoss: what does sf do that we do not [15:25] I still dont think this has anything to do with powerd [15:25] rsalveti, -1 is fine, but we need something a little more workable, let's say ;) [15:25] considering 95% of the bug is people saying that opening many apps had this problem [15:25] me eother [15:25] either [15:26] or letting the phone sleep overnight [15:26] which I did btw, last night [15:26] and it was fine in the morning, it jiggles for 5 seconds and then its fine [15:26] ChickenCutlass, I think we are experiencing [15:26] I'm certainly not seeing a 2 minute lag-down [15:26] also, that bug is about general slowness with Mir... not powerd and the resume issue people are seeing [15:27] ricmm, you might want to cross-check with kdub, he has looked into the issue quite deeply [15:28] kdub: ping [15:28] rsalveti: get back on [15:29] ricmm: ok [15:29] well, i can see mir's demo programs going very slowly too [15:29] and when i turn the clocks up, they start running normally [15:30] kdub: so how does sf account for the clocks? [15:30] kdub: android does not certainly keep everything at max [15:31] ChickenCutlass, i'm sure they don't too [15:31] kdub: this is a phone -- we can not keep it on max [15:31] but i'm don't have the details of their power architecture [15:32] tvoss: right, but let's just investigate a bit more [15:33] rsalveti, sure [15:33] tvoss: looking at the bug, there's no easy explanation about what happened in there [15:33] rsalveti, let's take the cpugovernor as baseline [15:33] still -1, sorry [15:33] that's a no-go [15:34] that's bad press as well, let's just put some more effort into it [15:34] and at least understand what changed [15:34] kdub: increasing the cpu clock will probably help on whatever case we use, that's true [15:35] but I don't think we want top performance all the time [15:37] alan_g: have you already spoken with jdstrand abotu https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1236912 [15:37] Ubuntu bug 1236912 in mir (Ubuntu Saucy) "please use XDG_RUNTIME_DIR instead of /tmp for mir_socket" [Undecided,New] [15:38] kgunn: About what led to it. yes [15:39] rsalveti, yes, i agree [15:39] alan_g: hate to put you under the gun...is this something you could quickly MP for testing ? and then we can provide mp for jdstrand to test on his side (he has to make changes as well) [15:40] we're at the point where we suspect the clocks pretty strongly, but have to start diving outside of mir for solutions [15:40] so it will be slow going for me, not really knowing ubuntu touch's power architecture either [15:41] kdub: there's not much for power happening in there [15:41] we're just using the default ondemand, which is also used by android [15:41] kgunn: what will break are scenarios where the server and the client run as different users. (E.g. the server is root) [15:41] kdub: so which one exactly are you looking into? the general "small slowness" or the several-seconds-stall after resuming [15:41] kgunn: see also https://bugs.launchpad.net/mir/+bug/1169075 [15:41] Ubuntu bug 1169075 in Mir "Mir server running as root does not accept connections from non-root clients" [Medium,Triaged] [15:41] kdub: if you never suspend it (disabling powerd), you should be able to stay at ondeman just fine [15:42] kdub: because I run the phone daily as my personal phone and I do see them both, but they are not nearly as critical as the bug mention [15:42] yeah I think we're talking about 2 issues here [15:42] general slowness is one issue, that you can see when scrolling the application list expanded [15:42] one is slowness after resuming, which we know that happens sometimes [15:42] yes, but even then I've never seen it be 1-2 minutes of super slowness [15:42] the other (which the bugs is all about) is mir being slow by default, after boot [15:42] before suspending [15:42] only 3-4 seconds of the greeter being choppy when coming in [15:43] hah [15:43] kgunn: still want me to go ahead? [15:44] ricmm, as long as you hold your finger over the screen after waking from sleep the system is slow. [15:44] lool: ^ guess you'll be involved at this as well, so read backlog :-) [15:44] om26er: what? [15:45] ricmm, rsalveti i still don't know how powerd fits into the picture, and what it can and can't do [15:45] i see slowness just starting the basic mir test programs [15:45] it just suspends the device and resumes it back [15:45] alan_g: still reading and thinking [15:45] kdub: all powerd does is suspend to mem [15:45] if you disable it, you'll be using the default governor [15:45] and resume from it [15:45] ricmm, hovering-slowness :) [15:45] yeah, we're not that smart on that yet [15:45] om26er: tell me more about that [15:45] ricmm, about the 3-4 seconds of slowness you talking about. I am saying that when you unlock the phone and keep your thumb over the screen, moving, you will see the slowness. it only gets better when you let go your thumb for a few seconds [15:46] ok now THATS a bug report [15:46] kdub, rsalveti, ricmm [15:46] kdub, rsalveti, ricmm according to http://androidxref.com/4.2.2_r1/xref/frameworks/native/services/surfaceflinger/DisplayHardware/PowerHAL.h [15:46] yeah, for the other issue [15:46] the powerHAL is provided with a vsync enablement hint, too [15:47] alan_g: sorry..i feel so stupid..so when does mir need to run as root ? [15:47] tvoss, i was poking around that yesterday too [15:47] rsalveti, ricmm, kdub http://androidxref.com/4.2.2_r1/xref/frameworks/native/services/surfaceflinger/EventThread.cpp#312 [15:47] alan_g: i see you listed 3 scenarios... [15:47] guys, let's try to break this bug properly [15:47] ChickenCutlass, ^ [15:47] one is slow by default [15:48] alan_g: i am guessing, since the greeter isn't split out yet, and we technically aren't on the mir-on-mir config [15:48] the other is slow after suspend/resuming [15:48] alan_g: that will be the issue (which...would be a deal killer) [15:48] tvoss: right, ok so are you saying that on suspend we need to stop sync events? [15:48] kdub: tvoss that looks promising [15:49] ChickenCutlass, well, the kernel does that already [15:49] is it possible the pipeline is missing a bunch of frame refreshes because of vsync timeouts? [15:49] and it only stabilizes after a bit [15:49] back in 15 [15:49] still for the second issue :-) [15:49] rsalveti: yea [15:49] not for the original bug [15:49] ChickenCutlass, i think the issue is that the vsync doesnt come back in time [15:49] right [15:49] it might be possible, however SF deals with vsync differently [15:50] it deals with it by using a signal on an fd which we have explicitly disabled as kdub implemented proper fencing at the hwc level [15:50] kdub: am I right on that? [15:50] om26er: rsalveti: omer, can you split that bug into two please? one is the general slowness, another is the slowness on resume (include the thumb on screen info) [15:51] the general slowness wont really be resolved before Thursday, but the second can [15:51] ricmm, its already reported as two bugs. both from me [15:51] ricmm, need to give a nuanced answer [15:51] we wait for vsync properly [15:52] ricmm, bug 1233257 is the second [15:52] bug 1233257 in powerd (Ubuntu Saucy) "[mako] waking from deep sleep, phone is pretty slow, takes a while to get back to normal speed" [High,Confirmed] https://launchpad.net/bugs/1233257 [15:52] using fencing (the kernel's sync driver) is not something we do as optimally as we can yet [15:52] kdub: got it, can we perhaps disable vsync when we blank the screen? [15:52] the same way we are disabling the SF signal when we do so [15:53] kgunn: well, there are loads of possible scenarios - those were the ones I thought mattered [15:53] the vsync on fd one, verbose [15:53] well, we can't really disable vsync itself, just the polling for the vsync signal from hal [15:54] well yea I mean disable the fencing on vsync [15:54] I'm not entirely sure how it works internally [15:54] alan_g: for now let's keep it to what we know (e.g. xmir & touch) - so you're actually saying xmir would break as well [15:54] but I would expect we need to do something like "disable fencing, suspend -- resume -> flush the pipeline, re-enable fencing' [15:56] kgunn: If Mir and xmir are different users and they both use the default, then making the default depend on the username breaks it [15:56] ricmm, we do something similar, we stop the composition and the clients when the display goes off [15:57] where did tvoss go? the power hal for qualcomm doesn't take a vsync hint [15:57] https://github.com/CyanogenMod/android_hardware_qcom_power/blob/cm-10.1/power.c [15:57] alan_g: when are you eod'ing ?...maybe it'd help me & jamie to walk thru this on a hangout [15:57] kgunn: 1 hr [15:58] kgunn: I'm less familiar with the touch stack [15:59] kdub: is everything flushed out at that time? [15:59] kgunn: Anyway, I'll create the MP - you can decide which pain is worse [16:00] eeek [16:00] alan_g: https://plus.google.com/hangouts/_/5d829e0fcc19845aa040bb7b10366dec813e4d69?pqs=1&authuser=0&hl=en [16:00] mind jumping on ^ [16:01] ricmm, we finish rendering, and block the clients. everything should be out of the gpu (including clients), if that's what you meant by 'flushed' [16:01] I do [16:01] im kinda interested in omer's mention of keeping the thumb down maintains the slowness [16:02] might be his thumb [16:02] :) [16:02] oh no, its real :) [16:04] ricmm, i would be surprised if that has to do with the clocks issue, probably something else involving input, scheduling rendering, etc [16:19] kdub: rsalveti ricmm ChickenCutlass ogra_ sorry guys...lost track...so whats the decision about holding pm policy to "performance" short term ? [16:19] fixing the bug? :-) [16:19] kgunn, right, unacceptable seemed to be the general temperature [16:19] rsalveti: ok...open wound approach.... [16:19] kgunn, we can do that on release day for the very last image as a very last resort ... (and even then i want a full management order to land such shit first) [16:20] ogra_: ack... [16:20] its a gross hack ... like dropping apparmor because one app doesnt start or similar [16:21] the value in trying that was to make sure it was something to do with the device fabric/clocks [16:21] kdub: rsalveti ricmm ChickenCutlass ogra_ ...does anyone in phonedations know the proper pm fmwk api for nicely setting/removing constraints on things like mem i/f clocks ? [16:21] dunno if its generic arm kernel stuff yet...or probably some msm specific fmwk [16:21] kdub, right its a valid test [16:21] just not a solution ... [16:22] kgunn: I'm afraid that might be device specific [16:22] if we don't have a hal, we usually don't have a generic interface in android [16:23] rsalveti: i meant generic from an arm kernel perspective [16:23] not android [16:23] at least omap had one...and it was being pushed as the arm common soln at one point [16:24] but then ...well, ti..omap...people died, lots of blood :) [16:24] I believe we do, but yeah, don't know what is currently happening in there [16:24] hard because we're still using old kernels [16:24] 3.4 is *very* old already [16:24] heh [16:25] and maguro has 3.0 [16:25] yeah [16:25] * ogra_ would call mako mederately new in that light :) [16:25] *moderately [16:27] 3.4!!! now...what shit is in there :) [16:28] anyway...happy to tie in there...but we sure could use some guidance here, what's the i/f to talk to that is... [16:28] going for lunch [16:48] rsalveti: so is fair to say that we're trying to fix the Mir is slow after suspend/resume by making sure Mir + kernel do the correct thing and we've abandoned the governor thing unless we're desperate? [16:48] +it [16:49] racarr, heyo. So ApplicationManager in unity-mir... it's focusRequested signal doesn't seem emitted ever? Seems like it's deprecated in favor of new-style appid launching? [16:49] lool: yup, but again, that's not what the original bug was all about [16:49] lool: but it's fair to say people will investigate both bugs more before we decide to do such desperated decision [16:50] *desperate [16:50] rsalveti: Ok good [16:51] kgunn: mir isn't updating photo user metrics it works on SF though. I'm going to write a bug up for it if I can't find one [16:58] alan_g, ricmm: are either of you particularly informed about unity-mir? [16:58] Specifically, the app focusing bits/ [16:58] ? [16:58] mterry: I'm specifically uninformed about that. racarr is your man (when he awakes) [16:59] mterry: whats up? [16:59] alan_g, OK [16:59] ricmm, I'm looking at how the shell gets notified of a focused app (which we need to do if we want to hide greeter to show dialer-app when we get a call for example) [17:00] that dwells in the QML application manager API [17:00] ricmm, and it looks like the only support in unity-mir for that is a "focusRequested(FavoriteApplication favoriteApplication)" signal [17:00] ricmm, right [17:00] ricmm, but that signal isn't hooked up to anything and should probably use appId instead [17:00] that signal is deprectated [17:00] ricmm, i.e. unity-mir never actually emits that signal [17:00] ricmm, in place of? [17:00] the right course of action would be to hide the greeter and use URL to invoke the dialer:// [17:01] ricmm, right. We want notification more than action [17:01] whos we? the greeter? [17:01] ricmm, like, the user clicks on "accept call" or whatever and the shell should hide the greeter [17:01] ricmm, yeah greeter/shell [17:02] theres an onFocusedApplicationIdChanged [17:02] ricmm, maybe the shell can do that, if it's managing the notifications... I'd have to look into who owns that [17:02] not sure if that fires internally in QML when the greeter is shown, but if it does you could listen to it and use it to hide greeter [17:02] ricmm, where does that live? [17:03] oh i see it [17:03] yup [17:03] mterry: so yea I would either do that, or just do it internally in the shell [17:04] when a snap decision is accepted (call) just hide greeter [17:04] go into some greeter-out-for-call state [17:04] so you can lock back again after [17:04] and so on [17:04] ricmm, ah, I guess that lives in unity::shell::application::ApplicationManagerInterface, so I didn't see it when I looked at unity-mir's version [17:04] ricmm, ok, will test. thanks for helping me find that [17:05] usa::ApplicationManagerInterface is the only mandated API [17:05] its sometimes confusing because there might be signals in unity-mir [17:05]