| sarnold | pfew, finally done with the Mir MIR :) thanks everyone for your help to bring me up to C++11 speed quickly. :) | 01:37 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| * duflu reboots for live image testing | 03:31 | |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| tvoss_ | good morning | 05:12 |
| tvoss_ | RAOF, ping | 05:12 |
| RAOF | tvoss_: Pong. | 05:12 |
| RAOF | Good afternoon. | 05:12 |
| tvoss_ | RAOF, good morning :) how is it going? | 05:13 |
| RAOF | Pretty well. | 05:13 |
| RAOF | It's getting quite hot in my office. | 05:13 |
| RAOF | Which is nice at the moment. | 05:13 |
| RAOF | Ask again in a month or two ☺ | 05:13 |
| tvoss_ | RAOF, ;) it's becoming quite chilly here in the morning, I would rather prefer some hot weather | 05:17 |
| tvoss_ | RAOF, catching up after vacation, what is our current status on radeon? | 05:17 |
| RAOF | Working | 05:19 |
| RAOF | With some glitches on multihead, but I don't think I've rechecked that after some of the multiple-surfaces fixes landed. | 05:20 |
| tvoss_ | RAOF, ack, will try it on my netbook :) | 05:23 |
| duflu | RAOF: Frame ordering is all good. Since about Friday :D | 05:25 |
| duflu | tvoss: There is a lingering radeon corruption bug, but it's much rarer this one --> bug 1233545 | 05:29 |
| ubot5 | bug 1233545 in xserver-xorg-video-ati (Ubuntu) "XMir screen corruption on radeon chipset" [Critical,Confirmed] https://launchpad.net/bugs/1233545 | 05:29 |
| duflu | tvoss_ ^ | 05:29 |
| tvoss_ | duflu, is that "than this one"? | 05:36 |
| duflu | tvoss_: Oops. It's much rarer than the stripes bug. The remaining radeon bug is 1233545 | 05:37 |
| tvoss_ | duflu, ack | 05:37 |
| tvoss_ | duflu, RAOF do we have a theory where the corruption bug arises from? | 05:37 |
| duflu | tvoss_: No idea. AFAIK we don't have hardware that reproduces that one | 05:37 |
| tvoss_ | duflu, okay | 05:38 |
| duflu | But multi-monitor glitches/ordering is fixed. Did I mention that enough times? :) | 05:38 |
| tvoss_ | duflu, yup, you did :) what was the final fix? | 05:38 |
| tvoss_ | duflu, or better: the underlying issue? | 05:38 |
| duflu | 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:39 |
| tvoss_ | duflu, great, thanks | 05:41 |
| RAOF | Boo. The Radeon glitches haven't been magically fixed by fixing the out-of-order buffers. | 05:43 |
| duflu | RAOF: Oh, you see glitches like the remaining open bug? | 05:44 |
| RAOF | Yes. | 05:44 |
| duflu | Cool | 05:44 |
| duflu | Kind of | 05:44 |
| RAOF | Under GPU load. | 05:44 |
| RAOF | I suspect we're hitting a sort of synchronisation problem Intel magically handles for us in the kernel. | 05:45 |
| * tvoss_ wishes for some standardized tracing information exported via lttng from the gpu drivers | 05:49 | |
| tvoss_ | racarr, you around? | 06:21 |
| === chihchun_afk is now known as chihchun | ||
| racarr | tvoss_: Hey | 06:34 |
| racarr | am now | 06:34 |
| racarr | Was out at an open mic :D | 06:34 |
| racarr | what's up? | 06:34 |
| jibel | a crash easy to reproduce with Mir and latest build on mako (build #86), bug 1236705 . Could anyone have a look? | 06:41 |
| ubot5 | bug 1236705 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Critical,Confirmed] https://launchpad.net/bugs/1236705 | 06:41 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === _morphis is now known as morphis | ||
| jibel | another Mir only crash easy to reproduce bug 1234152 | 08:22 |
| ubot5 | 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:22 |
| jibel | the initial crash was with calendar-app but it is easier to reproduce with music-app | 08:23 |
| duflu | greyback: I swear someone told me that touch apps were all fullscreen. Surely that's not true with the panel always visible... ? | 08:27 |
| greyback | 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:28 |
| duflu | greyback: Oh. Is that a temporary approach? | 08:29 |
| greyback | duflu: Yes. When we get resizeable surfaces we can fix it | 08:30 |
| === davmor2_ is now known as davmor2 | ||
| alan_g | duflu, hikiko: could you re-review https://code.launchpad.net/~alan-griffiths/mir/remove-endpoint-first-when-shutting-down/+merge/189376 | 10:07 |
| duflu | alan_g: Oh. I was about to log off, but seem to be blocking it | 10:09 |
| hikiko | sure alan_g | 10:09 |
| alan_g | duflu: Your life is more important than work | 10:09 |
| duflu | alan_g: Sorry about that. The proposal is more important than I have time to commit tonight... | 10:15 |
| duflu | I don't want to rush that one | 10:15 |
| alan_g | duflu: np | 10:15 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| dandrader | kdub, ping | 11:08 |
| dandrader | I'm getting http://paste.ubuntu.com/6208867/ when I try to run unity8 from an ssh terminal, after calling "stop unity8" | 11:09 |
| dandrader | any ideas? | 11:09 |
| dandrader | alf_, ^ | 11:09 |
| alf_ | dandrader: looking | 11:10 |
| dandrader | not even a "start unity8" works after that. only rebooting solves it. | 11:10 |
| alf_ | dandrader: haven't come across that before, which image/pkg versions are you? | 11:11 |
| dandrader | just flashed it around an hour ago with devel-proposed | 11:11 |
| dandrader | + those packages http://people.canonical.com/~msawicz/mir-input/ | 11:11 |
| dandrader | but I don't think those extra packages have anything to do with it. I've been suffered from it before... | 11:12 |
| dandrader | alf_, and I'm using a galaxy nexus (maguro), if that's make any difference | 11:12 |
| alf_ | dandrader: ah, probably, I only have n4 | 11:12 |
| dandrader | :( | 11:13 |
| * alan_g hates it when he has to reboot | 11:14 | |
| hikiko | alan_g, it works fine if I send the signals one by one | 11:20 |
| hikiko | now I ll check the seg fault case | 11:20 |
| alf_ | alan_g: Could we get a SIGPIPE under normal circumstances when a client disconnects abruptly? | 11:21 |
| alan_g | hikiko: you do see there's a test case that does that? | 11:21 |
| alan_g | alf_: I'm not certain | 11:22 |
| alf_ | alan_g: in any case, I don't think we should be handling SIGPIPE,SIGALRM (i.e. non-fatal signals) | 11:27 |
| hikiko | yes alan_g :) | 11:28 |
| hikiko | cool! | 11:28 |
| hikiko | let me link my bug report to your branch | 11:28 |
| alf_ | 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:29 |
| alan_g | alf_: Posix says they are "Term" signals - so I thought there was an case for handling them | 11:30 |
| alan_g | But I'll reduce the set. We can add more easily later | 11:31 |
| alan_g | Gotta go now | 11:31 |
| === alan_g is now known as alan_g|lunch | ||
| === hikiko is now known as hikiko|lunch | ||
| dandrader | alf_, FYI stopping powerd solved my problems with unity8 not initializing | 11:51 |
| alf_ | dandrader: thanks | 11:52 |
| dandrader | dang it! now the problem is back again | 11:55 |
| dandrader | celebrated too early | 11:55 |
| === dandrader is now known as dandrader|lunch | ||
| === Mirv_ is now known as Mirv | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | alf_: you happy with these? SIGQUIT, SIGABRT, SIGFPE, SIGSEGV, SIGBUS | 12:28 |
| alf_ | alan_g: yes | 12:29 |
| alan_g | alf_: updated | 12:35 |
| === hikiko|lunch is now known as hikiko | ||
| === yofel_ is now known as yofel | ||
| === dandrader|lunch is now known as dandrader | ||
| mterry | Can anyone review https://code.launchpad.net/~mterry/unity-mir/permissions/+merge/189718 today? That would be great | 13:39 |
| alf_ | greyback: In unity-mir MirSurfaceManager::sessionDestroyingSurface() is there a reason we .erase() the MirSurface before sending the surfaceDestroyed() signal? | 14:21 |
| alf_ | tsdgeos: ^^ (see question above) | 14:39 |
| tsdgeos | i'm not very much into unity-mir architecture tbh | 14:39 |
| tsdgeos | but i'll have a quick look | 14:40 |
| tsdgeos | alf_: is it causing any ptoblem? | 14:40 |
| tsdgeos | from the "i know nothing about this" | 14:41 |
| tsdgeos | it makes sense to me | 14:41 |
| tsdgeos | kill it and then say "destroyed" | 14:41 |
| tsdgeos | but otoh it's connected to something that is called destroyingSurface | 14:41 |
| tsdgeos | so maybe the expectation from whoever calls here is that you warn before the surface is gone | 14:42 |
| tsdgeos | can't really say much more than this without an extra mile of guessing :D | 14:42 |
| tsdgeos | alf_: you probably want Gerry, but he's away at Qt Dev Days, shall be back on thursday i think | 14:42 |
| alf_ | tsdgeos: thanks | 14:43 |
| === dandrader is now known as dandrader|afk | ||
| jfunk | ping om26er | 15:02 |
| om26er | jfunk, pong | 15:02 |
| kgunn | 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 |
| kgunn | b) how long does battery last/does it get hot ? | 15:03 |
| jfunk | om26er, there you have it | 15:04 |
| om26er | 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 |
| jfunk | om26er, we're checking on this bughttps://bugs.launchpad.net/mir/+bug/1235190 | 15:04 |
| ubot5 | Ubuntu bug 1235190 in mir (Ubuntu Saucy) "[mako] Unity8 on Mir got slow" [High,Confirmed] | 15:04 |
| kdub | kgunn, om26er, yes, i'd expect the battery to drain a bit faster | 15:04 |
| kgunn | om26er: so does the screen blank/go dark ? | 15:05 |
| om26er | kgunn, kdub at the same time, I am also not seeing bug 1233257 anymore | 15:05 |
| ubot5 | 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 |
| kgunn | e.g. its allowed to idel | 15:05 |
| om26er | kgunn, yes, The screen does turn off fine, automatically | 15:05 |
| kgunn | ogra_: lool ^...so holding pm policy to performance does seem ok | 15:06 |
| kgunn | tvoss: ^ | 15:06 |
| tvoss | kgunn, ack and thx for testing | 15:06 |
| lool | ogra_: ^ | 15:07 |
| ogra_ | kgunn, well, if you ignore the fact that battery life goes from 12-18h to ~5h | 15:07 |
| kgunn | ogra_: hey man...you want performance or what ? :) jk | 15:07 |
| kgunn | whats a couple of hours between friends | 15:07 |
| om26er | 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:07 |
| ogra_ | 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 |
| ogra_ | om26er, i can usually use my mako for about 12h with scren on | 15:08 |
| tvoss | ogra_, we cannot afford investing the time to dive into the memory bus/cpu performance governors present | 15:08 |
| kgunn | ogra_: more than happy to if you can convince people to give us the breathing ropom | 15:08 |
| ogra_ | om26er, after 30min with performance set and screen on i'm at 87% | 15:08 |
| tvoss | ogra_, at least right now | 15:08 |
| ogra_ | tvoss, what does cpufreq to do with it | 15:08 |
| ogra_ | tvoss, you *abuse* cpufreq to hide a problem you dont want to research | 15:09 |
| tvoss | ogra_, cpufreq to performance ensures that all subcomponents like memory bus speed, gpu speed etc. operate at full speed | 15:09 |
| tvoss | ogra_, I *want* to research it, would love to do it, but not right now | 15:09 |
| ogra_ | tvoss, right, it forces everything to full speed | 15:09 |
| ogra_ | and keeps it there (unles powerd forces it off) | 15:10 |
| ogra_ | tvoss, it also doesnt change the issue at all on maguro | 15:10 |
| ogra_ | it still persistes there | 15:10 |
| tvoss | 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:10 |
| tvoss | ogra_, the bug report talks about mako, though, iirc | 15:11 |
| ogra_ | right just dont let it off the radar please | 15:11 |
| ogra_ | tvoss, well, i was asked to force performance on all devices based on that bug | 15:11 |
| tvoss | lool, mind clarifying here? | 15:11 |
| ogra_ | (and i know for sure that this will break grouper ... performance is broken there due to android hackery) | 15:11 |
| tvoss | lool, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235190 is talking about mako only | 15:12 |
| ubot5 | Ubuntu bug 1235190 in mir (Ubuntu Saucy) "[mako] Unity8 on Mir got slow" [High,Confirmed] | 15:12 |
| ogra_ | (or probably nviodia hackery) | 15:12 |
| ogra_ | though given that Mir doesnt run at all on grouper thats surely ignorable | 15:12 |
| tvoss | ogra_, it comes down to the nvidia driver using a process-shared pthread mutex, which we cannot support via hybris | 15:13 |
| ogra_ | tvoss, yeah | 15:13 |
| ogra_ | 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:13 | |
| tvoss | ogra_, fair point, but it's not only a mir issue, everything else in the system should experience worse performance, too | 15:14 |
| tvoss | kgunn, ^, thoughts? | 15:14 |
| ogra_ | tvoss, well, surely not the cpufreq governor :) | 15:15 |
| === dandrader|afk is now known as dandrader | ||
| kgunn | tvoss: agreed... | 15:15 |
| === chihchun is now known as chihchun_afk | ||
| kdub | yes, other things would be affected too | 15:16 |
| kgunn | tvoss: altho...graphics is the one area we're ripping out the most of what was natively android and replacing | 15:16 |
| tvoss | kgunn, fair | 15:16 |
| kgunn | others might get lucky...like daft punk | 15:16 |
| tvoss | ogra_, https://code.launchpad.net/~thomas-voss/location-service/refactor-packaging/+merge/189878 | 15:17 |
| ChickenCutlass | tvoss: lool it is a mistake to force performance on cpufreq | 15:17 |
| ChickenCutlass | bad idea | 15:17 |
| tvoss | ChickenCutlass, we only do it on mako | 15:18 |
| ChickenCutlass | tvoss: bad idea | 15:18 |
| ChickenCutlass | tvoss: -1 | 15:18 |
| rsalveti | can we prove with data that it actually helps? | 15:18 |
| tvoss | ChickenCutlass, alternative proposals? | 15:18 |
| ChickenCutlass | tvoss: fix the problem | 15:18 |
| rsalveti | :-) | 15:18 |
| tvoss | ChickenCutlass, not enough time right now | 15:18 |
| ChickenCutlass | tvoss: we can not throttle the cpu at max | 15:18 |
| tvoss | ChickenCutlass, seriously: we haven't experienced the issue with sf as powerd was just hanging with sf | 15:19 |
| ChickenCutlass | tvoss: seriously do not do that | 15:19 |
| tvoss | ChickenCutlass, what else then? | 15:19 |
| ChickenCutlass | tvoss: not sure -- but can't do this | 15:19 |
| ChickenCutlass | tvoss: battery will suck | 15:19 |
| ChickenCutlass | the phone will get hot | 15:19 |
| rsalveti | and this bug is a regression right? | 15:21 |
| tvoss | ChickenCutlass, fair point, but: we need to investigate how we can selectively pull the memory bus and GPU back to full speed | 15:21 |
| rsalveti | seems it was faster before | 15:21 |
| rsalveti | pushing gpu is one thing | 15:21 |
| tvoss | rsalveti, after we enabled support for powerd actually talking to u8/mir, yes | 15:21 |
| rsalveti | pushing CPU is another thing | 15:21 |
| tvoss | rsalveti, true, but we just don't have the infrastructure available right now to selectively pull the gpu | 15:21 |
| rsalveti | right, but pushing CPU won't help much | 15:22 |
| rsalveti | will cost at *lot* | 15:22 |
| tvoss | rsalveti, it helps according to testers | 15:22 |
| kdub | it turns up the axi bus on the phone, which is why it helps | 15:22 |
| rsalveti | right, but we get a lot of side effect as well | 15:23 |
| rsalveti | anyway, -1 | 15:24 |
| ChickenCutlass | tvoss: so help me understand -- why is this not a problem with SF but with mir? | 15:25 |
| ChickenCutlass | tvoss: what does sf do that we do not | 15:25 |
| ricmm | I still dont think this has anything to do with powerd | 15:25 |
| tvoss | rsalveti, -1 is fine, but we need something a little more workable, let's say ;) | 15:25 |
| ricmm | considering 95% of the bug is people saying that opening many apps had this problem | 15:25 |
| ChickenCutlass | me eother | 15:25 |
| ChickenCutlass | either | 15:25 |
| ricmm | or letting the phone sleep overnight | 15:26 |
| ricmm | which I did btw, last night | 15:26 |
| ricmm | and it was fine in the morning, it jiggles for 5 seconds and then its fine | 15:26 |
| tvoss | ChickenCutlass, I think we are experiencing | 15:26 |
| ricmm | I'm certainly not seeing a 2 minute lag-down | 15:26 |
| ricmm | also, that bug is about general slowness with Mir... not powerd and the resume issue people are seeing | 15:26 |
| tvoss | ricmm, you might want to cross-check with kdub, he has looked into the issue quite deeply | 15:27 |
| ricmm | kdub: ping | 15:28 |
| ricmm | rsalveti: get back on | 15:28 |
| rsalveti | ricmm: ok | 15:29 |
| kdub | well, i can see mir's demo programs going very slowly too | 15:29 |
| kdub | and when i turn the clocks up, they start running normally | 15:29 |
| ChickenCutlass | kdub: so how does sf account for the clocks? | 15:30 |
| ChickenCutlass | kdub: android does not certainly keep everything at max | 15:30 |
| kdub | ChickenCutlass, i'm sure they don't too | 15:31 |
| ChickenCutlass | kdub: this is a phone -- we can not keep it on max | 15:31 |
| kdub | but i'm don't have the details of their power architecture | 15:31 |
| rsalveti | tvoss: right, but let's just investigate a bit more | 15:32 |
| tvoss | rsalveti, sure | 15:33 |
| rsalveti | tvoss: looking at the bug, there's no easy explanation about what happened in there | 15:33 |
| tvoss | rsalveti, let's take the cpugovernor as baseline | 15:33 |
| rsalveti | still -1, sorry | 15:33 |
| rsalveti | that's a no-go | 15:33 |
| rsalveti | that's bad press as well, let's just put some more effort into it | 15:34 |
| rsalveti | and at least understand what changed | 15:34 |
| rsalveti | kdub: increasing the cpu clock will probably help on whatever case we use, that's true | 15:34 |
| rsalveti | but I don't think we want top performance all the time | 15:35 |
| kgunn | alan_g: have you already spoken with jdstrand abotu https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1236912 | 15:37 |
| ubot5 | Ubuntu bug 1236912 in mir (Ubuntu Saucy) "please use XDG_RUNTIME_DIR instead of /tmp for mir_socket" [Undecided,New] | 15:37 |
| alan_g | kgunn: About what led to it. yes | 15:38 |
| kdub | rsalveti, yes, i agree | 15:39 |
| kgunn | 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:39 |
| kdub | we're at the point where we suspect the clocks pretty strongly, but have to start diving outside of mir for solutions | 15:40 |
| kdub | so it will be slow going for me, not really knowing ubuntu touch's power architecture either | 15:40 |
| rsalveti | kdub: there's not much for power happening in there | 15:41 |
| rsalveti | we're just using the default ondemand, which is also used by android | 15:41 |
| alan_g | kgunn: what will break are scenarios where the server and the client run as different users. (E.g. the server is root) | 15:41 |
| ricmm | kdub: so which one exactly are you looking into? the general "small slowness" or the several-seconds-stall after resuming | 15:41 |
| alan_g | kgunn: see also https://bugs.launchpad.net/mir/+bug/1169075 | 15:41 |
| ubot5 | Ubuntu bug 1169075 in Mir "Mir server running as root does not accept connections from non-root clients" [Medium,Triaged] | 15:41 |
| rsalveti | kdub: if you never suspend it (disabling powerd), you should be able to stay at ondeman just fine | 15:41 |
| ricmm | 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 |
| rsalveti | yeah I think we're talking about 2 issues here | 15:42 |
| ricmm | general slowness is one issue, that you can see when scrolling the application list expanded | 15:42 |
| rsalveti | one is slowness after resuming, which we know that happens sometimes | 15:42 |
| ricmm | yes, but even then I've never seen it be 1-2 minutes of super slowness | 15:42 |
| rsalveti | the other (which the bugs is all about) is mir being slow by default, after boot | 15:42 |
| rsalveti | before suspending | 15:42 |
| ricmm | only 3-4 seconds of the greeter being choppy when coming in | 15:42 |
| tvoss | hah | 15:43 |
| alan_g | kgunn: still want me to go ahead? | 15:43 |
| om26er | ricmm, as long as you hold your finger over the screen after waking from sleep the system is slow. | 15:44 |
| rsalveti | lool: ^ guess you'll be involved at this as well, so read backlog :-) | 15:44 |
| ricmm | om26er: what? | 15:44 |
| kdub | ricmm, rsalveti i still don't know how powerd fits into the picture, and what it can and can't do | 15:45 |
| kdub | i see slowness just starting the basic mir test programs | 15:45 |
| rsalveti | it just suspends the device and resumes it back | 15:45 |
| kgunn | alan_g: still reading and thinking | 15:45 |
| ricmm | kdub: all powerd does is suspend to mem | 15:45 |
| rsalveti | if you disable it, you'll be using the default governor | 15:45 |
| ricmm | and resume from it | 15:45 |
| ogra_ | ricmm, hovering-slowness :) | 15:45 |
| rsalveti | yeah, we're not that smart on that yet | 15:45 |
| ricmm | om26er: tell me more about that | 15:45 |
| om26er | 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:45 |
| ricmm | ok now THATS a bug report | 15:46 |
| tvoss | kdub, rsalveti, ricmm | 15:46 |
| tvoss | kdub, rsalveti, ricmm according to http://androidxref.com/4.2.2_r1/xref/frameworks/native/services/surfaceflinger/DisplayHardware/PowerHAL.h | 15:46 |
| rsalveti | yeah, for the other issue | 15:46 |
| tvoss | the powerHAL is provided with a vsync enablement hint, too | 15:46 |
| kgunn | alan_g: sorry..i feel so stupid..so when does mir need to run as root ? | 15:47 |
| kdub | tvoss, i was poking around that yesterday too | 15:47 |
| tvoss | rsalveti, ricmm, kdub http://androidxref.com/4.2.2_r1/xref/frameworks/native/services/surfaceflinger/EventThread.cpp#312 | 15:47 |
| kgunn | alan_g: i see you listed 3 scenarios... | 15:47 |
| rsalveti | guys, let's try to break this bug properly | 15:47 |
| tvoss | ChickenCutlass, ^ | 15:47 |
| rsalveti | one is slow by default | 15:47 |
| kgunn | 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 |
| rsalveti | the other is slow after suspend/resuming | 15:48 |
| kgunn | alan_g: that will be the issue (which...would be a deal killer) | 15:48 |
| ChickenCutlass | tvoss: right, ok so are you saying that on suspend we need to stop sync events? | 15:48 |
| ricmm | kdub: tvoss that looks promising | 15:48 |
| ogra_ | ChickenCutlass, well, the kernel does that already | 15:49 |
| ricmm | is it possible the pipeline is missing a bunch of frame refreshes because of vsync timeouts? | 15:49 |
| ricmm | and it only stabilizes after a bit | 15:49 |
| tvoss | back in 15 | 15:49 |
| rsalveti | still for the second issue :-) | 15:49 |
| ricmm | rsalveti: yea | 15:49 |
| rsalveti | not for the original bug | 15:49 |
| ogra_ | ChickenCutlass, i think the issue is that the vsync doesnt come back in time | 15:49 |
| ChickenCutlass | right | 15:49 |
| ricmm | it might be possible, however SF deals with vsync differently | 15:49 |
| ricmm | 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 |
| ricmm | kdub: am I right on that? | 15:50 |
| ricmm | 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:50 |
| ricmm | the general slowness wont really be resolved before Thursday, but the second can | 15:51 |
| om26er | ricmm, its already reported as two bugs. both from me | 15:51 |
| kdub | ricmm, need to give a nuanced answer | 15:51 |
| kdub | we wait for vsync properly | 15:51 |
| om26er | ricmm, bug 1233257 is the second | 15:52 |
| ubot5 | 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 |
| kdub | using fencing (the kernel's sync driver) is not something we do as optimally as we can yet | 15:52 |
| ricmm | kdub: got it, can we perhaps disable vsync when we blank the screen? | 15:52 |
| ricmm | the same way we are disabling the SF signal when we do so | 15:52 |
| alan_g | kgunn: well, there are loads of possible scenarios - those were the ones I thought mattered | 15:53 |
| ricmm | the vsync on fd one, verbose | 15:53 |
| kdub | well, we can't really disable vsync itself, just the polling for the vsync signal from hal | 15:53 |
| ricmm | well yea I mean disable the fencing on vsync | 15:54 |
| ricmm | I'm not entirely sure how it works internally | 15:54 |
| kgunn | 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 |
| ricmm | but I would expect we need to do something like "disable fencing, suspend -- resume -> flush the pipeline, re-enable fencing' | 15:54 |
| alan_g | 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 |
| kdub | ricmm, we do something similar, we stop the composition and the clients when the display goes off | 15:56 |
| kdub | where did tvoss go? the power hal for qualcomm doesn't take a vsync hint | 15:57 |
| kdub | https://github.com/CyanogenMod/android_hardware_qcom_power/blob/cm-10.1/power.c | 15:57 |
| kgunn | alan_g: when are you eod'ing ?...maybe it'd help me & jamie to walk thru this on a hangout | 15:57 |
| alan_g | kgunn: 1 hr | 15:57 |
| alan_g | kgunn: I'm less familiar with the touch stack | 15:58 |
| ricmm | kdub: is everything flushed out at that time? | 15:59 |
| alan_g | kgunn: Anyway, I'll create the MP - you can decide which pain is worse | 15:59 |
| kgunn | eeek | 16:00 |
| kgunn | alan_g: https://plus.google.com/hangouts/_/5d829e0fcc19845aa040bb7b10366dec813e4d69?pqs=1&authuser=0&hl=en | 16:00 |
| kgunn | mind jumping on ^ | 16:00 |
| kdub | 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 |
| ricmm | I do | 16:01 |
| ricmm | im kinda interested in omer's mention of keeping the thumb down maintains the slowness | 16:01 |
| ogra_ | might be his thumb | 16:02 |
| ogra_ | :) | 16:02 |
| om26er | oh no, its real :) | 16:02 |
| kdub | ricmm, i would be surprised if that has to do with the clocks issue, probably something else involving input, scheduling rendering, etc | 16:04 |
| kgunn | kdub: rsalveti ricmm ChickenCutlass ogra_ sorry guys...lost track...so whats the decision about holding pm policy to "performance" short term ? | 16:19 |
| rsalveti | fixing the bug? :-) | 16:19 |
| kdub | kgunn, right, unacceptable seemed to be the general temperature | 16:19 |
| kgunn | rsalveti: ok...open wound approach.... | 16:19 |
| ogra_ | 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:19 |
| kgunn | ogra_: ack... | 16:20 |
| ogra_ | its a gross hack ... like dropping apparmor because one app doesnt start or similar | 16:20 |
| kdub | the value in trying that was to make sure it was something to do with the device fabric/clocks | 16:21 |
| kgunn | 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 |
| kgunn | dunno if its generic arm kernel stuff yet...or probably some msm specific fmwk | 16:21 |
| ogra_ | kdub, right its a valid test | 16:21 |
| ogra_ | just not a solution ... | 16:21 |
| rsalveti | kgunn: I'm afraid that might be device specific | 16:22 |
| rsalveti | if we don't have a hal, we usually don't have a generic interface in android | 16:22 |
| kgunn | rsalveti: i meant generic from an arm kernel perspective | 16:23 |
| kgunn | not android | 16:23 |
| kgunn | at least omap had one...and it was being pushed as the arm common soln at one point | 16:23 |
| kgunn | but then ...well, ti..omap...people died, lots of blood :) | 16:24 |
| rsalveti | I believe we do, but yeah, don't know what is currently happening in there | 16:24 |
| rsalveti | hard because we're still using old kernels | 16:24 |
| rsalveti | 3.4 is *very* old already | 16:24 |
| ogra_ | heh | 16:24 |
| ogra_ | and maguro has 3.0 | 16:25 |
| rsalveti | yeah | 16:25 |
| * ogra_ would call mako mederately new in that light :) | 16:25 | |
| ogra_ | *moderately | 16:25 |
| kgunn | 3.4!!! now...what shit is in there :) | 16:27 |
| kgunn | 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 |
| kgunn | going for lunch | 16:28 |
| lool | 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 |
| lool | +it | 16:48 |
| mterry | 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 |
| rsalveti | lool: yup, but again, that's not what the original bug was all about | 16:49 |
| rsalveti | lool: but it's fair to say people will investigate both bugs more before we decide to do such desperated decision | 16:49 |
| rsalveti | *desperate | 16:50 |
| lool | rsalveti: Ok good | 16:50 |
| davmor2 | 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:51 |
| mterry | alan_g, ricmm: are either of you particularly informed about unity-mir? | 16:58 |
| mterry | Specifically, the app focusing bits/ | 16:58 |
| mterry | ? | 16:58 |
| alan_g | mterry: I'm specifically uninformed about that. racarr is your man (when he awakes) | 16:58 |
| ricmm | mterry: whats up? | 16:59 |
| mterry | alan_g, OK | 16:59 |
| mterry | 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) | 16:59 |
| ricmm | that dwells in the QML application manager API | 17:00 |
| mterry | ricmm, and it looks like the only support in unity-mir for that is a "focusRequested(FavoriteApplication favoriteApplication)" signal | 17:00 |
| mterry | ricmm, right | 17:00 |
| mterry | ricmm, but that signal isn't hooked up to anything and should probably use appId instead | 17:00 |
| ricmm | that signal is deprectated | 17:00 |
| mterry | ricmm, i.e. unity-mir never actually emits that signal | 17:00 |
| mterry | ricmm, in place of? | 17:00 |
| ricmm | the right course of action would be to hide the greeter and use URL to invoke the dialer:// | 17:00 |
| mterry | ricmm, right. We want notification more than action | 17:01 |
| ricmm | whos we? the greeter? | 17:01 |
| mterry | ricmm, like, the user clicks on "accept call" or whatever and the shell should hide the greeter | 17:01 |
| mterry | ricmm, yeah greeter/shell | 17:01 |
| ricmm | theres an onFocusedApplicationIdChanged | 17:02 |
| mterry | ricmm, maybe the shell can do that, if it's managing the notifications... I'd have to look into who owns that | 17:02 |
| ricmm | 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 |
| mterry | ricmm, where does that live? | 17:02 |
| mterry | oh i see it | 17:03 |
| ricmm | yup | 17:03 |
| ricmm | mterry: so yea I would either do that, or just do it internally in the shell | 17:03 |
| ricmm | when a snap decision is accepted (call) just hide greeter | 17:04 |
| ricmm | go into some greeter-out-for-call state | 17:04 |
| ricmm | so you can lock back again after | 17:04 |
| ricmm | and so on | 17:04 |
| mterry | 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 |
| mterry | ricmm, ok, will test. thanks for helping me find that | 17:04 |
| ricmm | usa::ApplicationManagerInterface is the only mandated API | 17:05 |
| ricmm | its sometimes confusing because there might be signals in unity-mir | 17:05 |
| ricmm | that are provided by that other header | 17:05 |
| ricmm | so just look at the unity-api definitions | 17:05 |
| ricmm | unity-mir can extend it, but not the other way around... so start there | 17:05 |
| ricmm | mterry: btw right now if you have the greeter locked and you launch an app from launcher, it hides greeter and it brings the app forward | 17:06 |
| === alan_g is now known as alan_g|EOD | ||
| ricmm | follow that code path and have snap decisions do the same | 17:06 |
| alan_g|EOD | kgunn: MP = https://code.launchpad.net/~mir-team/mir/fix-1236912/+merge/189916su - good fortune! | 17:08 |
| mterry | ricmm, yeah, we handle that right, but not receiving a call case | 17:10 |
| mterry | Poke again about super-simple merge https://code.launchpad.net/~mterry/unity-mir/permissions/+merge/189718 | 17:30 |
| mterry | It stops the infographic from being updated | 17:30 |
| === csslayer_ is now known as csslayer | ||
| mterry | ricmm, hmm.. focusedApplicationIdChanged isn't a great choice if dialer is already focused | 17:47 |
| mterry | ricmm, does anything expose requests themselves? | 17:48 |
| ricmm | mterry: if its already focused then hiding should be enough, no? its just for this case after all | 17:59 |
| ricmm | combined with a notifications-tell-shell mechanism it should work | 18:00 |
| mterry | ricmm, but we don't get signal if it's already focuses | 18:00 |
| ricmm | no but you get the notification | 18:00 |
| ricmm | the qml notification lives in-shell | 18:00 |
| ricmm | it shouldnt be too complicated to connect to an acceptance action from it | 18:00 |
| mterry | ricmm, oh, but notifications don't know whether they will end up launching an app ornot | 18:00 |
| mterry | ricmm, that knowledge lives inside of the app that started it | 18:00 |
| mterry | ricmm, I might have a workaround | 18:01 |
| mterry | ricmm, I'm thinking that we should unfocus apps when the greeter is up anyway | 18:01 |
| ricmm | im pretty sure that we do, at least when the button is pressed / or powerd timeouts, we do | 18:01 |
| ricmm | grep for setFocused in Shell.qml | 18:01 |
| ricmm | yea we do, because its our mechanism to have all apps release their sensor | 18:02 |
| ricmm | they all get a signal that they will suspend and they release blocking hw resources | 18:02 |
| mterry | ricmm, yeah, but when we turn back on, we re-focus. I think we should only re-focus when the greeter is swiped | 18:05 |
| racarr | lol ugh... irssi hgangs. I just wonder why everyone is so quiet. | 18:05 |
| bschaefer | has anyone gotten this while compiling mir on arm? http://paste.ubuntu.com/6210388/ | 18:07 |
| bschaefer | which when i print out the size im getting a 0 | 18:10 |
| * bschaefer sees this comment and wonders why its turned on... | 18:11 | |
| bschaefer | #ctest does not work for android, so turn test discovery off | 18:11 |
| racarr | bschaefer: That's a prett yfantastic error ;) | 18:33 |
| racarr | I haven't seen it :( | 18:33 |
| racarr | I remember...there used to be some strange stack corruption that could happen in discover | 18:34 |
| racarr | tests sometimes | 18:34 |
| bschaefer | racarr, turns out i have to set the mir_platform aim at andoird | 18:34 |
| bschaefer | android | 18:34 |
| racarr | if you...<blank>... | 18:34 |
| racarr | oh XD | 18:34 |
| racarr | yes | 18:34 |
| bschaefer | :) | 18:34 |
| * bschaefer is use to the nice desktop version of mir | 18:34 | |
| bschaefer | racarr, im happy it wasn't a stack corruption error...that wouldn'tbe fun! | 18:35 |
| bschaefer | racarr, also, how bad would it be if i killed surface flinger then just tried to run mir on its on the phablet? | 18:36 |
| bschaefer | on its own* | 18:36 |
| * bschaefer is attempting to test if a library port works on mir/arm | 18:36 | |
| racarr | bschaefer: that should work | 18:37 |
| racarr | bschaefer: Make sure surface flinger stays down XD | 18:37 |
| racarr | mv /system/bin/surfaceflinger /system/bin/surfaceflinger.lol -.- | 18:37 |
| racarr | or I think you can 'stop' it | 18:37 |
| bschaefer | racarr, awesome, haha that sounds like a good way | 18:38 |
| kgunn | racarr: ping | 18:39 |
| racarr | kgunn: pong | 18:42 |
| kgunn | racarr: hey, i hate showing up with a new redirect every day....but....can you look at https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-saucy-amd64-ci/131/console | 18:44 |
| kgunn | racarr: it relates to alan_g's mp i asked for https://code.launchpad.net/~mir-team/mir/fix-1236912/+merge/189916 | 18:44 |
| kgunn | racarr: regarding moving the mir_socket conn | 18:44 |
| kgunn | to a running session related directory | 18:45 |
| kgunn | racarr: anyway...looks like a potentially legitimate ci test failure... | 18:46 |
| racarr | kgunn: mm | 18:46 |
| racarr | looks like this is the actual failure | 18:46 |
| racarr | Stack trace: | 18:46 |
| racarr | /tmp/buildd/mir-0.0.13/tests/unit-tests/frontend/test_published_socket_connector.cpp:229: Failure | 18:46 |
| racarr | Expected: { client->display_server.disconnect(0, &client->ignored, &client->ignored, google::protobuf::NewCallback(client.get(), &mt::TestProtobufClient::disconnect_done)); client->wait_for_disconnect_done(); } throws an exception of type std::runtime_error. Actual: it throws nothing. | 18:46 |
| racarr | ill dig and push some revision to the branch as it's at ~mir-team | 18:46 |
| kgunn | racarr: thanks...it seemed to me it might be legit since he was dorking with moving mir_socket...and this is about connections | 18:47 |
| racarr | kgunn: I'm not sure yet, it seems suspiscious though | 18:47 |
| racarr | that doesnt sound like | 18:47 |
| racarr | a test that should be racy | 18:47 |
| racarr | Uninteresting mock function call - returning directly. Function call: listening_on(@0xc1ba198 "./test_socket") | 18:48 |
| racarr | Stack trace: | 18:48 |
| racarr | suspiscious | 18:48 |
| racarr | is rather | 18:48 |
| racarr | among other things | 18:48 |
| racarr | anyway have to build it and see if I can reproduce will be a few minutes | 18:48 |
| kgunn | racarr: thankyou | 18:51 |
| racarr | at some point recently we hit some complexity of compilation where compiling mir just makes my system crawl to the point of being unusable :( | 18:54 |
| racarr | i.e. like 5 second compiz pauses | 18:54 |
| racarr | etc | 18:54 |
| racarr | kgunn: Oh good I can't reproduce it locally | 19:05 |
| racarr | otherwise it wouldn't be a challenge :p | 19:05 |
| racarr | kgunn: the only thing I can think of is something with the test socket getting left around leading to weird state, but I can't exactly work out how it would cause these errors... | 19:20 |
| racarr | also the only data is once out of 30,000 test runs I got | 19:21 |
| racarr | a failure | 19:21 |
| racarr | with removing the socket | 19:21 |
| racarr | I passed 30,000 test runs | 19:21 |
| racarr | but um. | 19:21 |
| racarr | Not sure that means much | 19:21 |
| kgunn | racarr: hmmmm.....i wonder, maybe the machine it ran on had a stale socket at /tmp/ | 19:21 |
| kgunn | racarr: so you think just review & approve and let jenkins try again ? | 19:21 |
| racarr | ok I can see the error | 19:22 |
| racarr | a lot more frequently | 19:22 |
| racarr | in valgrind | 19:22 |
| racarr | kgunn: Well the oscket is in the test directory though | 19:23 |
| kgunn | mmm, slower | 19:23 |
| racarr | so it would have to be like | 19:23 |
| racarr | some previous test leaving it around in a racy fashion | 19:23 |
| racarr | or perhaps even... | 19:23 |
| racarr | valgrind...being weird :p | 19:23 |
| kgunn | racarr: maybe that test should delete first before it runs | 19:23 |
| racarr | kgunn: That's what I tried (And we do that in some of the other tests) | 19:24 |
| racarr | but want to collect enough data to be sure that's what is going on | 19:24 |
| racarr | before just shoving stuff in | 19:24 |
| kgunn | k | 19:25 |
| racarr | kgunn: Nope. It's not juist that :) something else is going on | 19:27 |
| racarr | ill um...keep digging though now that I can eproduce it | 19:27 |
| kgunn | racarr: thanks again | 19:28 |
| === thomi_ is now known as thomi | ||
| racarr | ok this test is a little more nerfarious than it seems | 19:31 |
| racarr | it may have only been passing kind of coincidentally | 19:31 |
| racarr | lol | 19:31 |
| racarr | the test it passing now most of the time | 19:35 |
| racarr | because the server closes the pipe after the first disconnect | 19:35 |
| kgunn | nefarious isn't usually a character trait of a test...theyre supposed to be the good guys | 19:35 |
| racarr | and ytou get broken pipe exception | 19:35 |
| racarr | the problem is if the test process stalls for a long time because say you are running in valgrind :p | 19:36 |
| racarr | you send the disconnect | 19:36 |
| racarr | before the server has broken the pipe | 19:36 |
| racarr | and...it seems like there are a few things that can happen now | 19:36 |
| racarr | this | 19:39 |
| racarr | also is not a unit test | 19:39 |
| racarr | lol | 19:39 |
| kgunn | racarr: huh? this is not a unit test | 19:40 |
| racarr | kgunn: I just mean the test that is failing | 19:41 |
| racarr | shoudl be an integration test not a unit test | 19:41 |
| racarr | I am also pretty sure this branch has nothing to do with itand its been existing | 19:41 |
| racarr | and become more frequent due to some changes in frontend leading to more gmock warnings | 19:41 |
| racarr | slowing things down enough to make it come up more often | 19:41 |
| kgunn | ah | 19:42 |
| tvoss | ricmm, kdub did you guys look further into the power HAL? | 19:47 |
| kdub | tvoss, dead end | 19:49 |
| tvoss | kdub, why is that? | 19:49 |
| kdub | tvoss, https://github.com/CyanogenMod/android_hardware_qcom_power/blob/cm-10.1/power.c#L77 | 19:50 |
| kdub | hint doesn't do anything on sf either | 19:50 |
| kgunn | racarr: you mentioned alf made some amazing change that would fix a lot of bugs...but i don't see anything in MP's or landed on dev branch ?? | 19:56 |
| racarr | kgunn: https://code.launchpad.net/~robertcarr/mir/hold-surface-alive/+merge/189400 | 19:58 |
| racarr | kgunn: Itt's a unity-mir proposal he made that makes this not leak | 19:58 |
| racarr | (see comments at bottom) | 19:58 |
| racarr | there are other crashes potentially linked but am trying not to go overzealous with it XD | 20:00 |
| kgunn | robert_ancell: by your mail regarding lightdm socket creation, do you really mean to say "these changes have no effect" or do you mean to say "it'll break it" | 20:39 |
| robert_ancell | kgunn, first I was "it will change it", then I realised it wont (for the desktop case) | 20:39 |
| robert_ancell | it will change on the phone case | 20:39 |
| robert_ancell | but as alan_g said, that shouldn't matter | 20:39 |
| robert_ancell | It might break some QA tests | 20:40 |
| kgunn | robert_ancell: so you are really saying....we can land alan's change and xmir will be fine ? | 20:40 |
| robert_ancell | yes | 20:40 |
| kgunn | woohoo | 20:40 |
| kgunn | altho...we need to be nice to qa | 20:40 |
| kgunn | which i assume means they just need to check the new dir for the socket existance | 20:40 |
| robert_ancell | yeah, just a heads up for them - they might just have to change a hard-coded value to another hard-coded value | 20:40 |
| robert_ancell | yes | 20:40 |
| kgunn | robert_ancell: i thot we should also mir-devel on that one...its like a behavior change | 20:41 |
| robert_ancell | yes, agreed | 20:41 |
| robert_ancell | what is XDG_RUNTIME_DIR for root? | 20:41 |
| robert_ancell | it's not just /tmp anyway is it? | 20:41 |
| kgunn | robert_ancell: my understanding its tmp dir associated with a running session that would disappear on termination of the session | 20:42 |
| robert_ancell | kgunn, yes, for users I know that's true. I wasn't sure if root was special cased | 20:43 |
| kgunn | mmm, dunno robert_ancell , you could ask jdstrand | 20:43 |
| robert_ancell | well, the phone is not root so it wont matter in this case | 20:43 |
| robert_ancell | brb | 20:44 |
| racarr | lunnnnch | 20:45 |
| robert_ancell | brought to you by the letter n | 20:47 |
| kgunn | robert_ancell: so racarr is still looking to see if there's a legit concern around the ci test failure...he believes there's an issue there, but its likely with the test, nothing to do with this branch | 21:05 |
| kgunn | i'd like to get it merged so we can update trunk | 21:05 |
| kgunn | robert_ancell: oh crap...forgot the first sentence | 21:06 |
| robert_ancell | kgunn, this is alans branch? | 21:06 |
| kgunn | would you mind reviewing https://code.launchpad.net/~mir-team/mir/fix-1236912/+merge/189916 | 21:06 |
| kgunn | yeah...sorry :) super out of order | 21:06 |
| robert_ancell | kgunn, already done it | 21:06 |
| kgunn | ta...mind reader :) | 21:06 |
| robert_ancell | kgunn, did racarr trigger a rebuild? | 21:09 |
| kgunn | i just did robert_ancell , i ta'd | 21:09 |
| robert_ancell | k | 21:09 |
| racarr | I didnt, I was still trying to fix it | 21:10 |
| racarr | Still kind of half lunching | 21:10 |
| racarr | the thing is the test doesn't pass in the way that was originally expected either | 21:11 |
| racarr | at least I dont think it does... | 21:11 |
| racarr | but its hard to figure out the original intention right now | 21:11 |
| racarr | might need to talk to alan in the morning | 21:12 |
| robert_ancell | kgunn, is that fix important mostly for phone or both phone and desktop (wondering if I should make the associated lightdm fix) | 21:15 |
| kgunn | robert_ancell: mainly for phone... | 21:16 |
| kgunn | robert_ancell: jamie outlined in the bug https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1236912 | 21:16 |
| ubot5 | Ubuntu bug 1236912 in apparmor-easyprof-ubuntu (Ubuntu Saucy) "please use XDG_RUNTIME_DIR instead of /tmp for mir_socket" [High,Triaged] | 21:16 |
| racarr | kgunn: Ok so I have no quick fixes so far and it seems like | 21:27 |
| racarr | there is probably something better for me to do than work on an intermittent acceptance test bug that alan can help with in the morning | 21:27 |
| kgunn | racarr: yep - agreed.... | 21:28 |
| kgunn | racarr: let's see if we can get it to pass | 21:28 |
| racarr | haha I like your email picture | 21:28 |
| racarr | kgunn: the thing is it will show up on other mps, etc.. | 21:29 |
| racarr | but it should pass. | 21:29 |
| racarr | most of the time :/ | 21:29 |
| racarr | robert_ancell: Could you take a peek at https://code.launchpad.net/~robertcarr/mir/hold-surface-alive/+merge/189400 | 21:30 |
| robert_ancell | racarr, everytime I see that URL I think of the beegees | 21:30 |
| racarr | robert_ancell: P.S. We will miss you on the crazy train. | 21:30 |
| robert_ancell | ah ah ah ah surface alive, surface alive. Surface ALIVE! | 21:30 |
| racarr | Ahahaha | 21:30 |
| racarr | this and many other hits, on "The Music of Mir - A Symphony of Google Mock" | 21:31 |
| racarr | now available at your local record store | 21:31 |
| robert_ancell | racarr, so what happens now if the surface has been destroyed (e.g. by the client quitting) and the shell tries to modify it (e.g. allow_framedropping(true)) | 21:34 |
| robert_ancell | or it is never destroyed until the shell releases it? | 21:34 |
| racarr | robert_ancell: It's never destroyed | 21:34 |
| racarr | so it's still a valid surface. | 21:34 |
| racarr | can be rendered and everything | 21:34 |
| robert_ancell | racarr, and how does the shell know it should be destroyed? | 21:35 |
| racarr | through the "shell interface" :p | 21:35 |
| racarr | at this moment I believe they are using | 21:35 |
| racarr | the SessionListener | 21:35 |
| racarr | I mean so in most cases | 21:35 |
| racarr | the shell should still hold weak_ptr | 21:35 |
| robert_ancell | This all makes sense to me to have the shell and the rendered surface and client surface all with the same lifecycle | 21:35 |
| racarr | the point is when it temporarily locks it | 21:35 |
| robert_ancell | just want to double check | 21:35 |
| racarr | well temporarily promotes it to shared_ptr | 21:36 |
| racarr | then that actually will hold the surface alive | 21:36 |
| racarr | rather than the current nonsense, where that doesn't really mean anything | 21:36 |
| racarr | but also, there are some places where the shell might want to actually hold it alive | 21:36 |
| robert_ancell | yes, agrees | 21:36 |
| racarr | like say, a client disconnects suddenly, the shell should probably still keep the surface alive | 21:36 |
| racarr | to do a little animation or whatever | 21:36 |
| robert_ancell | I'm thinking if a client quits, that doesn't mean the shell might not want to keep rendering the last frame or animate its death | 21:37 |
| racarr | Right. | 21:37 |
| racarr | kgunn: Do we still need a mir side to: https://bugs.launchpad.net/unity8/+bug/1233564 ? | 21:39 |
| ubot5 | Ubuntu bug 1233564 in Mir "Greeter is seen animating when pressing the side button to wake up" [High,Triaged] | 21:39 |
| racarr | *testing* | 21:39 |
| racarr | yes its still not working right in the latest image at least | 21:41 |
| racarr | im a little skeptical that it's fixed in unity-mir though because the error is larger | 21:41 |
| racarr | than a single frame | 21:41 |
| kgunn | racarr: hmm, don't know how important it is...or well...at least, i wonder | 21:42 |
| kgunn | will this get addressed when greeter is split out ? | 21:43 |
| racarr | probably | 21:43 |
| racarr | halfway | 21:43 |
| racarr | the problem is | 21:43 |
| racarr | the client posted frame, or compositor posted frame could be posted right before screen blank, but not actually post so then it blocks the client and compositor with the stale frames | 21:44 |
| racarr | and when we come back an old frame gets shown | 21:44 |
| racarr | if the greeter is another surface, then it doesn't matter that the client frames are out of date | 21:44 |
| racarr | because it will look fine anyway | 21:44 |
| racarr | but we still have the risk of a one old compositor frame | 21:44 |
| racarr | flashing up | 21:44 |
| racarr | tbh it doesn't seem like THE most important thing | 21:44 |
| racarr | I am thinking maybe the best thing for me to do is, build trunk of everything + hold surface alive and alfs branch | 21:46 |
| racarr | and go try and reproduce crashes | 21:46 |
| racarr | and see what we can check off | 21:46 |
| kgunn | racarr: yes | 21:57 |
| kgunn | racarr: and run AP tests if you like | 21:57 |
| kgunn | racarr: or even this one....not because its ricks, but because its a consistent crash https://bugs.launchpad.net/mir/+bug/1236946 | 21:57 |
| ubot5 | Ubuntu bug 1236946 in Mir "Karma machine scrolls under SF, but not Mir" [Undecided,New] | 21:58 |
| kgunn | robert_ancell: just curious...would you mind testing alans branch with xmir just to see | 22:08 |
| kgunn | to verify it doesn't break anything | 22:09 |
| robert_ancell | kgunn, sure | 22:09 |
| racarr | kgunn: ok sounds like a plan | 22:12 |
| racarr | halfway through the phone update dance | 22:12 |
| racarr | is there a way to stop the nexus 4 wireless | 22:26 |
| racarr | from getting to slow when the power turns off | 22:26 |
| bschaefer | racarr, hmm when I try to run mir build on the N7, all i get is: __pthread_gettid -2 | 22:27 |
| bschaefer | and then when i attempt to re-run it I get: | 22:27 |
| bschaefer | http://paste.ubuntu.com/6211379/ | 22:27 |
| bschaefer | racarr, but you seem busy, so no worries :) | 22:27 |
| racarr | bschaefer: That looks just like the old process | 22:28 |
| racarr | is stranded alive | 22:28 |
| racarr | remove socket file, make sure process is dead, etc | 22:28 |
| racarr | but I think mir on n7 is still expected to be broken | 22:28 |
| racarr | kdub: ^ | 22:28 |
| bschaefer | yeah, but i don't see a mir process running anywhere | 22:28 |
| kdub | yes, expected broken | 22:28 |
| rsalveti | kdub: did a quick check and updated bug 1231917, it crashes when gralloc.tegra3.so calls pthread_mutex_lock because the original address of that pointer is not part of the process mapped memory region o_O | 22:28 |
| ubot5 | bug 1231917 in libhybris (Ubuntu) "Mir servers crash with SIGSEGV in libhybris-common.so.1 on Nexus7" [Low,Confirmed] https://launchpad.net/bugs/1231917 | 22:28 |
| bschaefer | kdub, o i see, well thats good to know :) | 22:29 |
| bschaefer | thanks! | 22:29 |
| racarr | :( | 22:29 |
| racarr | love that hybris | 22:29 |
| rsalveti | I don't get why we got that address | 22:29 |
| kdub | in gralloc though? | 22:30 |
| kdub | i saw in hwcomposer.tegra3.so last time i checked | 22:30 |
| kdub | it was a long time ago though so something could have changed | 22:30 |
| rsalveti | kdub: how to check that? it's all the same process in theory | 22:31 |
| rsalveti | maybe it's a shared memory regioin, and that's not mapped properly | 22:31 |
| racarr | I think it uses a mutex in a shared memory region | 22:32 |
| racarr | is...a rumor I heard in the past :p | 22:32 |
| rsalveti | but I don't get how if it's all the same process | 22:32 |
| racarr | mm right who is sharing | 22:33 |
| kdub | well, it shares it when a client connects | 22:33 |
| racarr | maybe it shares with libEGL or something absurd | 22:33 |
| rsalveti | still weird | 22:33 |
| kdub | it is weird | 22:34 |
| rsalveti | kdub: any tips or idea on what I could check? | 22:34 |
| kdub | rsalveti, well, last time i tried that device, client rendering looked okay | 22:35 |
| kdub | and if i forced mir to use a fallback rendering mode, it worked | 22:35 |
| kdub | it was just bringing in the hwc that caused problems for me | 22:36 |
| rsalveti | right, let me try removing the hwcomposer | 22:37 |
| rsalveti | kdub: yeah, doesn't crash after removing the hwcomposer | 22:40 |
| kdub | yay | 22:40 |
| rsalveti | that crap is also proprietary | 22:44 |
| kdub | yep, so can't even see what they might be doing | 22:44 |
| rsalveti | but mir_demo_client_egltriangle is running fine | 22:45 |
| rsalveti | time to try with the entire session | 22:45 |
| kdub | i /suspect/ they were trying to do some fancy synchronization in the background before google added the sync fences to the native window type | 22:46 |
| rsalveti | could be | 22:46 |
| kdub | and google had a peek under the covers and said, 'well if you're going to go to this length, we'll accommodate you' | 22:46 |
| rsalveti | let me reflash first, but saw unity8 crashing here | 22:50 |
| rsalveti | :-) | 22:50 |
| racarr | Testing trunk with hold-surface-alive and unity-mir fix...*waits for phone to reboot* | 22:55 |
| racarr | haven't tested the monitor channel stuff either yet on phone so excited to see it all work | 22:55 |
| rsalveti | ricmm: who starts mir in touch? | 22:58 |
| rsalveti | ricmm: and with which user? | 22:58 |
| rsalveti | got a few perm denied here, so wondering if that runs as phablet | 22:58 |
| ricmm | rsalveti: phablet user | 22:59 |
| ricmm | what perm denied? | 22:59 |
| rsalveti | ricmm: right, nexus 7 specific | 22:59 |
| rsalveti | I can run mir_demo server/client as root just fine | 22:59 |
| rsalveti | but can't start unity8 | 22:59 |
| rsalveti | ricmm: it's all part of unity8, right? | 22:59 |
| ricmm | yea mir is unity8 | 23:00 |
| rsalveti | ricmm: should you be able to run mir_demo server/client as phablet as well? | 23:00 |
| rsalveti | that's easier to reproduce the problem | 23:00 |
| ricmm | yes it goes through the same path | 23:01 |
| ricmm | should hit the same error | 23:01 |
| rsalveti | awesome | 23:01 |
| ricmm | rsalveti: do you see the choppy greeter when resuming your nexus 4? | 23:02 |
| ricmm | cable disconnected | 23:02 |
| ricmm | sleep for ~10 sec | 23:02 |
| rsalveti | ricmm: sometimes | 23:02 |
| ricmm | can you try? | 23:03 |
| ricmm | I have a deb with the power hint stuff | 23:03 |
| racarr | woohoo its running great | 23:03 |
| ricmm | resuming while swiping your finger across the screen several times should do it | 23:03 |
| robert_ancell | kgunn, confirmed alan's branch runs fine with XMir and continues to use /tmp/mir_socket | 23:06 |
| kgunn | robert_ancell: awesome...thanks for doing that (painful as it was i know) | 23:06 |
| robert_ancell | kgunn, not painful, just tedious to compile :) | 23:06 |
| kgunn | robert_ancell: about to do the paper work....it's "dch -i" for the changlog bump right ? | 23:06 |
| robert_ancell | kgunn, yes | 23:06 |
| racarr | how am I supposed to install click packages that arent just in the dash | 23:06 |
| racarr | trying to test karma machine | 23:07 |
| kgunn | i swear i wrote it down tons of times....i keep deleting it | 23:07 |
| robert_ancell | kgunn, shouldn't the autolanding fill out the changelog? | 23:07 |
| racarr | oh wow | 23:07 |
| racarr | I searched the dash and it worked | 23:07 |
| kgunn | robert_ancell: i'm gonna say i'm a dumb monkey on that one....at least, i'm just gonna follow the process that keeps me from being yelled at | 23:08 |
| racarr | grr I have to sign on to ubuntu sso to install apps now | 23:08 |
| robert_ancell | kgunn, probably better keep doing that then :) | 23:08 |
| kgunn | racarr: i know searching dash is kinda cool that it actually works | 23:08 |
| racarr | unfortunately this accounts pane to add | 23:09 |
| racarr | my sso page isnt | 23:09 |
| * robert_ancell -> lunch | 23:09 | |
| racarr | lol got signed in now app installing is sticking around at 0 percent... | 23:14 |
| racarr | ah it goesss | 23:14 |
| racarr | hey it scrolls and it doesnt crash :) | 23:17 |
| kgunn | robert_ancell: would you do me the honors https://code.launchpad.net/~mir-team/mir/bump-deb-changelog14-mirserver6/+merge/189990 | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!