[01:58] <kdub> another fun day of powerd for me... see yall tommorrow
[02:11] <duflu> Later kdub
[02:44] <RAOF> racarr: Oh, Kevin mentioned that you were fighting with nested?
[07:25] <duflu> RAOF: Silly question: In the nested world, a greeter is a shell too, right?
[07:25] <RAOF> duflu: There will certainly be a greeter shell, yes.
[07:25] <duflu> Good. Just checking I understood that much
[07:25] <RAOF> Whether or not the greeter is built into that shell or is a separate client is neither here nor there, really.
[07:38] <duflu> 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] <RAOF> No, they will.
[07:39] <RAOF> There will still be a nested shell that the greeter runs in.
[07:39] <duflu> Sounds weird. We'd have to have a good reason for that...
[07:40] <RAOF> The greeter needs to have a bit of session logic, as it folds in multiple processes.
[07:40] <RAOF> See the current greeter - the indicators need to be folded in, and they can pop up windows, etc.
[07:41] <duflu> 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] <duflu> Oh, right, popups in greeters. OK
[07:41] <RAOF> 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] <RAOF> Right, you've got it :)
[07:42] <duflu> You could just say don't make greeters with windows :)
[07:42] <duflu> I think Ubuntu is unique in that area
[07:47] <RAOF> 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] <duflu> Wow, framerate (thoughput) is indeed higher when nesting. What's that all about?!
[08:07] <duflu> Perhaps nesting allows the extra N-buffering we don't really do properly with a single server?
[08:16] <RAOF> Perhaps.
[08:22] <anpok> hmm
[08:23] <anpok> rfkill block / unblock seems to fix the issue
[08:23] <anpok> RAOF: do you experience strange behavior on the ac7260 wifi chip
[08:24] <RAOF> anpok: I don't have one of those; I've got Qualcomm Atheros AR9462
[08:25] <duflu> 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] <anpok> it works very well for like a day usually
[08:26] <anpok> but then connection attempts seem to take ages.. lots of packet loss
[08:28] <anpok> maybe caused by some upgrade.. I had no issue in london
[08:28] <RAOF> I've seen complaints that Intel wifi has been going backwards, quality-wise.
[08:28] <anpok> and the time before
[08:29] <duflu> Hmm, and now nested is slower, which sounds more sane
[08:31] <anpok> 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] <duflu> anpok: No, you can resubmit now and RAOF's diff will be hidden if it's listed as a prereq of yours
[08:32] <duflu> Just fill in the Prerequisite Branch field
[08:48] <duflu> anpok: Thanks. That's smaller :)
[08:49] <anpok> yeah.. I didnt expect such a feature would exist
[08:50] <anpok> regarding tests.. I think I need to do some more behavior changes
[08:50] <anpok> so far it only allows selecting pixel formats
[08:51] <anpok> which is ignored by offscreen and android  .. and it would fail for mesa
[08:52] <anpok> at least now it would fail
[08:52] <anpok> hm i think inside gbm.. if somebody tries to create an ARGB buffer with the scan out flag it would fail
[08:54] <anpok> shall I filter such an attempt.. and pick a similar pixel format without alpha - or throw?
[09:30] <anpok> ah ok display class in mesa also does not take that setting into account
[09:33] <duflu> 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] <duflu> ... I noticed after realizing I was moving and resizing the nested server and _not_ the client within it :P
[09:34] <anpok> yeah
[09:34] <anpok> we could also draw borders
[09:34] <anpok> clear is simpler
[09:40] <duflu> anpok: The glClear call already exists. Just change glClearColor
[09:40] <duflu> Although when I changed the default colour, that upset Unity8 people
[09:44] <anpok> oh there is clear call in mesa platform
[09:44] <anpok> i thought only in the example shell
[09:45] <anpok> would we see garbage on screen otherwise - if there was no initial clear&swap?
[09:52] <duflu> anpok: src/server/compositor/gl_renderer.cpp:    glClear(GL_COLOR_BUFFER_BIT);
[11:32] <alan_g> 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.
[14:41] <alf_> kgunn: alan_g: https://code.launchpad.net/~afrantzis/mir/fix-mako-ci-use-steady-clock/+merge/199469
[14:43] <alan_g> alf_: looking...
[14:44] <alf_> alan_g: resubmitted against mir-devel: https://code.launchpad.net/~afrantzis/mir/fix-mako-ci-use-steady-clock/+merge/199472
[15:01] <alan_g> 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] <alf_> alan_g: trying
[15:10] <kgunn> alan_g: alf_ sorry...was in with ui guys...
[15:10]  * kgunn waits for cross build results
[15:10] <alan_g> kgunn: ?
[15:11] <kgunn> alan_g: just checking back in...
[15:11] <kgunn> seems the 32bit stuff was a red herring
[15:12] <alf_> alan_g: problem confirmed here too, I will try again after an apt-get update
[15:24] <alan_g> alf_: thanks
[15:32] <alf_> alan_g: FWIW, no change after ensuring I have an up-to-date system
[15:33] <alan_g> alf_: agreed. Something changed upstream - not yet tracked down what. (I hope I've an old copy of the relevant files on my laptop...)
[16:36] <alf_> 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] <kgunn> alf_: please do....
[16:36] <alf_> kgunn: cross-compilation issues == the ones Alan is investigating
[16:37] <kgunn> alf_: yes...i realized it right after i saw it fail & tried to approve again :P
[16:45] <alan_g> Hmm, this must be related - a load of "#  if __GLIBC_HAVE_LONG_LONG" conditions have become unconditional in the gnu headers.