| thomi | robert_ancell: I'll email francis and see what he thinks | 00:11 |
|---|---|---|
| robert_ancell | RAOF, I think I saw you had some bzr magic that tells you if you have merged branches that can now be pruned - is that right? | 00:34 |
| RAOF | robert_ancell: Correct. | 00:38 |
| RAOF | robert_ancell: You're looking for the bzr-removable plugin. | 00:39 |
| RAOF | cd ~/.bazaar/plugins; bzr branch lp:bzr-removable removable | 00:39 |
| robert_ancell | RAOF, ta | 00:46 |
| RAOF | for I in $(bzr removable trunk) ; do rm -r $I ; done | 00:47 |
| RAOF | (Obviously in the repository) | 00:47 |
| robert_ancell | so handy | 00:49 |
| RAOF | You'll likely find that it misses a number of branches that are actually removable - it's quite conservative. So if you've got any untracked files or uncommitted changes, the branch will not be marked as removable. | 00:51 |
| RAOF | ‘bzr unremovable trunk’ will tell you why things aren't removable. | 00:51 |
| === owner is now known as Guest76879 | ||
| thomi | duflu: you around? | 01:49 |
| duflu | thomi: Maybe | 01:49 |
| thomi | duflu: any idea how I can narrow down the reason why, as of this morning, compiz is using 80% of my CPU, and Xorg the other 20%? | 01:49 |
| thomi | even when I have no windows open :( | 01:50 |
| duflu | thomi: Wow. What driver/GPU? | 01:50 |
| thomi | well, other than a terminal | 01:50 |
| thomi | duflu: it's an nvidia GF116M [GeForce GT 560M] | 01:50 |
| duflu | thomi: Yeah Nvidia's the worst for CPU usage on a good day... | 01:51 |
| thomi | it's never been this bad | 01:51 |
| thomi | I also have a bangin' CPU, so 80% is quite a lot :) | 01:51 |
| duflu | thomi: It's probably some hidden(?) window generating damage | 01:51 |
| thomi | hmmmm | 01:51 |
| duflu | thomi: Try the compiz plugin CCSM>Utility>Show Repaint | 01:52 |
| thomi | duflu: I don't see that plugin in ccsm - is there a separate package I need to install? | 01:52 |
| duflu | thomi: Yes, the compiz-plugins package | 01:52 |
| thomi | gotchya | 01:53 |
| duflu | thomi: Also, some snapshots of the compiz threads using a script I will email you... | 01:54 |
| thomi | duflu: hmm, interesting. I now have a very colorful desktop | 01:55 |
| duflu | thomi: That's showing the windows generating damage/redraws | 01:55 |
| thomi | duflu: also, it seems like when I enabled that plugin the CPU usage dropped down to 30% | 01:55 |
| duflu | thomi: Perhaps it's the root window; nautilus misbehaving? | 01:55 |
| duflu | Or the unityshell plugin | 01:56 |
| thomi | wow, there we go... | 01:56 |
| duflu | ? | 01:56 |
| thomi | epileptic fit time :-/ | 01:56 |
| thomi | back up to 80% :-/ | 01:56 |
| duflu | thomi: sudo dstack compiz # a few times | 01:57 |
| duflu | https://launchpadlibrarian.net/106890342/dstack | 01:57 |
| thomi | it seems to be repainting both monitors every frame :-/ | 01:57 |
| duflu | And then send me the output somehow. In a bug? | 01:57 |
| duflu | I'm not going to *fix* compiz but might be able to tell you what the issue is | 01:58 |
| duflu | thomi: Also try unloading the unityshell plugin. It has a history of doing such things | 01:58 |
| thomi | duflu: http://paste.ubuntu.com/6001417/ | 01:59 |
| duflu | thomi: Yep, that confirms something is triggering rendering constantly. And unityshell being slow at rendering makes that 100% CPU | 02:00 |
| duflu | thomi: But unityshell is not always the trigger. Can you try disabling it in CCSM, briefly? | 02:01 |
| thomi | sure | 02:01 |
| thomi | duflu: with unityshell disabled, CPU usage drops to 63% | 02:02 |
| duflu | thomi: Still busy tho? | 02:02 |
| duflu | thomi: OK, try killall nautilus :) | 02:03 |
| thomi | hmmm, I don't see the repaint plugin flashing me anymore | 02:03 |
| * thomi tries re-enabling unity | 02:04 | |
| thomi | hmm, seems to be better... so far | 02:05 |
| duflu | thomi: Yeah I think I've seen that before. Nautilus randomly goes nuts and since it draws the desktop, that means everything gets repainted | 02:06 |
| thomi | interestingly, this happened after a reboot as well | 02:07 |
| thomi | it's interesting to see just how often we repaint things, sometimes for no discernable reason | 02:07 |
| thomi | for example, as I type this on the RHS monitor, chromioum is busy repainting all sorts of things on the LHS monitor | 02:07 |
| duflu | thomi: Yes, we browsers will repaint constantly due to animations, somehere, on some tab | 02:09 |
| duflu | -we +web | 02:09 |
| thomi | well, it seems to be sitting at 60%, which is at least somewhat usable - thanks for your help | 02:13 |
| duflu | thomi: 60% is bad. Is the flashing at least limited to a window now? | 02:17 |
| duflu | I mean, Show Repaint no longer shows the whole screen repainting, right? | 02:19 |
| duflu | ... You have to treat the root cause, which sounds like nautilus in this case. Unfortunately using unityshell (< 8.0) and Nvidia drivers will make performance worse | 02:29 |
| * duflu vanishes to test some ISOs briefly | 02:54 | |
| duflu | thomi: I'm curious and concerned... Still 60%? Is showrepaint showing the whole screen repainting or just some windows? | 03:02 |
| thomi | duflu: hey, yeah, still %64 | 03:17 |
| thomi | but showrepaint no longer shows whole screens being redrawn | 03:17 |
| thomi | so I think we're one step better than we were | 03:17 |
| thomi | ahaaaaa | 03:19 |
| duflu | thomi: Without a browser? | 03:19 |
| thomi | duflu: one of my chromium tabs had a notification, which makes chromium fade the tab colour in and out endlessly. if I get rid of the notification, it drops down to 19% | 03:19 |
| duflu | thomi: Also, I think some hacks in unityshell means compiz will get damage events from minimized windows. Which is not ideal. | 03:20 |
| thomi | :-/ | 03:20 |
| thomi | man, I can't wait until we have mir - I'm sure then we won't see these sorts of problem.... RIGHT GUYS!?? | 03:20 |
| thomi | :P | 03:20 |
| duflu | thomi: Yeah Mir has a simpler and more sensible damage model. It also doesn't have Unity7/Nux sitting on top of it to consume yet more CPU/GPU | 03:22 |
| thomi | yup | 03:22 |
| thomi | by then hopefully we'll have better graphics driver support as well | 03:23 |
| duflu | thomi: Tho we can't "fix" browsers or make Nvidia's proprietary drivers any less CPU hungry | 03:23 |
| thomi | :-/ | 03:23 |
| duflu | By "fix" I mean stopping them from repainting when they actually need to | 03:24 |
| duflu | You could "fix" /all/ the web pages to make them more efficient for idle desktops | 03:24 |
| duflu | There can't be that many web pages | 03:24 |
| === chihchun_afk is now known as chihchun | ||
| duflu | thomi: CPU usage is really an equation with many coefficients. So we don't need to "fix" browsers or drivers if we can lower enough of the coefficients using Mir/Unity8 | 03:45 |
| thomi | sure | 03:46 |
| robert_ancell | thomi, I'm going to merge in the Ubuntu packaging into LightDM - https://code.launchpad.net/~robert-ancell/lightdm/debian-packaging/+merge/180766. Can you make the appropriate changes to CI / autolanding so it doesn't try and use the obsolete lp:~lightdm-team/lightdm/trunk-packaging? | 04:59 |
| thomi | robert_ancell: yes, but we cannot redeploy those changes until tomorrow | 05:02 |
| robert_ancell | thomi, that's fine | 05:02 |
| thomi | ok, cool | 05:03 |
| thomi | robert_ancell: while I'm in here, do you still need/want autolanding & CI for lp:~mir-team/lightdm/unity ? | 05:05 |
| robert_ancell | thomi, nope, that branch is dead | 05:05 |
| thomi | cool | 05:06 |
| robert_ancell | Mir support is in trunk now, and in the archive | 05:06 |
| robert_ancell | thomi, oh, did the raring builds get turned off for the staging PPA? | 05:06 |
| robert_ancell | they seem to still be building | 05:07 |
| thomi | robert_ancell: hmm, I could have sworn I'd landed that change, but it seems they're still configured | 05:07 |
| thomi | removing them now as well | 05:07 |
| thomi | robert_ancell: FYI: https://code.launchpad.net/~autopilot/cupstream2distro-config/lightdm-config-tweaks/+merge/180768 | 05:11 |
| robert_ancell | thomi, does the staging PPA still get lightdm built from trunk? Is that done from somewhere else? | 05:12 |
| tvoss_ | good morning | 05:13 |
| robert_ancell | tvoss_, hello | 05:13 |
| thomi | robert_ancell: no, it looks like lightdm trunk gets built into ppa:lightdm-team/daily | 05:13 |
| tvoss_ | robert_ancell, hey there :) happy new week | 05:13 |
| thomi | hi tvoss_, how's it going? | 05:13 |
| robert_ancell | thomi, ah, ok | 05:13 |
| tvoss_ | thomi, good, but my week is roughly 13 minutes old :) | 05:13 |
| thomi | robert_ancell: and in that PPA we build for precise<->saucy and everything inbetyween | 05:13 |
| tvoss_ | thomi, how are you? | 05:13 |
| thomi | tvoss_: so far so good :) | 05:14 |
| thomi | enjoying a quiet monday without all you europeans asking me for things :P | 05:14 |
| robert_ancell | thomi, cool. So I'll delete lightdm from the staging PPA and point people at the lightdm-team/daily PPA if they need to test new changes | 05:14 |
| robert_ancell | thomi, so does the config need updating for the daily PPA to change the packaging? | 05:14 |
| thomi | robert_ancell: yeah. If we want it built into two places we may be able to accomodate that, but TBH that sounds like a bad idea to me | 05:14 |
| robert_ancell | thomi, shouldn't be any need | 05:15 |
| thomi | robert_ancell: that's what I just changed | 05:15 |
| thomi | robert_ancell: diff line 17 from that MP | 05:15 |
| robert_ancell | ah, ok | 05:16 |
| robert_ancell | awesome! | 05:16 |
| thomi | although, the diff is kind of hard to read, since LP doesn't give us much context around changes :-/ | 05:16 |
| robert_ancell | yeah, that's what go me | 05:16 |
| robert_ancell | RAOF, can haz review plz? https://code.launchpad.net/~robert-ancell/unity-system-compositor/apport-pci-info/+merge/180771 | 05:31 |
| robert_ancell | stolen shamelessly from xorg packaging | 05:31 |
| * robert_ancell -> EOD | 05:32 | |
| RAOF | didrocks: Are we able to reproduce the ATI bug on the jenkins machine with the most recent mir? | 05:42 |
| didrocks | RAOF: not sure, as we stopped building it | 05:42 |
| didrocks | RAOF: do you think there is hope? | 05:42 |
| RAOF | didrocks: Well, https://bugs.launchpad.net/mir/+bug/1212516 is maybe related and might be fixed... | 05:43 |
| ubot5 | Launchpad bug 1212516 in Mir "valgrind integration-tests: [ FAILED ] BespokeDisplayServerTestFixture.*" [Undecided,In progress] | 05:43 |
| didrocks | RAOF: ok, I'll ask to have a try later today | 05:43 |
| dholbach | good morning | 07:01 |
| tvoss_ | dholbach, salut | 07:16 |
| dholbach | hi tvoss_ | 07:18 |
| Saviq | morning all | 07:24 |
| RAOF | Ah, yes. When changing XMir ABI it's important to actually update the drivers… | 07:26 |
| * duflu is still impressed every time he sees Mir smoothly and reliably use multiple monitors | 07:28 | |
| RAOF | Then prepare to be amazed by XMir smoothly and reliably using multiple monitors! | 07:28 |
| RAOF | *: FSVO ‘smoothly’ | 07:28 |
| RAOF | *: FSVO ‘reliably’ ☺ | 07:29 |
| duflu | FSVO? | 07:29 |
| RAOF | For Some Values Of. | 07:29 |
| duflu | Ah, my math terminology is rusty | 07:30 |
| dholbach | sudo apt-get install bsdgames; wtf fsvo :) | 07:31 |
| RAOF | Woot! | 07:32 |
| RAOF | Gone from no output to infinite loop after presenting the first frame! | 07:32 |
| duflu | It's /a step/ | 07:32 |
| duflu | One small step for correctness, one giant leap for fan noise | 07:33 |
| RAOF | Gah. Stupid closures in C and their stupid type-erasing void *ctx. | 07:41 |
| tvoss_ | RAOF, https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801 | 07:49 |
| tvoss_ | mzanetti, good morning :) | 07:50 |
| mzanetti | good morning tvoss_ | 07:50 |
| tvoss_ | mzanetti, hey :) so can you check if our friend the upstream merger is still alive? | 07:50 |
| mzanetti | hehe, sure | 07:50 |
| mzanetti | tvoss_: what makes you think it isn't? | 07:52 |
| tvoss_ | mzanetti, I pushed to https://code.launchpad.net/~thomas-voss/platform-api/location-service/+merge/180692 | 07:53 |
| tvoss_ | mzanetti, an hour ago, and still no vote | 07:53 |
| mzanetti | tvoss_: right. I'll check | 07:53 |
| mzanetti | tvoss_: otherwise it seems to do stuff. not sure why this one wasn't picked up | 07:53 |
| tvoss_ | mzanetti, thx :) | 07:53 |
| didrocks | tvoss_: "no vote" -> maybe he's undecided and wants to vote blank ;) | 07:54 |
| tvoss_ | didrocks, well, I always figured that our jenkins setup might evolve to become skynet, but I haven't expected it that early | 07:54 |
| mzanetti | tvoss_: oh... the build queue holds like 50 jobs :/ | 07:55 |
| tvoss_ | mzanetti, oops | 07:55 |
| mzanetti | this is not looking good. | 07:56 |
| didrocks | tvoss_: ahah ;) | 07:56 |
| alf__ | duflu: Hi! Bypass question: why do we care about transformations of non-fullscreen windows in the bypass filter? | 07:58 |
| duflu | alf__: Because no one uses the fullscreen state yet. It's not "wired up" | 07:58 |
| duflu | When it is, the certainly we'll use it | 07:59 |
| alf__ | duflu: no, I mean we are checking for orthogonality of all windows, why is that? | 07:59 |
| duflu | alf__: Because a rotated window should not get bypassed. It would lose transformation | 08:00 |
| duflu | Oh, I see | 08:00 |
| duflu | Hang on | 08:00 |
| duflu | That was to fix a bug, let me find it | 08:01 |
| duflu | alf__: It's to reliably detect overlaps. If a window overlaps a fullscreen window then the fullscreen window can't be bypassed. And I do calculate the overlap for "orthogonal" windows, but for rotated windows it's too hard/unreliable. Safer to assume if anything is rotated (not orthogonal) then some fullscreen window "might" be overlapped. | 08:02 |
| duflu | And there are test cases which will fail otherwise... | 08:03 |
| alf__ | duflu: ok, thanks | 08:04 |
| duflu | alf__: Also, I suspect in future that rotation will not be an attribute of a surface, but rather a function of an effect or animation that's in progress. If that changes then we will test for "any effects in progress" instead | 08:05 |
| duflu | alf__: I now see however that I shouldn't be caring about rotated windows that are underneath | 08:09 |
| duflu | Unless we start using Z-buffers | 08:10 |
| alf__ | duflu: I think that's ok for now (for the XMir use case) | 08:10 |
| duflu | alf__: I think it may even become preferable to be "less correct" in future to stop more edge cases from accidentally un-bypassing a fullscreen window | 08:11 |
| duflu | Although that's less important for Mir where bypass can be switched on/off between frames. It was important in Compiz where there's a 2-frame lag | 08:12 |
| duflu | alf__: Actually that's a fun multimonitor test for bypass: Run egl{plasma,triagnle} -n -f, and then a second smaller windowed client. See how the first fullscreen client speeds up when there's nothing overlapping it | 08:15 |
| alf__ | duflu: ack, will try it out | 08:15 |
| Saviq | tsdgeos, so it's not looking like racarr got anywhere on Friday? :/ | 08:17 |
| tsdgeos | i think not :_/ | 08:18 |
| tvoss_ | Saviq, is ogra_ back? | 08:18 |
| tvoss_ | ogra_, ping | 08:18 |
| Saviq | tvoss_, was he away? | 08:18 |
| tvoss_ | Saviq, ah no, that was rsalveti | 08:18 |
| Saviq | tvoss_, canonicaladmin.com says he should be back today | 08:19 |
| tvoss_ | Saviq, ah | 08:19 |
| Saviq | greyback, tsdgeos let me know what I can halp with, will try the app auth out now | 08:19 |
| ogra_ | tvoss_, yup | 08:20 |
| greyback | Saviq: thanks | 08:20 |
| tvoss_ | ogra_, hey, did something change in the lxc-android-container configuration in terms of memory limits? | 08:20 |
| ogra_ | tvoss_, nope, not that i'm aware of | 08:21 |
| ogra_ | hmm ... unless ... | 08:21 |
| ogra_ | ask the security team, they might have tightened apparmor rules | 08:21 |
| ogra_ | thats the only thing that comes to mind | 08:22 |
| tvoss_ | ogra_, for some weird reason, when Mir tries to access the framebuffer, we see ENOMEM in ptrace | 08:22 |
| tvoss_ | ogra_, thanks for the hint | 08:22 |
| ogra_ | tvoss_, oh, there were also apparmor kernel changes now that i think of it, but i dont think xnox has rebuilt the android package for them yet | 08:24 |
| ogra_ | might be that something is out of sync there | 08:24 |
| xnox | ogra_: ack. | 08:25 |
| tvoss_ | ogra_, thanks | 08:25 |
| mzanetti | tvoss_: jenkins doesn't come up again after a restart. I fear we need to live without it for the next couple of hours until some of our jenkins experts are online | 08:39 |
| tvoss_ | mzanetti, thx | 08:40 |
| didrocks | tvoss_: maybe ask gema? her team should have some people for this kind of production issue? | 08:41 |
| alan_g | hikiko: welcome back. Good break? | 08:49 |
| hikiko | hi alan_g :) yes it was nice! | 08:50 |
| alan_g | hikiko: Are you caught up yet? We landed some nested mir stuff while you were away and more is waiting for review: https://code.launchpad.net/~alan-griffiths/mir/native-platform/+merge/180618 | 08:52 |
| hikiko | let me get a look at it :) | 08:52 |
| alan_g | hikiko: Once you've done that we should plan the next steps together. | 08:55 |
| hikiko | alan_g, you merged the nested-display branch and you added the NestedGbmPlatform isn't it? | 08:59 |
| Saviq | tvoss_, oh, interesting find (re ENOMEM) | 09:00 |
| alan_g | hikiko: *Native*GbmPlatform (and NativeAndroidPlatform) | 09:01 |
| tvoss_ | Saviq, yup, that was the only thing that was hinting to an issue | 09:02 |
| hikiko | sorry that's what I meant I am pulling :) | 09:04 |
| tvoss_ | didrocks, can you give https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing a try on the ati machine | 09:19 |
| didrocks | sil2100: ^ | 09:20 |
| didrocks | tvoss_: weird that RAOF told me that latest trunk may fix it | 09:21 |
| didrocks | as it's not merged yet | 09:21 |
| sil2100 | ;/ | 09:21 |
| didrocks | so we will need a ppa + rebuild | 09:21 |
| sil2100 | ;\ | 09:21 |
| RAOF | didrocks: That's another possible fix. | 09:21 |
| didrocks | sil2100: handling that? | 09:21 |
| didrocks | sil2100: maybe take latest mir trunk + merge that | 09:22 |
| didrocks | and push to a ppa | 09:22 |
| didrocks | once built, push u-s-c there | 09:22 |
| didrocks | and we can then just test installing from the ppa? | 09:22 |
| sil2100 | Ok | 09:34 |
| duflu | Hmm, I could return to trying to figure out test case side-effects and whether they're important... | 09:49 |
| duflu | ... or I could finish early and work on preparing a healthy meal | 09:50 |
| duflu | Right then | 09:50 |
| hikiko | alan_g, when I build trunk | 09:51 |
| hikiko | I get this: | 09:51 |
| hikiko | make[2]: *** No rule to make target `/usr/lib/libboost_chrono.so', needed by `lib/libmirclient.so.1'. Stop. | 09:51 |
| hikiko | although I have libboost-chrono-dev installed | 09:51 |
| alan_g | hikiko: your cmake cache is out of date with saucy | 09:52 |
| alan_g | delete it and run cmake again | 09:52 |
| hikiko | but I just did bzr branch lp:mir :s | 09:52 |
| hikiko | ok | 09:52 |
| hikiko | I will try | 09:52 |
| alan_g | hikiko: that's odd then | 09:53 |
| alan_g | hikiko: are you using any ppas? | 09:54 |
| Saviq | greyback, oh, tricky... webbrowser creates a separate surface it seems | 09:54 |
| Saviq | greyback, and it gets rejected | 09:55 |
| greyback | Saviq: quite likely, as the webprocess separate. Good catch...wonder how to work-around | 09:55 |
| Saviq | greyback, indeed | 09:55 |
| hikiko | alan_g, mir-team/staging/ubuntu and http://ppa.launchpad.net/phablet-team/ppa/ubuntu | 09:56 |
| Saviq | greyback, it feels like unity8 starts faster with Mir, are you seeing the same? | 09:57 |
| greyback | Saviq: hud is disabled :) | 09:57 |
| Saviq | lol | 09:57 |
| greyback | must re-enable it | 09:57 |
| hikiko | alan_g, I am dist-upgrading maybe that will solve the problem, I didn't upgrade for 10 days or more | 09:57 |
| Saviq | greyback, desktop hint → happroved | 09:57 |
| greyback | Saviq: thanks. | 09:58 |
| alan_g | hikiko: you shouldn't need the ppas as everything ought to be in the distro | 09:58 |
| hikiko | ok, I ll remove them and try again, thanks! | 09:59 |
| hikiko | alan_g, the branch looks good but shouldn't we call the NativeGbmPlatform NativeGBMPlatform to match the GBMPlatform? could I rename it? | 10:21 |
| alan_g | hikiko: we should, but as alf__ top-approved without that tweak we can do it in a future MP (it only affects a couple of lines in a .cpp we need to change anyway) | 10:22 |
| alan_g | hikiko: you building OK now? | 10:26 |
| hikiko | yes alan_g | 10:27 |
| hikiko | after upgrading everything is fine | 10:27 |
| === hikiko is now known as hikiko|lunch | ||
| === tvoss_ is now known as tvoss|lunch | ||
| Saviq | tsdgeos, hey, I might take over QDesktopServices::openUrl from you, interested? | 10:49 |
| tsdgeos | Saviq: all yours, i'm doing some unit/auto/something-tests for greyback | 10:49 |
| Saviq | tsdgeos, yup, know that | 10:50 |
| Saviq | tsdgeos, any quick pointers where I should put that in (e.g. the DBus service backing it)? | 10:50 |
| tsdgeos | Saviq: tbh not sure what's needed, so we want QDesktopServices::openUrl to do what? open the appropiate app for that url? do we have such system in place? | 10:51 |
| Saviq | tsdgeos, a preliminary one, yes | 10:52 |
| tsdgeos | and that's going to call ApplicationManager::startProcess or something unrelated to start the app? | 10:52 |
| Saviq | tsdgeos, https://launchpad.net/url-dispatcher | 10:52 |
| Saviq | tsdgeos, upstart | 10:53 |
| tsdgeos | Saviq: ok, why not ApplicationManager::startProcess? it needs to have upstart support afaics from the comments | 10:53 |
| tsdgeos | may as well have the upstart code only once? | 10:53 |
| Saviq | tsdgeos, yeah, it seems url-dispatcher is a self-contained thing now | 10:53 |
| Saviq | tsdgeos, will talk to tedg on that later | 10:54 |
| tsdgeos | Saviq: i would understand that it should go in unity-mir, probably | 10:56 |
| Saviq | tsdgeos, yeah, that's for sure | 10:56 |
| tsdgeos | not sure which class exactly | 10:56 |
| tsdgeos | i don't think ApplicationManager is a bad place | 10:57 |
| tsdgeos | but gerry may disagree | 10:57 |
| Saviq | tsdgeos, we agreed on that before already | 10:57 |
| greyback_ | fine with me | 10:57 |
| tsdgeos | ah, did we? | 10:57 |
| tsdgeos | :D | 10:57 |
| * tsdgeos can't read lately | 10:57 | |
| * greyback_ rebooting as Mir seems to freeze his machine | 10:58 | |
| greyback_ | alan_g: ping | 10:59 |
| alan_g | greyback_: hello | 10:59 |
| greyback_ | alan_g: hey there, I need some advice from you | 10:59 |
| greyback_ | alan_g: I am trying a simple unity-mir server on my desktop. Something is not happy, as when running it, my machine's graphics completely hangs. I can ssh in, but could you give me tips on how to debug? | 11:00 |
| mlankhorst | does ssh work? | 11:01 |
| greyback_ | mlankhorst: yes | 11:01 |
| greyback_ | I suppose catching output into a file is necessary for a start | 11:02 |
| greyback_ | alan_g: also, if using XMir, would my Mir instance with XMir collide? (I've disabled xmir) | 11:02 |
| alan_g | greyback_: I usually try running from an ssh session so that I can see errors. (and maybe turning on some logging) | 11:02 |
| alan_g | greyback_: yes, we don't have nested mir sessions working yet | 11:03 |
| greyback_ | alan_g: ack | 11:03 |
| greyback_ | alan_g: any way to confirm xmir not running? | 11:04 |
| alan_g | greyback_: I'm the wrong one to ask (I have never enabled it) | 11:05 |
| greyback_ | alan_g: ok, thanks | 11:05 |
| === greyback_ is now known as greyback|unstabl | ||
| alan_g | greyback_: I'd guess there's be a u-s-c process running (but I don't actually know) | 11:06 |
| Saviq | greyback|unstabl, lp:platform-api/mir is merged into lp:platform-api already? | 11:06 |
| greyback|unstabl | Saviq: yes | 11:08 |
| Saviq | greyback|unstabl, good, thanks | 11:08 |
| greyback|unstabl | Saviq: same with qtubuntu | 11:08 |
| greyback|unstabl | alan_g: ever got this exception: "Failed to mute keyboard" when launching over ssh? Would it be that I'm sshing into my primary machine (that I'm typing this on) | 11:10 |
| alan_g | greyback|unstabl: yeah, sounds like X owns the keyboard. You need to be in a VT (and tell your server which one with --vt) | 11:12 |
| greyback|unstabl | alan_g: aha, --vt! Thanks | 11:12 |
| alan_g | greyback|unstabl: ./mir_demo_server --help is wonderful | 11:13 |
| tsdgeos | greyback|unstabl: how do i "stop" a QMirServer? | 11:18 |
| tsdgeos | it seems that returning from the function i pass to runWithClient is not enough | 11:18 |
| === hikiko|lunch is now known as hikiko | ||
| === alan_g is now known as alan_g|lunch | ||
| kgunn | alf__: hey...nice job on mm... | 12:49 |
| alf__ | kgunn: thanks, did you try it out? | 12:53 |
| kgunn | alf__: not yet....was just looking at what landed while i was out.... | 12:54 |
| kgunn | alf__: and what new problems we have :) | 12:54 |
| === kode54_ is now known as kode54 | ||
| === alan_g|lunch is now known as alan_g | ||
| kgunn | tvoss|lunch: so are we able to pilot https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801 on didrocks machine? (sorry if this is old news) | 13:52 |
| tvoss|lunch | kgunn, I think sil2100 did | 13:54 |
| === tvoss|lunch is now known as tvoss_ | ||
| kgunn | sil2100: how many successful runs? i only ask because this is a heisenbug....i know didrocks got 10 in a row once | 13:55 |
| kgunn | with the "current failing config" | 13:55 |
| tvoss_ | didrocks, got an update on https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801 | 14:02 |
| didrocks | tvoss_: as you told, sil2100 is on it | 14:03 |
| didrocks | I didn't got any update since, he had some issue with his ppa, then I think he copied to another one but didn't get feedback | 14:03 |
| didrocks | let's wait for him :) | 14:03 |
| sil2100 | didrocks: running the tests, but so far no failures - but no many tests have passed yet | 14:09 |
| didrocks | if 2 tests pass, we're fine TBH | 14:10 |
| didrocks | sil2100: you will rerun it then? | 14:10 |
| didrocks | (hum, aren't we at next tick though?) | 14:10 |
| didrocks | still 30 minutes until the first stack starts I guess | 14:10 |
| sil2100 | I know ;p | 14:10 |
| sil2100 | uuuu | 14:11 |
| sil2100 | didrocks: hmmm | 14:12 |
| sil2100 | didrocks: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console | 14:12 |
| sil2100 | didrocks: looks to me like 'it' ;/ | 14:12 |
| sil2100 | didrocks: since it seems that it stopped on the opengl | 14:12 |
| sil2100 | kgunn: ^ | 14:12 |
| didrocks | right | 14:13 |
| didrocks | tvoss_: ^ | 14:13 |
| didrocks | sil2100: we'll need to free it for production in some minutes (reboot electrically directly the machines to avoid having next test failing) | 14:13 |
| didrocks | sil2100: let's wait a little bit to see if kgunn/tvoss have a chance to get to it | 14:14 |
| sil2100 | Ok | 14:15 |
| sil2100 | tvoss_: ? | 14:24 |
| sil2100 | didrocks: I guess we might have to reset the machine? | 14:24 |
| kgunn | sil2100: didrocks ...can we get another opportunity to build in the patch | 14:24 |
| didrocks | sil2100: agreed | 14:24 |
| kgunn | from RAOF http://paste.ubuntu.com/5983202/ | 14:24 |
| kgunn | understanding this might be a while | 14:25 |
| didrocks | kgunn: IIRC, this one was already tried | 14:25 |
| didrocks | kgunn: without any success | 14:25 |
| kgunn | didrocks: its not a solution... | 14:25 |
| kgunn | its debug | 14:25 |
| didrocks | yeah, we tried it | 14:25 |
| didrocks | and couldn't get any blocking situation | 14:25 |
| didrocks | (after 20 runs) | 14:25 |
| didrocks | damn heisenberg… :p | 14:26 |
| kgunn | didrocks: oh...the debug patch changes timing... | 14:26 |
| kgunn | ug | 14:26 |
| didrocks | right :/ | 14:26 |
| kgunn | didrocks: sil2100 ...can you at least grab the logs off it before rebooting | 14:27 |
| didrocks | sil2100: mind doing that? see the logs I attached to the bug and paste the same | 14:28 |
| didrocks | sil2100: just log into the container and installs pastebinit | 14:28 |
| didrocks | it's the easiest | 14:28 |
| didrocks | sil2100: can help you if needed (but in meetings) | 14:28 |
| sil2100 | Doing ;) | 14:29 |
| sil2100 | Looking at the bug first | 14:29 |
| sil2100 | kgunn, tvoss_: attached the logs to the bug as a comment | 14:35 |
| kgunn | sil2100: thank alot | 14:35 |
| sil2100 | didrocks: would it be enough if I just restart the machine through ssh? | 14:36 |
| tvoss_ | sil2100, thx | 14:36 |
| didrocks | sil2100: yeah | 14:37 |
| sil2100 | didrocks: do I have to detach the lxc containers first or nothing needed ;p ? | 14:37 |
| didrocks | sil2100: no no, it's fine | 14:37 |
| didrocks | sil2100: just reboot outside the container though :p | 14:38 |
| didrocks | or you just shut down the container then :p | 14:38 |
| sil2100 | Rebooting normally then, thanks ;) I prefer to double-ask with fragile things | 14:38 |
| tvoss_ | sil2100, does not look like anything failed judging from the logs | 14:40 |
| sil2100 | tvoss_: didn't paste in compiz logs, but it's the same as before - it's stopping on loading the opengl plugin | 14:41 |
| tvoss_ | sil2100, ah, what was the error message again? | 14:42 |
| sil2100 | tvoss_: no error message really, just this from compiz, as seen in this comment: https://bugs.launchpad.net/mir/+bug/1204939/comments/11 | 14:44 |
| ubot5 | Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged] | 14:44 |
| kgunn | Saviq: confirmed with alan_g ....current mir worked on old image....so, makes me wonder if we updated android trees or move kernel | 14:45 |
| kgunn | more so than i did | 14:45 |
| Saviq | kgunn, right | 14:45 |
| kgunn | Saviq: even better...alan_g says old mir fails on new image | 14:46 |
| Saviq | ricmm, hey, wanted to ask, where should put the platform api part of QDesktopServices::openUrl()? | 14:46 |
| ricmm | Saviq: I need more context | 14:47 |
| Saviq | ricmm, it'll effectively be just a DBus call to AppManager | 14:47 |
| tvoss_ | sil2100, so it segfaults? | 14:47 |
| Saviq | ricmm, that will ask it to open the url provided | 14:47 |
| alan_g | kgunn: Saviq - alf__ tried an old mir on the new image | 14:47 |
| === alan_g is now known as alan_g|tea | ||
| sil2100 | tvoss_: hm, hard to say this time, I would assume yes but it says nothing in the logs: jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console | 14:48 |
| sil2100 | tvoss_: scroll down to the bottom and try finding compiz init phase | 14:48 |
| tvoss_ | sil2100, I get an error accessing https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console | 14:49 |
| sil2100 | hm, then maybe http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console <- with VPN access | 14:49 |
| === alan_g|tea is now known as alan_g | ||
| racarr_ | Morning | 15:11 |
| alan_g | afternoon | 15:20 |
| === dholbach_ is now known as dholbach | ||
| === sfeole` is now known as sfeole | ||
| kgunn | racarr_: ping | 16:17 |
| kgunn | so wrt "mir doesn't work on n4"...the current belief is that its a um/km out of sync issue.... | 16:19 |
| kgunn | looks like at ~1:30 today there will be a 19.2 image available (where all will be resync'd) | 16:19 |
| kgunn | racarr_: so basically....save beating your head on the n4 mir thing until then....& | 16:20 |
| kgunn | hopefully it will just be corrected by the image creation...can you test that this afternoon ?? | 16:20 |
| racarr_ | kgunn: um/km? | 16:20 |
| racarr_ | I definitely can! and that's | 16:20 |
| kgunn | user mode/kernel mode | 16:20 |
| racarr_ | good to hear | 16:20 |
| racarr_ | oh ok | 16:20 |
| racarr_ | yes that | 16:20 |
| racarr_ | seems really feasible | 16:20 |
| racarr_ | it was getting absurd on friday when I was trying to figure it out :p | 16:21 |
| kgunn | racarr_: yeah...sounds like it was android um as well as ubuntu um code that was outta whack | 16:21 |
| kgunn | at least ogra seems to be strongly thinking the same | 16:21 |
| ogra_ | err, not exactly :) | 16:22 |
| ogra_ | apparmor userspace and kernel got updated ... but the kernel didnt make it into the images yet, so something *could* be out of sync | 16:22 |
| * ogra_ never said "strongly" ... it was just the best guess i could make on the situation you guys hit | 16:23 | |
| racarr_ | ogra_: It might not be possible for it to be that...I think I tried | 16:24 |
| racarr_ | to unload apparmor | 16:24 |
| racarr_ | but im not confident I did it correctly so or the mismatch could have made that | 16:24 |
| racarr_ | incorrect | 16:24 |
| racarr_ | so I will test the image | 16:24 |
| === racarr_ is now known as racarr | ||
| ogra_ | with luck the fix made it into 19.1 | 16:24 |
| ogra_ | it will definitely make 19.2 though | 16:24 |
| ogra_ | (which starts building at 20:00 UTC ... so should be available in a few hours) | 16:25 |
| ogra_ | racarr, to do it right you need to disable apparmor on the kernel cmdline | 16:25 |
| ogra_ | (apparmor=0 iirc) | 16:26 |
| racarr | ogra_: Ah ok | 16:26 |
| racarr | It sounds pretty feasible | 16:26 |
| racarr | :) | 16:26 |
| kgunn | ogra_: "updated kernel"....so besides apparmor...there are other updates to the kernel ? | 16:31 |
| ogra_ | kgunn, https://launchpad.net/ubuntu/saucy/+source/linux-mako/3.4.0-3.20 | 16:32 |
| ogra_ | and as i said above ... i was only guessing, not sure it is actually your issue | 16:35 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | kgunn, racarr: http://paste.ubuntu.com/6003505/ these are two scripts that help with manipulating the kernel cmdline on touch images | 16:51 |
| ogra_ | so just try appending the apparmor=0 and see if it helps | 16:52 |
| robotfuel | it looks like 3d acceleration broke on nouveau starting on friday, for regular x as well. | 17:04 |
| === alan_g is now known as alan_g|EOD | ||
| racarr | finally have time to do powermangement | 17:24 |
| racarr | it seems maybe dpms_mode is a member of | 17:24 |
| racarr | MirDisplayOutput | 17:24 |
| racarr | ? | 17:24 |
| tvoss | racarr, ping | 18:11 |
| === alex_abreu is now known as alex-abreu | ||
| racarr | tvoss: pong | 18:55 |
| racarr | Was lunching :) | 18:55 |
| tvoss | racarr, cool, just wanted to say that I'm around to help out with the nexus 4 issue | 18:56 |
| racarr | tvoss: The rumor is that it could be a kernel space userspace mismatch for apparmor | 18:57 |
| racarr | so waiting on new images to build | 18:57 |
| racarr | where the rumor was they would build around 1:30 today | 18:58 |
| tvoss | ack, in ~1.5 hours from now, right? | 18:58 |
| racarr | Yeah | 18:58 |
| racarr | ill try ith apparmor=0 right now :) | 19:00 |
| racarr | Hmm it doesn't work :( | 19:02 |
| racarr | ogra_: ^ :( | 19:02 |
| racarr | I think I ill wait for the new images though to do anything more here | 19:02 |
| kgunn | racarr: can you elaborate on "doesn't work" ?? | 19:43 |
| racarr | kgunn: I mean with apparmor=0 nothing changes | 19:44 |
| kgunn | racarr: meaning our theory is busted ? | 19:45 |
| racarr | kgunn: Probably! | 19:45 |
| racarr | but it could be something else with the kernel | 19:45 |
| racarr | or maybe something can someho load apparmor later, and something fishy | 19:45 |
| racarr | so I have decided to work on DPMS and wait for the new image | 19:46 |
| racarr | to know for sure | 19:46 |
| kgunn | racarr: for your next attempt...could you add a report of the egl error like so | 19:50 |
| kgunn | https://pastebin.canonical.com/96033/ | 19:50 |
| kgunn | in android_framebuffer_window.cpp | 19:50 |
| kgunn | ...or something like that | 19:51 |
| racarr | kgunn: ok | 19:57 |
| kgunn | racarr: thanks... | 19:57 |
| racarr | Based on some other errors I think either the framebufer isnt' allocating | 19:58 |
| racarr | or some ioctl inside the driver to reference it is failing | 19:58 |
| racarr | so this might be useful | 19:58 |
| racarr | I may need to talk to alf before I can finish this DPMS stuff | 20:05 |
| racarr | I'm not sure we have theinfrastructure in place to apply display configuration changes without reallocating the scanout buffers | 20:05 |
| racarr | and don't want to step on things | 20:05 |
| racarr | That could also just be what happens in the first implementation of DPMS but that kind of | 20:06 |
| racarr | defeats the point I think | 20:07 |
| kgunn | racarr: kinda weird...i would | 20:08 |
| kgunn | 've thot that | 20:08 |
| kgunn | dps would've been more about cutting clocks to the display/gpu | 20:09 |
| kgunn | rather than messing with mem allocations....altho...maybe the system could save power on mem rails if it frees enoug ? | 20:10 |
| racarr | kgunn: Right, I just mean the way mir is set up | 20:11 |
| racarr | I was encoding the DPMS mode as part of the display configuration | 20:11 |
| racarr | which seems kind of correct | 20:12 |
| racarr | but when you apply a display configuration it rebuilds everything | 20:12 |
| racarr | which is correct for most other things you might ant to change. | 20:12 |
| racarr | but the DPMS settings dont change the layout or anything | 20:12 |
| racarr | so it just requires some reworking of the existing code | 20:12 |
| racarr | maybe I can figure it out today :)it's almost done though so I think syncing iwth alf in the morning might be a good plan | 20:13 |
| racarr | and back to nexus 4 soon | 20:13 |
| kgunn | racarr: gotcha....you're just trying to avoid triggering an unnecessary tear down | 20:13 |
| kgunn | alf__: ^ in case you read scrollback :) | 20:14 |
| racarr | kgunn: Yeah :) | 20:18 |
| racarr | I feel like today is the day for client focus notifications. | 20:21 |
| racarr | Back in 20 to switch to nexus 4 | 20:22 |
| racarr | Nexus time | 20:39 |
| kgunn | bregma: robert_ancell ....well...gooogle....that was rude | 20:41 |
| robert_ancell | indeed! | 20:41 |
| robert_ancell | we're back | 20:41 |
| racarr | http://cdimages.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/ hot of the press ;) | 20:43 |
| robert_ancell | olli_, do we have a hangout for the CFT meeting? | 20:51 |
| * kgunn waits for word from racarr | 20:54 | |
| racarr | kgunn: Flash is alllmost done then takes a bit to install mir | 20:55 |
| racarr | fingers crossed | 20:55 |
| racarr | wow surface flinger took like 30 seconds to come up | 20:59 |
| olli_ | robert_ancell, will add | 20:59 |
| olli_ | robert_ancell, kgunn https://plus.google.com/hangouts/_/calendar/b2xpdmVyLnJpZXNAY2Fub25pY2FsLmNvbQ.miib2j0d57b9590jbd8dufi79c | 21:00 |
| tvoss | racarr, any new insights? | 21:18 |
| kgunn | tvoss: apparmor=0 didn't change the result | 21:21 |
| racarr | Also it's still broken on the new image :( | 21:22 |
| tvoss | racarr, okay, and you said that surfaceflinger is slow to start? | 21:22 |
| racarr | yes that's true it was really slow to start. I haven't tested that again | 21:23 |
| racarr | > 30 seconds to the point where I started trying to investigate if it was broken | 21:23 |
| racarr | then it came up | 21:23 |
| racarr | Im building mir again now (actuallyd onloading 391mb of build dependencies to the phone woohoo) | 21:23 |
| racarr | then probing the egl errors | 21:24 |
| racarr | sometimes there have been errors about not being able to find an egl config | 21:24 |
| racarr | kgunn: Wait where did that | 21:24 |
| racarr | exception come from | 21:24 |
| racarr | I saw it once and was never able to get it again (went away after reboot) | 21:24 |
| kgunn | racarr: its the exception that alan documented in the bug | 21:25 |
| kgunn | my assumption was it was repeatable | 21:25 |
| kgunn | (or consistent) | 21:25 |
| racarr | kgunn: not exactly I got that once | 21:27 |
| racarr | well | 21:27 |
| racarr | many times ina row | 21:27 |
| racarr | but then when I rebooted it went back | 21:27 |
| racarr | to th same no errors except for the ioctl failures in strace | 21:27 |
| racarr | maybe once I build mir I will get that exception this time? :/ | 21:27 |
| racarr | I dont get it from running mir_demo_server on the fresh image | 21:27 |
| racarr | also for me/tmp/mir_socket is created | 21:28 |
| racarr | clients | 21:33 |
| racarr | are stuck at half FPS | 21:33 |
| racarr | 1 FPS | 21:34 |
| racarr | 7 FPS | 21:34 |
| racarr | 26 FPS | 21:34 |
| racarr | 28 FPS | 21:34 |
| racarr | 29 FPS | 21:34 |
| racarr | 30 FPS | 21:34 |
| racarr | 30 FPS | 21:34 |
| racarr | not that anything shows up | 21:34 |
| racarr | oh wo I left one open for a while | 21:34 |
| racarr | terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what(): error posting with fb device | 21:34 |
| robert_ancell | robotfuel, oh you are here already :) | 21:45 |
| robotfuel | :) | 21:45 |
| robert_ancell | robotfuel, we'd like to verify https://code.launchpad.net/~vanvugt/mir/bypass/+merge/180503 against the test machines before landing it - what is the best way to do that? | 21:46 |
| robotfuel | robert_ancell: how do I test it? | 21:48 |
| robert_ancell | robotfuel, Would a PPA fit in with the test system? | 21:48 |
| robert_ancell | Otherwise it's just building from source | 21:49 |
| robert_ancell | The tests are the same as before - if you can run a session and run a GL app then it's good to go | 21:49 |
| robotfuel | robert_ancell: yes ppa's fit as long as ps-jenkins can see them. | 21:49 |
| robotfuel | robert_ancell: what ppa is it in? | 21:54 |
| robert_ancell | robotfuel, I'll set one up and email you the details | 21:55 |
| tvoss | racarr, kgunn which image is the latest that Mir is working with? | 21:55 |
| kgunn | tvoss: unsure...i'm guessing circa 2 weeks ago (based on the bug info) | 22:00 |
| kgunn | meaning 2 week old image | 22:00 |
| racarr | tvoss: Seems about right | 22:01 |
| racarr | maybe even ~1 week | 22:01 |
| kgunn | racarr: should we bisect ? | 22:02 |
| kgunn | images | 22:02 |
| racarr | kgunn: seems so...:( | 22:03 |
| racarr | ^Cphablet@ubuntu-phablet:~/src/trunk/build/bin$ sudo ./mir_demo_standalone_rendeto_fb | 22:03 |
| racarr | __pthread_gettid -2 | 22:03 |
| racarr | terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what(): Could not unblank display | 22:03 |
| racarr | why does | 22:03 |
| racarr | it keep moving | 22:03 |
| racarr | phablet@ubuntu-phablet:~/src/trunk/build/bin$ sudo ./mir_demo_standalone_render_surfaces | 22:03 |
| racarr | __pthread_gettid -2 | 22:03 |
| racarr | ERROR: /home/phablet/src/trunk/src/server/graphics/android/hwc_common_device.cpp(64): Throw in function mir::graphics::android::HWCCommonDevice::HWCCommonDevice(const std::shared_ptr<hwc_composer_device_1>&, const std::shared_ptr<mir::graphics::android::HWCVsyncCoordinator>&) | 22:03 |
| racarr | Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> > | 22:03 |
| racarr | std::exception::what: Could not unblank display | 22:04 |
| racarr | [boost::errinfo_errno_*] = 1, "Operation not permitted" | 22:04 |
| racarr | even | 22:04 |
| racarr | more fascinating | 22:04 |
| kgunn | racarr: so basically new error code every time | 22:04 |
| kgunn | ? | 22:04 |
| racarr | well | 22:04 |
| racarr | it seems like new error code with new image | 22:04 |
| racarr | on this image so far it's consistent | 22:04 |
| racarr | well | 22:04 |
| racarr | ok so the mir from the archive ust silently fails | 22:04 |
| racarr | when I build mir it always fails with | 22:04 |
| racarr | "Could not unblank display" | 22:04 |
| racarr | operation not permitted | 22:04 |
| racarr | the first demo ust doesnt print the errno | 22:05 |
| racarr | always = always on this image | 22:05 |
| racarr | why | 22:06 |
| racarr | is root | 22:06 |
| racarr | not root | 22:06 |
| racarr | :p | 22:06 |
| racarr | of course now I reboot and its back to silently failing | 22:08 |
| racarr | kgunn: After reboot that error is now gone forever seemingly and it's back to failing silently | 22:14 |
| kgunn | racarr: what the what?...so consistently fails with no permission to blank display ....then fails silent ? (meaning just a hang, no exception thrown) | 22:15 |
| kgunn | racarr: well...bisecting will likely be better use of cycles i think | 22:17 |
| racarr | no hang | 22:17 |
| racarr | just nothing on screen | 22:17 |
| kgunn | racarr: got it...(sorry misuse of the word hang) | 22:17 |
| kgunn | racarr: what happens if you try a demo client in that state ? | 22:18 |
| racarr | nothing | 22:19 |
| racarr | just the same half FPS stuff as before | 22:19 |
| racarr | the files in /usr/include/android/hardware | 22:19 |
| racarr | the headers | 22:19 |
| racarr | are significantly different than the files in 3rd-party/android-deps | 22:19 |
| kgunn | racarr: but at least, the client can get an egl context and render to the fb | 22:19 |
| kgunn | ? | 22:19 |
| racarr | kgunn: Seemingly it can | 22:20 |
| racarr | but nothing happens | 22:20 |
| racarr | I assume there are the same strace errors there were on the last image with the ioctl failing | 22:20 |
| kgunn | eeeewwww....header changes huh | 22:20 |
| racarr | maybe | 22:20 |
| racarr | maybe libhardware itself changed | 22:20 |
| racarr | or maybe this is normal and the files in android-deps are magical I don't really know the | 22:21 |
| racarr | story around them | 22:21 |
| racarr | digging | 22:21 |
| kgunn | racarr: actually this is what i was fearing...that egl/hwc/fb glue we can't see possibly changes | 22:21 |
| kgunn | changed | 22:21 |
| tvoss | kgunn, we can see all of the glue | 22:22 |
| kgunn | tvoss: you have egl & hwc implementations ? | 22:22 |
| racarr | libhardware itself is open afaik | 22:23 |
| tvoss | kgunn, racarr exactly | 22:23 |
| robotfuel | robert_ancell: this is blocking nexuiz from running on nvidia and radeon https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1214030 | 22:23 |
| ubot5 | Error: launchpad bug 1214030 not found | 22:23 |
| racarr | I'm not sure im interpreting things right | 22:24 |
| robert_ancell | robotfuel, ta | 22:24 |
| racarr | but it seems like if these headers are out of sync, they have been for ages | 22:24 |
| racarr | so it seems to not matter | 22:24 |
| racarr | what do the different headers mean then | 22:24 |
| tvoss | racarr, are we building against libhardware? | 22:24 |
| robotfuel | robert_ancell: do I need to make that bug public or can you see it? | 22:25 |
| robert_ancell | robotfuel, I can see it - any reason not to make it public? | 22:25 |
| racarr | tvoss: Oi, mir is | 22:25 |
| racarr | but it has it's own headers in 3rd-party/android-deps | 22:26 |
| kgunn | tvoss: racarr ....sure, there is an open source impl...but what about vendor blobs ? | 22:26 |
| robotfuel | robert_ancell: not that I am aware of, I guess apport does that by default. | 22:26 |
| tvoss | racarr, so which headers do we pull into the build? | 22:26 |
| racarr | tvoss: For mir we use the headers in 3rd-party/android-deps | 22:26 |
| kgunn | most vendors replace hwcomposer.cpp | 22:26 |
| racarr | seemingly, because I just copied the headers from /usr/include in to there | 22:26 |
| racarr | and it doesn't build anymore ;) | 22:27 |
| tvoss | kgunn, no worries, all good. It's only about symbols | 22:27 |
| tvoss | racarr, okay, and then we link against what? libhardware? | 22:27 |
| racarr | oi | 22:27 |
| tvoss | racarr, is that yes or no? | 22:28 |
| tvoss | :) | 22:28 |
| robotfuel | robert_ancell: there is also this bug that is blocking us from getting results on nvidia | 22:28 |
| robotfuel | https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1214066 | 22:28 |
| ubot5 | Launchpad bug 1214066 in xorg (Ubuntu) "phoronix benchmarks on nouveau is 4 times slower today than it was last thursday" [Undecided,New] | 22:28 |
| robotfuel | robert_ancell: it's a regression in regular x as well | 22:28 |
| racarr | tvoss: Yes | 22:28 |
| racarr | tvoss: We link against system libhardware but explicitly use the | 22:28 |
| racarr | in tree headers | 22:28 |
| tvoss | racarr, here we go ... | 22:29 |
| robotfuel | robert_ancell: benchmarks are timing out on nvidia because acceleration is non-existent or slow | 22:29 |
| tvoss | racarr, do we _link_ against libhardware on the ubuntu side or are we using hybris? | 22:30 |
| racarr | tvoss: Err,as far as I can see we are linking against the | 22:31 |
| racarr | hybris libhardware | 22:31 |
| tvoss | racarr, okay, even worse than | 22:31 |
| racarr | there is no hwcomposter.h in /usr/include | 22:31 |
| tvoss | kgunn, when is kdub back? | 22:33 |
| racarr | there is some series of macros preventing me from immediately seeing why this compile is faling XD but it's something about version defines/compatibility macros | 22:33 |
| racarr | this compile is when I tried to use the system headers | 22:33 |
| racarr | I think | 22:33 |
| racarr | if I could get a new | 22:34 |
| racarr | hwcomposer.h | 22:34 |
| racarr | it would work | 22:34 |
| kgunn | tvoss: sept2 | 22:35 |
| tvoss | kgunn, really? | 22:35 |
| kgunn | really | 22:36 |
| rsalveti | racarr: which version of hwcomposer.h are you originally using? | 22:38 |
| rsalveti | tvoss: indeed, that's not part of the android-platform-headers | 22:38 |
| rsalveti | I can add it there, but I first want to check how different it is from our current hwcomposer.h from 4.2.2 | 22:38 |
| tvoss | racarr, ^ | 22:39 |
| racarr | rsalveti: see in lp:mir 3rd-party/android-deps/hardware | 22:39 |
| racarr | Phone sorry, will be back in 5 min with more info XD | 22:39 |
| racarr | ok | 22:42 |
| racarr | so...um. I guess I dont know | 22:42 |
| racarr | how to identify what version of hwcomposer.h it is | 22:42 |
| racarr | or why we use these in tree headers | 22:42 |
| racarr | is it legacy only? or is there another reason | 22:42 |
| rsalveti | racarr: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_libhardware.git;a=tree;f=include/hardware;h=139b8bb682030607ffea03beca691ef877a5e794;hb=refs/heads/phablet-saucy | 22:43 |
| rsalveti | this is the one we're using at our android images now | 22:43 |
| kgunn | hwcomposer_defs.h changed as well | 22:44 |
| kgunn | racarr: ^ | 22:44 |
| racarr | yeah | 22:44 |
| racarr | rsalveti: Ok thanks. I am going to see if I can get mir to compile | 22:44 |
| racarr | against these headers | 22:44 |
| rsalveti | racarr: tvoss: http://paste.ubuntu.com/6004566/ | 22:45 |
| rsalveti | comparing the headers, nothing really critical | 22:46 |
| rsalveti | only difference is removal of HWC_BLIT | 22:46 |
| racarr | rsalveti: Err, ok so these | 22:46 |
| racarr | aren't the headers | 22:46 |
| racarr | that are in /usr/include/android | 22:46 |
| racarr | on the device | 22:46 |
| racarr | the diff there is much larger | 22:46 |
| rsalveti | racarr: there's no hwcomposer.h in there | 22:47 |
| rsalveti | that's why I'm comparing with what got changed in the android side | 22:47 |
| rsalveti | to see if the headers inside mir would need any sort of update | 22:47 |
| rsalveti | racarr: what was the last known working image? | 22:48 |
| racarr | err | 22:48 |
| racarr | I had a hardware.h with a much larger difference | 22:48 |
| racarr | and no it wont build | 22:48 |
| racarr | rsalveti: No one knows. 2 weeks ago should be safe though | 22:48 |
| kgunn | rsalveti: yeah...but that addition of ifdef qcom hw adds an int right in the middle of a hwc struct | 22:48 |
| kgunn | that's used for hwframebuffer | 22:48 |
| rsalveti | right, can't we get someone to trace that based on the ones available in http://cdimage.ubuntu.com/ubuntu-touch/ ? | 22:49 |
| rsalveti | we got one from 12 there, would be nice to see if it works there | 22:49 |
| kgunn | racarr: can you test http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130812/ | 22:50 |
| rsalveti | kgunn: right, but I don't think QCOM_HARDWARE is defined at all for nexus 4 | 22:50 |
| rsalveti | iirc | 22:50 |
| tvoss | racarr, rsalveti off now, quite late here. kgunn, racarr can you guys send me a handover mail? | 22:51 |
| kgunn | tvoss: you bet | 22:51 |
| kgunn | rsalveti: really...? that would surprise me...isn't n4 qcom ? | 22:51 |
| racarr | tvoss: Ok | 22:52 |
| rsalveti | kgunn: it is, but iirc that define was cm specific for other qcom based devices | 22:52 |
| racarr | rsalveti: http://pastebin.ubuntu.com/6004587/ | 22:52 |
| rsalveti | but would need to double check, and you can easily rebuild against the updated header to test as well | 22:52 |
| racarr | this is the diff I get when copying /usr/include/android | 22:52 |
| racarr | in to the android-deps | 22:52 |
| racarr | so where are | 22:52 |
| racarr | THESE files coming from? | 22:52 |
| racarr | using the files from github with the small diff didnt ork | 22:53 |
| racarr | interesting trivia: Cmake does not detect changes to the android-deps folder ;) | 22:55 |
| rsalveti | racarr: these are from libhybris, which originally came from our phablet git repos | 22:55 |
| rsalveti | but they were always different, that's why I'm not sure if this is indeed the cause | 22:55 |
| racarr | yes | 22:55 |
| racarr | thats hat the changelogs seemed to say to me too | 22:56 |
| rsalveti | tracing the last working image would be a better idea I guess | 22:56 |
| racarr | but I am double checking because hat else could it be | 22:56 |
| racarr | yeah... | 22:56 |
| racarr | kgunn: http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130812/ | 22:56 |
| racarr | still ant me to test that one? | 22:56 |
| kgunn | racarr: i think that would help | 22:57 |
| racarr | ok | 22:58 |
| racarr | ok the thing is installing the PPA on this image will bring in other updates I guess so I have to | 23:08 |
| racarr | build mir again.. | 23:08 |
| racarr | at this rate it will take like 1 hour per image | 23:12 |
| racarr | sigh | 23:12 |
| RAOF | Ah, vgdb. You're the best. | 23:20 |
| kgunn | racarr: sorry dude | 23:25 |
| kgunn | racarr: i do think you're on to something with the header deltas.... | 23:26 |
| kgunn | gonna hop off to eat dinner.. | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!