[01:52] <duflu> Eeek, brown-out
[01:57] <RAOF> Win!
[02:10] <RAOF> The mediumtests-trusty-touch and mediumtests-runner-mako CI jobs are just failing at the moment, aren't they? That's not an issue with my code?
[02:15] <duflu> RAOF: They are indeed just failing :/
[02:15] <duflu> in 80-90% of cases...
[02:16] <duflu> So you can retry :)
[03:27] <duflu> RAOF: Could you kindly give the changelog and version proposals an honorary approval?
[03:29] <RAOF> There you go.
[03:47] <duflu> RAOF: Ta
[03:48] <RAOF> I know *why* we have debian/ in the repository, I just continue to think it's a bad idea ;)
[03:48] <duflu> RAOF: If we continue with the two separate branches then I agree. But while the goal is to ideally have one, then I disagree
[03:49] <duflu> Hmm, we *could* hide debian/ in dev and just quietly maintain it in lp:mir :)
[03:50] <RAOF> Yes, we could.
[03:50] <duflu> Although that makes code reviews of packaging changes impossible
[03:50] <duflu> Umm, less convenient
[03:50] <RAOF> Not really? We just review on lp:mir
[03:51] <RAOF> I don't think it's a bad idea to have packaging changes reviewed in a different place to code changes; our developer skill sets are almost entirely disjoint, too.
[03:51] <duflu> Surely debian/ as a subdirectory is designed that way so you can keep it with your code without stepping on any toes
[03:52] <RAOF> Historically it has not been; we're being an unhelpful upstream by including it.
[03:52] <RAOF> (This is mostly fixed with deb src 3.0, though)
[03:52] <duflu> RAOF: I hate to say it, but code reviews are even more scarce on lp:mir than dev.
[03:53] <RAOF> Are there any reviews to *do* on lp:mir?
[03:53] <duflu> I mean, if you rely on the subset of developers with the skills to review packaging changes, then you don't have enough reviewers
[03:54] <RAOF> Ah, but we can get potentially get didrocks and other distro people to review those changes.
[03:54] <duflu> Because he loves us so much already
[03:54] <duflu> And rightly so
[03:54] <duflu> I mean that both ways
[03:55] <RAOF> No one from distro is going to regularly check merges that are almost all code changes unrelated to distro work; if we separate out those quite-infrequent changes it's more likely we can shanghai people to do them.
[06:58] <RAOF> duflu: What's the typo?
[06:58] <duflu> RAOF: construtor ?
[06:59] <RAOF> AHA!
[06:59] <duflu> Or is it copy-construe-er?
[07:00] <duflu> If all else fails, copy and paste into an edit field with spell-checking
[07:02] <RAOF> Hm. I do appear to have dropped into my native braces style a bit there, don't I?
[07:04] <RAOF> Also, I'm pretty sure our style guide suggests 120 characters ;)
[07:06] <duflu> RAOF: On the theme of readability, not style compliance :)
[07:07] <duflu> Though I've already spent enough of my life trying to explain to people why a limit of 80 cols is important. I won't waste my breathe (much) more
[07:08] <duflu> breath too
[07:13]  * RAOF wonders if we should set up clang-format as a precommit hook.
[07:22] <duflu> RAOF: I suspect we have too many exceptions we'd like to keep :)
[07:23] <duflu> Including 3rd party, which we wish to not touch where possible
[07:44] <tvoss> RAOF, +1 on clang-format
[08:38] <anpok> is there a rule for curly braces placement .. egyptian vs on the same column?
[08:39] <RAOF> Is egyptian
[08:39] <RAOF> if (foo)
[08:39] <RAOF> {
[08:39] <RAOF>    hello();
[08:39] <RAOF> }
[08:39] <RAOF> ?
[08:39] <RAOF> If so, yes, we use Egyptian :)
[08:39] <anpok> nope
[08:39] <anpok> if (foo) {
[08:39] <anpok>    hello();
[08:39] <anpok> }
[08:40] <anpok> http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html
[08:48] <alf_> anpok: http://unity.ubuntu.com/mir/cppguide/index.html
[08:51] <tvoss> olli, ping
[08:51] <anpok> alf_: yes, but it only states it for function definitions.. and some examples use { on the same line..
[08:52] <alf_> anpok: they are wrong :)
[08:52] <anpok> obviously
[08:54] <duflu> Awesome. Now I can code like an Egyptian and party like it's 1986 simultaneously
[08:57] <RAOF> alf_: I'd like a second opinion on GLContext { void make_current() const; }; duflu has suggested that having it be const is an artefact of using non-C++ types, and I can see that, but I vacillated when writing the commit message for unconstifying it.
[08:57] <RAOF> alf_: cf: https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510
[08:58] <duflu> RAOF: I'm happy to keep const. Just expect it to be non-const if the implementation changes
[09:00] <RAOF> duflu: Ok then. I think conceptually const makes more sense, and it's an implementation detail if it isn't.
[09:00] <duflu> Yeah const is always a maintenance risk in that way
[09:01] <duflu> There's a reasonable argument for not having const in the language :)
[09:01] <duflu> Although I think having const with clearly defined policy is better
[09:14] <anpok> it is always simpler to explain the usage of const_cast / mutable if it is to fulfill a const in the problem domain, than because of a possible trivial implementation
[09:16] <anpok> duflu: any suggestions on the pixel format encoding? should I only take RGB based formats into account now..
[09:16] <anpok> or look for something that also adresses yuv ..
[09:17] <duflu> anpok: I suggest sticking with what you have (don't change MirPixelFormat for now). It's nice and forward compatible to just define query functions like you have
[09:17] <duflu> Fitting all the info we need into 32-bits is quite difficult actually
[09:18] <anpok> SDL2 does something similar .. but they dont encode shift values directly
[09:20] <duflu> anpok: The panacea is an accurate set of instructions for interpreting/encoding any pixel :)
[09:20] <duflu> Without switch/case
[09:21] <RAOF> We should probably look at gallium's format descriptor infrastructure.
[09:22] <RAOF> anpok: That's what your merge proposal triggered for me.
[09:22] <anpok> the one in gbm.h
[09:22] <anpok> ?
[09:23] <duflu> I think fourcc is kind of OK, but fails to resolve the bug really. You have to switch on all known fourcc's. It's ugly
[09:23] <RAOF> anpok: No... let me hunt it down.
[09:23] <duflu> Hmm SDL_pixels.h is interesting
[09:26] <RAOF> https://github.com/RAOF/mesa/tree/egl-platform-mir/src/gallium/auxiliary/util - u_format.{c,h,csv}
[09:28] <RAOF> A bunch of that is driver-implementation-specific, but the general gist could be useful.
[09:32] <anpok> hm there are also compressed formats
[09:32] <anpok> hm those would not be needed ...
[09:34] <RAOF> Right. There are a huge number of formats there, most of which we wouldn't need.
[09:35] <RAOF> Also, we (probably?) don't need all that description; block width and height, channel swizzle, layouts that aren't ‘plain’
[09:36] <anpok> that reminds me of https://github.com/laanwj/etna_viv/blob/master/doc/hardware.md
[09:37] <anpok> if I am not mistaken the device can render to super tiled frame buffers.. and the optional composition gpu can do scanouts on those
[09:48] <anpok> that might be relevant again with hwc on android
[09:49] <anpok> different topic in some code parts DisplayConfigurationPolicy is named "initial" conf.. why only initial?
[09:50] <anpok> i initially assumed that.. if changes to the available displays happen the policy would querried again
[09:53] <RAOF> anpok: No; that's only used for initial configuration, and something else is assumed to handle configuration on hotplug events.
[10:00]  * RAOF EODs
[10:26]  * duflu too. Overdue for cooking a healthy meal
[11:45] <mlankhorst> RAOF: grrr! fix your trailing whitespace
[12:31] <mlankhorst> RAOF: anway xorg-server for saucy-proposed, pixman and libdrm for all supported releases in the release queue:)
[13:19] <anpok> i am a bit concerned about the conversion operator usage
[13:19] <anpok> in EGLDisplayHandle and similar... not widely used. it seems odd to have conversion operators for typedefs of void*
[15:16] <kgunn> bregma: did RAOF get you the mesa you needed for nested mir on desktop ?
[15:16] <kgunn> never saw a follow up
[15:22] <anpok> kgunn: iirc nested mir on desktop also needs a small change in mesa platform which is currently in review
[15:23] <kgunn> anpok: exactly, this is what i was asking about
[15:23] <kgunn> anpok: i looked at raof's github but didn't see any reference
[15:23] <kgunn> but maybe i don't know where to look exactly ?
[15:24] <kgunn> can you share if you do ?
[15:25] <anpok> sorry my wording was ambigiuous ..
[15:25] <anpok> mir/mesa needed another change
[15:25] <anpok> there is some utility class that needs surfaceless context, but creates a pbuffer surface which is not supported by mesa.
[15:26] <anpok> https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510 thats the change
[15:40] <xnox> Does mir at all can export / has api to query detected screen resolution and the DPI setting?
[15:44] <anpok> you can querry that through the mir client api - take a look at demo_client_display_config.c in the examples folder
[16:09] <kdub> yay https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037904.html
[16:10] <xnox_> =)
[16:11] <kdub> i was just looking up who to +1... i'll see  if  i can drop my amateur cmake cross compile file from mir
[16:26] <kgunn> kdub: so did you say if you put in some logic to "ignore" the second "on"...display turns on but then hangs ?
[16:27] <kdub> kgunn, right
[16:28] <kdub> like, the problem is
[16:28] <kgunn> kdub: damn...that's just weird...so not only does powerd send it...it meant to send it :)
[16:28] <kdub> right
[16:28] <kdub> i'm still poking around powerd trying to understand
[16:29] <kdub> ricmm, ping
[16:35] <greyback> kdub: anything I could do to help?
[16:36] <kdub> greyback, don't know of anything at the moment
[16:37] <greyback> kdub: ok
[16:37] <kdub> unity-mir's role seems to be pretty straightforward
[17:33]  * mterry pokes ricmm about libhybris
[17:34] <kdub> mterry, what about hybris?
[17:35] <mterry> kdub, that libhybris fix that ricmm identified during the sprint, to allow two different users (root and phablet) to access hw on maguro
[17:36] <mterry> It's the last fix needed for nested mode to land
[17:37] <kdub> ah, okay
[17:37] <kdub> mterry, is screen on/off with nested working okay? i have some concerns about that
[17:38] <kdub> eh, actually, i'd expect it to work
[17:39] <kdub> its just funny that we make the power request to a nested client who asks the host server
[17:39] <kdub> too many hops
[17:40] <mterry> kdub, no, UCS is actually the one that will host the dbus interface
[17:40] <mterry> kdub, the unity-mir code to do it is still there, but will gracefully fail once UCS already owns it
[17:40] <mterry> kdub, and then we can remove that codee
[17:40] <kdub> mterry, great, sounds good
[20:57] <kgunn> kdub: so i was just trying your instructions...i'm on N4 with todays devel-proposed image...after i install mir-test-tools
[20:58] <kgunn> the only mir test i see is mir_stress
[20:58] <kgunn> any ideas?
[20:58] <kgunn> https://docs.google.com/a/canonical.com/document/d/1oxXDxehRQ35rYRwkuBCy1ZNmB_IBpg5UhE3jvNHEk_0/edit
[21:00]  * kdub looks
[21:07] <kdub> they were added in rev 1256
[21:07] <kdub> and it looks like 1248 was the last merge to lp:mir
[21:08] <kdub> kgunn^^
[21:09] <kgunn> kdub: heh
[21:09] <kgunn> fell victim