| RAOF | Why do we go through the whole CachedPtr<> rigmarole in DefaultServerConfiguration again? | 01:53 |
|---|---|---|
| * duflu_ abstains, having forgot what CachedPtr was | 02:08 | |
| === duflu_ is now known as duflu | ||
| RAOF | Oh, it's probably breaking dependency chains. | 02:15 |
| duflu | RAOF: Oh, yes, I remember those problems. Haven't had to deal with the ptr dependency cycles in a quite a while | 04:02 |
| RAOF | And also to allow different parts of the codebase to implement different parts of the DefaultServerConfiguration. | 04:03 |
| duflu | It feels a bit wrong that I have to wait for cross-compile-chroot to download stacks of libx* builddeps. I'm guessing that's probably Mesa | 06:09 |
| duflu | Wow, still going. I wonder what Mir's using that uses so many X libraries | 06:10 |
| RAOF | Mesa | 06:19 |
| RAOF | Ah! You're the reason I remember build-depending on umockdev everywhere but then failed! | 06:25 |
| duflu | Whee, gcc internal compiler error randomness | 06:29 |
| duflu | And make -j1 fixes it :) | 06:37 |
| RAOF | Bitchn' | 06:39 |
| RAOF | duflu: I thought your objection to a umockdev dependency was that it makes it more difficult for other distros? | 06:43 |
| RAOF | duflu: I don't see how that influences our day-to-day testing at all, since we won't be day-to-day testing other distros' packages? | 06:44 |
| duflu | RAOF: Yes, that's my objective argument. The subjective argument is how inconvenienced I am personally. A script sounds like an option | 06:44 |
| RAOF | A script to run on the device that'll correctly run the tests? Sure. | 06:45 |
| duflu | RAOF: Yep. I already said this in the MP. It's delayed :) | 06:45 |
| duflu | RAOF: On a related topic... https://code.launchpad.net/~vanvugt/mir/fix-1283951/+merge/207871 | 07:15 |
| === mardy_ is now known as mardy | ||
| duflu | alan_g: I've just started merging CompositingCritieria into Renderable. I hope you hadn't started.. ? | 09:22 |
| duflu | There's a lot to fix yet and the diff is 1800+ lines :( | 09:22 |
| alan_g | duflu: nope. I'll be distracted for a couple of days by the compositing issues that are behind https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1280842 | 09:23 |
| ubot5 | Ubuntu bug 1280842 in mir (Ubuntu) "[enhancement] Need a method of hiding surfaces until they are ready to draw themselves" [Medium,Opinion] | 09:23 |
| alan_g | I assume you've also checked against kdub's rework? | 09:24 |
| duflu | alan_g: ? | 09:24 |
| alan_g | The "overlay" stuff | 09:24 |
| duflu | Fark. | 09:25 |
| * duflu looks | 09:25 | |
| duflu | alan_g: OK, looks like he hasn't started on any such changes | 09:27 |
| duflu | Phew | 09:27 |
| duflu | Woo tree builds without CompositingCritieria. Now to make it *work* | 09:31 |
| duflu | Dear bzr: Bandwidth? | 09:45 |
| alan_g | Anyone know what started the "Cannot add PPA: 'ppa:chris.gagnon/mir-demo-tester'." failures? | 09:51 |
| alf | alan_g: no | 09:57 |
| alan_g | nm I'm asking on #ubuntu-ci-eng | 09:58 |
| mzanetti | alf: hi, will you take care about getting this into trunk? | 10:09 |
| mzanetti | https://code.launchpad.net/~mzanetti/mir/dont-crash-when-shooting-invalid-surface/+merge/207509 | 10:10 |
| alf | mzanetti: sure, do we want trunk or mir/devel? | 10:10 |
| alf | (it will end up in both eventually) | 10:11 |
| mzanetti | alf: well, we've manually patched this into the MWC image, so we're good there. I'd say just take the usual road into merging something to mir | 10:11 |
| alf | mzanetti: ok, so that's lp:mir/devel, thanks | 10:12 |
| duflu | alan_g: Wrapping std::atomic_bool with our own version wouldn't really hurt performance for Mir, and we could instantly silence a ton of helgrind race errors... | 10:32 |
| duflu | Just a thought | 10:32 |
| duflu | But good night | 10:33 |
| alan_g | goodnight | 10:33 |
| === alan_g_ is now known as alan_g | ||
| === davmor2_ is now known as davmor2 | ||
| alan_g | alf: I just built development_branch and found that if I start a mir server and a client, then Ctrl+Alt+Backspace I can't start another server (or switch back to X) "ERROR: /home/alan/display_server/mir4/src/platform/graphics/mesa/display_helpers.cpp(234): Throw in function int mir::graphics::mesa::helpers::DRMHelper::open_drm_device(const std::shared_ptr<mir::udev::Context>&)" - I'm sure this was working recently and can | 11:29 |
| alan_g | 't think what might have broken it. Any ideas? | 11:29 |
| alf | greyback: Hi! The 'MirSurface' symbol from unityapplicationplugin can conflict with the MirSurface symbol in libmirclient7. We have the options of 1. renaming it 2. Namespacing it (+ all other classes in unityapplicationplugin) | 11:32 |
| alf | greyback: are unityapplicationplugin symbols used outside of unity-mir? | 11:32 |
| alf | alan_g: no ideas, let me try that | 11:33 |
| greyback | alf: 2 best option. I can do it | 11:34 |
| alf | greyback: great, please take a look at https://bugs.launchpad.net/mir/+bug/1282248 and feel free to reassign it to yourself, otherwise ping me and I can try fixing unity-mir | 11:46 |
| ubot5 | Ubuntu bug 1282248 in Mir "Unity8 crashes when using latest mir/android backend with system-compositor" [High,In progress] | 11:46 |
| greyback | alf: ok | 11:46 |
| alan_g | alf: I've just discovered that it works if I don't use "--launch-client" - so I guess that the client is "inheriting" stuff it shouldn't | 11:50 |
| alf | alan_g: ok | 11:50 |
| didrocks | alf: greyback: alan_g: hey, we are seeing a higher than usual CPU usage on touch than usual. That has impacts on the test and promoting an image. | 12:36 |
| didrocks | The two processes on top, as pointed by psivaa are pulseaudio and unity-system-compositor | 12:36 |
| didrocks | kgunn opened https://launchpad.net/bugs/1279391 a while ago, do you know if this one is under work? | 12:36 |
| ubot5 | Ubuntu bug 1279391 in Mir "[nested] inclusion of u-s-c as system comp not getting system load zero as quick as before" [Undecided,New] | 12:36 |
| greyback | didrocks: hey, I don't know, but hopefully mterry can tell us, once he comes online | 12:38 |
| didrocks | ok ;) | 12:40 |
| === alan_g is now known as alan_g|lunch | ||
| === Trevinho__ is now known as Trevinho | ||
| === mhall119_ is now known as mhall119 | ||
| === alan_g_ is now known as alan_g | ||
| === dandrader is now known as dandrader|afk | ||
| alf | fginther: https://code.launchpad.net/~afrantzis/pbuilderjenkins/mir-reenable-valgrind-on-armhf/+merge/207936 | 14:10 |
| === psivaa is now known as psivaa-afk-bbl | ||
| === dandrader|afk is now known as dandrader | ||
| * alan_g finds nested mir less stable than it should be | 14:33 | |
| === alan_g is now known as alan_g|vt | ||
| greyback | mterry: hey, didrocks was reporting issue with higher than normal CPU usage on Touch. The unity-system-compositor was one source of the issue. kgunn opened d https://launchpad.net/bugs/1279391 a while ago, do you know if this one is under work? | 14:40 |
| ubot5 | Ubuntu bug 1279391 in Mir "[nested] inclusion of u-s-c as system comp not getting system load zero as quick as before" [Undecided,New] | 14:40 |
| kgunn | mterry: greyback its not really under work, one reason for that is that the render chain did get slightly longer...u-s-c on android nested doesn't have bypass | 14:47 |
| kgunn | i know the release team adjusted the settle time and this seemed to address the immediate problem | 14:48 |
| greyback | didrocks: ^^ | 14:48 |
| didrocks | yeah, that was before today :) | 14:49 |
| didrocks | (and it means that we accept the device, being idle, to take 2.5%) | 14:49 |
| didrocks | but we thought we crossed the barrier again of 2.5% | 14:49 |
| didrocks | we just have the real info now, the kernel changed its way to count "idle" | 14:49 |
| didrocks | so, nothing increased in u-s-c or pulseaudio | 14:50 |
| kgunn | didrocks: can you share a bit more ? so are you saying new kernel ...brought in new accounting method, so this was the culprit ? | 14:54 |
| kgunn | if you want to pass me off to someone feel free | 14:54 |
| didrocks | kgunn: yeah, exactly (more detail in my email in the end of day), before shutted down CPU was counting for 100% idle, now, they are just out of the global count | 14:54 |
| didrocks | so only running CPU are taking into account | 14:55 |
| didrocks | in the idle rate | 14:55 |
| didrocks | imagine why everything increased :p | 14:55 |
| alf | kgunn: didrocks: Why are we using the CPU at all at "idle" state? At least mir itself shouldn't be using any cpu while idle, unless something is feeding it events or new buffers. | 14:59 |
| didrocks | alf: I guess that's why in the end the bug I mentionned will need to be looked at | 15:00 |
| didrocks | can be unity8 as well | 15:00 |
| alf | anpok: @null-snapshot-for-session-without-surface, what do you mean by "For the use case in unity we should provide a different interface"? | 15:10 |
| anpok | alf: unity needs in a texture | 15:11 |
| anpok | to display.. and in some cases at a low resolution | 15:11 |
| anpok | and on the side stage case in full resolution | 15:11 |
| anpok | on n4 and n10 you notice the delay in display update when those screenshots are made | 15:12 |
| anpok | or uploaded? | 15:12 |
| anpok | not sure which part affects it | 15:12 |
| anpok | also of course the fact that full screen screen shots (maybe even without mip mapping?) are displayed in tiny rectangles is a bitodd | 15:14 |
| alf | anpok: it's debatable whether unity needs a texture for this particular use case, since in the proper app lifecycle apps may be killed, so we will need a lot of GPU memory (for those devices that have it dedicated) | 15:16 |
| anpok | sure | 15:18 |
| anpok | but if there is access to the texture we could render it into some unity8 image atlas containing the reduce image screenshots.. or something.. | 15:19 |
| anpok | but if the application is killed what would take_snapshot do? | 15:19 |
| anpok | or well suspended.. | 15:19 |
| anpok | i mean .. the interface could be .. that we provide access to the texture to some degree.. and in worst case just read the pixels right now? | 15:20 |
| kgunn | alf: mzanetti ... i see zanetti's 2 branches rejected, should we just propose this one ? | 15:22 |
| kgunn | https://code.launchpad.net/~mir-team/mir/dont-crash-when-shooting-invalid-surface | 15:22 |
| alf | kgunn: superseded by https://code.launchpad.net/~afrantzis/mir/null-snapshot-for-session-without-surface/+merge/207932 | 15:22 |
| mzanetti | kgunn: yeah, I talked to alf, and he'll get it landed somehow | 15:22 |
| kgunn | thanks guys | 15:22 |
| alf | anpok: it may complicated because of the GL contexts... textures live in per GL context namespace (and shared in shared contexts, of course), so we can't just create a texture and give out the id. It must be done in a context that is shared with the context unity8 is using. It's doable of course, but not straightforward as things stand. | 15:25 |
| === alan_g|vt is now known as alan_g|tea | ||
| alf | alan_g|tea: from vt(ea) to real tea! | 15:26 |
| anpok | alf: you context sharing is a endless source of fun .. or radnomness.. | 15:26 |
| anpok | s/you/yeah | 15:27 |
| === yofel_ is now known as yofel | ||
| anpok | alf: but back to the case of application being killed - take_snapshot would dig something up? (sidenote: I saw qt requesting the QImage - hence triggering the take_snapshot frequently - even when still in phone shell) | 15:29 |
| anpok | i.e. it did so when scrolling far enough downwards and then up again | 15:29 |
| alf | anpok: what I meant is that the main point of snapshots is to somehow store the pixels of apps that could be suspendend so that 1. we can show the snapshots in the app list 2. slide in the stored image to create an illusion of fluidity until the real app reloads | 15:32 |
| alf | anpok: at least that's why they were introduced, not sure if the goals have changed | 15:33 |
| === alan_g|tea is now known as alan_g | ||
| fginther | alf, can that MP with the hook changes be deployed as soon as it is ready, or do I need to wait on an mir MP to merge first? | 15:36 |
| alf | fginther: mir is ready, feel free to deploy | 15:37 |
| fginther | alf, thanks | 15:38 |
| * alan_g wonders why his test phone & tablet have flat batteries. Again. | 15:39 | |
| alf | alan_g: I find that the devices often don't really turn off when you tell them to. The only reliable way I have found to turn them off is to go into recovery(?) mode and select "Power Off" from there. | 15:43 |
| alan_g | alf: :( | 15:45 |
| === psivaa-afk-bbl is now known as psivaa | ||
| greyback | I tend to "adb shell shutdown -h now" and then unplug the USB cable. Works nearly always, except Nexus10 sometimes reboots itself for run | 15:54 |
| greyback | fun | 15:54 |
| === WebbyIT is now known as rpadovani | ||
| === seb128_ is now known as seb128 | ||
| === dandrader is now known as dandrader|lunch | ||
| mterry | racarr_, you around? | 17:31 |
| racarr_ | mterry: Oi! | 17:32 |
| racarr_ | whats up? | 17:32 |
| mterry | racarr_, hello! I wanted to pick your Mir brain | 17:32 |
| mterry | about how Mir behaves when the screen is off | 17:32 |
| mterry | racarr_, *so* | 17:32 |
| mterry | racarr_, my root problem is that testing with a split greeter shows that the greeter session doesn't start(continue?) spawning until the screen is back on | 17:33 |
| mterry | racarr_, and I've heard that Mir won't give out buffers when the screen is off | 17:33 |
| mterry | racarr_, I was wondering if that might stop Qt from running its mainloop and thus stop the greeter from coming up while the screen is off | 17:33 |
| mterry | racarr_, (because I'd like the greeter to be sitting there ready to go when the screen is turned back on) | 17:34 |
| alan_g | alf: AIUI when we build both graphics platforms both stacks create libmirplatformgraphics.so - so one gets overwritten. Am I missing something? | 17:34 |
| mterry | racarr_, alternatively, I've heard that Mir also sends lifecycle messages to force apps to sleep. I'm not sure that's going on here, because it's a whole new unity-mir greeter session, not an app | 17:34 |
| racarr_ | mterry: Hmm so mir sends the lifecycle messages but doesnt actually do the forcing them to sleep...I dont think the greeter could get forced to sleep but maybe | 17:37 |
| racarr_ | blocking on advancing the buffer is possible | 17:37 |
| racarr_ | platform-api is still mostly synchronous so we may be blocking the mainloop in ways we shouldnt. | 17:38 |
| alan_g | alf: nm just realized they're in different directories (before my script copies them to the same place) | 17:42 |
| * mterry has to run an errand, may bother you later racarr_, thanks! | 17:43 | |
| === alan_g is now known as alan_g|EOD | ||
| === dandrader|lunch is now known as dandrader | ||
| === dandrader is now known as dandrader|bbl | ||
| === dandrader|bbl is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!