[01:58] another fun day of powerd for me... see yall tommorrow [02:11] Later kdub [02:44] racarr: Oh, Kevin mentioned that you were fighting with nested? === chihchun_afk is now known as chihchun === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [07:25] RAOF: Silly question: In the nested world, a greeter is a shell too, right? [07:25] duflu: There will certainly be a greeter shell, yes. [07:25] Good. Just checking I understood that much [07:25] Whether or not the greeter is built into that shell or is a separate client is neither here nor there, really. [07:38] RAOF: Interesting point. If the greeter is just a client then the efforts to support translucent nested servers won't be used (anpok!) [07:39] No, they will. [07:39] There will still be a nested shell that the greeter runs in. [07:39] Sounds weird. We'd have to have a good reason for that... [07:40] The greeter needs to have a bit of session logic, as it folds in multiple processes. [07:40] See the current greeter - the indicators need to be folded in, and they can pop up windows, etc. [07:41] So put another way... in the nested case you can choose which server a client connects to. Why wouldn't the greeter just be a client to the system compositor? [07:41] Oh, right, popups in greeters. OK [07:41] Because then everything it spawns will be clients of the system compositor, and we would need nontrivial window management in the system compositor. [07:41] Right, you've got it :) [07:42] You could just say don't make greeters with windows :) [07:42] I think Ubuntu is unique in that area [07:47] I'm pretty sure we'll continue to want non-trivial greeters; the ability to enable wifi before logging in remotely requires some windowish. [08:07] Wow, framerate (thoughput) is indeed higher when nesting. What's that all about?! [08:07] Perhaps nesting allows the extra N-buffering we don't really do properly with a single server? [08:16] Perhaps. [08:22] hmm [08:23] rfkill block / unblock seems to fix the issue [08:23] RAOF: do you experience strange behavior on the ac7260 wifi chip [08:24] anpok: I don't have one of those; I've got Qualcomm Atheros AR9462 [08:25] That's odd. Intel wifi is usually the best. And ac7260 I think is the newest ... http://ark.intel.com/products/75439/Intel-Dual-Band-Wireless-AC-7260 [08:25] it works very well for like a day usually [08:26] but then connection attempts seem to take ages.. lots of packet loss [08:28] maybe caused by some upgrade.. I had no issue in london [08:28] I've seen complaints that Intel wifi has been going backwards, quality-wise. [08:28] and the time before [08:29] Hmm, and now nested is slower, which sounds more sane [08:31] duflu: I hoped that RAOF branch gets merged sooner.. what do you mean by resubmit? wait untill checks-for-urfaceless is in devel? [08:32] anpok: No, you can resubmit now and RAOF's diff will be hidden if it's listed as a prereq of yours [08:32] Just fill in the Prerequisite Branch field [08:48] anpok: Thanks. That's smaller :) [08:49] yeah.. I didnt expect such a feature would exist [08:50] regarding tests.. I think I need to do some more behavior changes [08:50] so far it only allows selecting pixel formats [08:51] which is ignored by offscreen and android .. and it would fail for mesa [08:52] at least now it would fail [08:52] hm i think inside gbm.. if somebody tries to create an ARGB buffer with the scan out flag it would fail [08:54] shall I filter such an attempt.. and pick a similar pixel format without alpha - or throw? [09:30] ah ok display class in mesa also does not take that setting into account [09:33] anpok: I've noticed it's very confusing trying to tell the difference between nested and non-nested servers on screen. Could you by any chance add an option to select the glClear background colour for each? :) [09:34] ... I noticed after realizing I was moving and resizing the nested server and _not_ the client within it :P [09:34] yeah [09:34] we could also draw borders [09:34] clear is simpler [09:40] anpok: The glClear call already exists. Just change glClearColor [09:40] Although when I changed the default colour, that upset Unity8 people [09:44] oh there is clear call in mesa platform [09:44] i thought only in the example shell [09:45] would we see garbage on screen otherwise - if there was no initial clear&swap? [09:52] anpok: src/server/compositor/gl_renderer.cpp: glClear(GL_COLOR_BUFFER_BIT); === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [11:32] CI and Autolanding are failing android-trusty-i386 with "W: GPG error: http://ppa.launchpad.net trusty Release" - I've put a general query on #ubuntu-ci-eng, but no-one I know is awake there. === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [14:41] kgunn: alan_g: https://code.launchpad.net/~afrantzis/mir/fix-mako-ci-use-steady-clock/+merge/199469 [14:43] alf_: looking... [14:44] alan_g: resubmitted against mir-devel: https://code.launchpad.net/~afrantzis/mir/fix-mako-ci-use-steady-clock/+merge/199472 [15:01] alf_: can you try a cross-build (including running tools/setup-partial-armhf-chroot.sh)? Do you see something like "/usr/arm-linux-gnueabihf/include/bits/byteswap.h:74:17: error: ‘__uint64_t’ does not name a type"? [15:05] alan_g: trying [15:10] alan_g: alf_ sorry...was in with ui guys... [15:10] * kgunn waits for cross build results [15:10] kgunn: ? [15:11] alan_g: just checking back in... [15:11] seems the 32bit stuff was a red herring [15:12] alan_g: problem confirmed here too, I will try again after an apt-get update === dandrader is now known as dandrader|lunch [15:24] alf_: thanks [15:32] alan_g: FWIW, no change after ensuring I have an up-to-date system [15:33] alf_: agreed. Something changed upstream - not yet tracked down what. (I hope I've an old copy of the relevant files on my laptop...) === chihchun is now known as chihchun_afk [16:36] kgunn: @fix-mako-ci-use-steady-clock, it's blocked by cross-compilation issues so we might want to merge manually to get it in ASAP [16:36] alf_: please do.... [16:36] kgunn: cross-compilation issues == the ones Alan is investigating [16:37] alf_: yes...i realized it right after i saw it fail & tried to approve again :P [16:45] Hmm, this must be related - a load of "# if __GLIBC_HAVE_LONG_LONG" conditions have become unconditional in the gnu headers. === dandrader|lunch is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === chihchun_afk is now known as chihchun