[02:14] <thomi> Hi mir-folk - I finally got the glmark tests to run on our highend intel hardware machine - the results are here: http://10.97.2.10:8080/job/mir-glmark-daily/7/label=ps-intel-4000-he/artifact/results.json
[02:14] <thomi> tldr: getting 60FPS on every test
[02:14] <thomi> which doesn't seem very useful
[02:15] <RAOF> thomi: That's currently expected behaviour.
[02:16] <thomi> so I'm wondering if I should run this on a lower-end machine, or perhaps customise the way we run glmark?
[02:16] <thomi> RAOF: so how to we notice performance degredations?
[02:17] <RAOF> thomi: Someone (and by "someone" I probably mean "me") fixes https://bugs.launchpad.net/mir/+bug/1130553
[02:20] <thomi> RAOF: ahhhh, right
[02:20] <thomi> RAOF: yeah, you should do that :)
[02:20]  * RAOF is the mesatron.
[02:21] <thomi> now that we have mesa autolanding.... no more excuses :)
[02:34] <thomi> robert_ancell: is it OK to publish these benchmark results to the public jenkins server? It'll make them easier to chart that way
[02:40] <robert_ancell> thomi, yes, sounds good
[02:40] <thomi> sweet
[02:42] <robert_ancell> thomi, btw, how hard would it be to set up autolanding for lightdm?
[02:42] <thomi> robert_ancell: very easy
[02:42] <robert_ancell> autolanding? I mean the "merge and push when MP set to approved"
[02:43] <thomi> yup - that's autolanding. You also get CI (aka: "build & test every MP before it's approved and comment on the MP") for free
[02:43] <robert_ancell> thomi, awesome. What do we need to do to turn that on now?
[02:44] <thomi> I need to propose a MP that modifies some confguration, then tomorrow morning I can get Francis to review it for me
[02:44] <robert_ancell> thomi, please do
[02:44] <thomi> should be able to turn it on before lunchtime tomorrow
[02:44] <thomi> ok
[03:01] <thomi> robert_ancell: which packaging branch should I use for the autolanding?
[03:01] <robert_ancell> thomi, can you just set it to compile for now?
[03:02] <thomi> robert_ancell: hmmmm, I actually don't know, I'll find pout
[03:02] <thomi> *out
[03:02] <robert_ancell> thomi, short answer is there isn't one in use at the moment
[03:03] <thomi> robert_ancell: OK - if need be we can grab the ubuntu packaging info and hack it till it works :)
[03:03] <robert_ancell> thomi, yeah, that will work
[03:04] <thomi> robert_ancell: also, do you want autolanding for lp:lightdm or for some other lightdm branch?
[03:04] <robert_ancell> thomi, lp:lighdm
[03:04] <thomi> robert_ancell: and finally, if we build a package, we can push it to a PPA at the same time...
[03:04] <robert_ancell> thomi, yeah, that would be handy
[03:05] <thomi> what PPA?
[03:06] <thomi> robert_ancell: also, which series should we be building for? The default is quantal & raring, but I can add precise support as well
[03:07] <robert_ancell> thomi, it should build fine on precise, so that would be useful too
[03:34] <thomi> robert_ancell: which PPA should it dput to?
[03:34] <robert_ancell> thomi, https://launchpad.net/~lightdm-team/+archive/daily
[03:35] <thomi> cool
[05:09] <RAOF> Mmm. Return code checking. Who needs it!
[05:09] <RAOF> Not gallium's DRI code, that's for sure!
[07:42] <alf_> RAOF: How is dma-buf on radeon going?
[07:42] <RAOF> alf_: Most of the way through the setup.
[07:42] <alf_> RAOF: great
[07:43] <RAOF> Most of the effort is in extending the gallium interface, which is now done. Actually pulling a buffer out of a dma-buf fd is (should be!) pretty simple :)
[08:36] <alf_> Anyone else want to take a look at https://code.launchpad.net/~afrantzis/mir/display-server-main-loop-1/+merge/157693 ?
[08:37] <alan_g> alf_: apparently not
[08:38] <alf_> alan_g: heh, you approved it already :)
[08:38] <alan_g> ;)
[09:37] <mlankhorst> I'm trying to build mir on precise, getting an error there
[09:37] <mlankhorst> /home/mlankhorst/nfs/xorg/mir/include/server/mir/time/time_source.h:34:29: error: 'virtual mir::time::TimeSource::~TimeSource()' declared virtual cannot be defaulted in the class body
[09:40] <alan_g> mlankhorst: what compiler version are you using?
[09:40] <mlankhorst> gcc 4.6.3
[09:40] <alan_g> You'll need 4.7
[09:42] <xnox> mlankhorst: 4.8 would be even better =) precise has exccelent support for lxc, so just start up a raring container for mir development =)
[09:43] <mlankhorst> blegh I'll mess up my raring chroot then
[09:45] <mlankhorst> no need for virtualization when I can boot my chroot off the network too :P
[11:19] <mlankhorst> is there a branch of mir somewhere that uses dma-buf instead of flink for passing buffers?
[11:20] <mlankhorst> oh found it
[11:25] <alan_g> alf_: I'll be off in half an hour (for the rest of the week). Anything you'd like me to look at first?
[11:26] <alf_> alan_g: No, thank you. I haven't pushed any vt stuff for review yet.
[11:30] <mlankhorst> ah great xxv-nouveau works with xmir
[11:32] <mlankhorst> http://people.canonical.com/~mlankhorst/xmir-nouveau.patch
[11:34] <mlankhorst> plus http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=for-airlied-next
[15:04] <alf_> status: More work on vt switching (getting close)
[15:05] <kdub> status: more work on fb native window (getting close)
[15:05] <kdub> specifically, it has some anxious jitter that I have to root out, but it can post to screen
[16:14] <racarr> hi
[16:36] <racarr> mlankhorst: Client rendering and everything works with Mir/noveau? Cool :) I don't know of anyone to have tested it so far
[17:01] <racarr> Iterated on fix-shell-focus-locking
[17:38] <mlankhorst> racarr: I only tested xserver
[17:39] <racarr> Ah! Well xserver is a client
[17:39] <racarr> so good news :)
[17:48] <ogra_> now try XDMCP :P
[17:48] <mlankhorst> glxgears ran though, dno what xdmcp would give me, apart from a security hole
[17:48] <ogra_> would it ? i woould actually expect it to block
[17:49] <ogra_> or rather expect Mir to block it
[17:49] <mlankhorst> shrug
[17:50]  * ogra_ would consider the security hole in Mir if Mir allowed  a client such things , but i might be wrong 
[18:02] <racarr> iterated on xkb-mapper and enable-inprocess-egl...now orking on making qtubuntu work on top of mirclient with xkb
[18:51] <racarr> Hey! I connected to my screen session via terminal emulator in mir :D���
[18:51] <racarr> lss���¿½��oh god funny characters
[18:51] <mlankhorst> invalid characters, even
[18:51] <racarr> this QML terminal emulator is a little weird
[18:56] <racarr> is jenkins broken someho?
[18:58] <racarr> oh maybe I just segfaulted gdb or whatever
[19:36] <racarr> kdub: So I updated the two build scripts for android for xkbmapper to install xkbcommon and xkbcommon-dev
[19:36] <racarr> but it gets put in /usr/lib/arm-linux-blabla/
[19:36] <racarr> so -lxkbcommon doesn't work.
[19:36] <racarr> ideas?
[19:36] <racarr> I don't really understand
[19:36] <racarr> multiarch /usr/lib
[19:38] <racarr> kdub: p.s. btw want to check out enable-inprocess-egl again? I think I fixed your last comment
[19:38] <racarr> mir_native_display() name -> shell_egl_display()
[19:39] <kdub> racarr, cool, ill look that over then
[19:41] <kdub> racarr, i had similar problems with glog, maybe look at that cmake file?
[19:41] <racarr> kdub: Ok ill check it out in a few
[20:05] <thomi> morning
[20:05] <kdub> hello thomi
[20:18] <racarr> have I ever mentioned that I love curry.
[20:25] <bschaefer> racarr, curry? http://en.wikipedia.org/wiki/Curry_%28programming_language%29
[20:31] <racarr> bschaefer: http://en.wikipedia.org/wiki/Vindaloo ;)
[20:33] <bschaefer> racarr, :), nice, curry is always good! I still yet to have a favourite
[20:33] <racarr> bschaefer: Vindaloo is my favorite indian curry but lately I am really obsessed with the thai curries...with lots of coconut milk and bamboo
[20:33] <racarr> also a place close by started doing curry burritos oO
[20:33] <bschaefer> red curry is awesome as well! Curry burritos! I need to try that...
[20:34] <racarr> works really well with just rice and beans all rolled up
[20:34] <bschaefer> yeah, you need the right % of rice vs curry otherwise a mess!
[20:35] <racarr> mm
[20:49] <racarr> Working on a short refactoring to use a method similar to mia::InputConfiguration for SessionManager construction
[20:50] <racarr> then going to use that to make a demo-shell example binary with some input filters
[21:12] <thomi> robert_ancell: you around?
[21:16] <robert_ancell> thomi, yes
[21:16] <robert_ancell> racarr, curry burritos?
[21:16] <racarr> robert_ancell: Yesssss
[21:17] <racarr> Mexican<OtherFoodType T> is commonly instantiated in these parts ;)
[21:47] <RAOF> racarr:
[21:47] <RAOF> racarr: When you say "the old version [mir_egl_native_display_is_valid] still works" what do you mean?
[21:48] <RAOF> racarr: Because when I used it, it didn't :)
[21:50] <racarr> RAOF: Err ok lets investigate hsortly
[21:50] <racarr> I am getting ready to propose a different branch then take a tea break
[21:50] <racarr> then I will figure out what is going on there
[21:50] <RAOF> Ok.
[21:50] <RAOF> I shall therefore have a shower.
[21:50] <racarr> right now im building my branch with clang to figure out whyt he last test I had to refactor
[21:51] <racarr> generates internal compiler errors
[21:51] <racarr> the joy!
[21:51] <RAOF> Woot!
[21:51] <RAOF> Is it the same std::make_shared<AbstractType>() causes ICE bug?
[21:52] <racarr> in this case it was
[21:52] <racarr> mt::fake_shared(std::shared_ptr)
[21:52] <racarr> lol
[22:03] <thomi> robert_ancell: sorry for the ping earlier - we're working on getting autolanding for lightdm going, and we hit a few issues. We're slowly getting through them though
[22:04] <robert_ancell> thomi, nice, thanks!
[22:08]  * kdub wonders about hooking an android phone up to jenkins
[22:08] <kdub> and actually, i *think* the android unit tests and acceptance tests are driver-free and should be able to run on an emulator
[22:11] <thomi> kdub: Martin already did some work hooking a few phones up to jenkins
[22:11] <thomi> kdub: when he getsback from holiday I expect I'll take over that work
[22:11] <thomi> and then.... run the glmark tests on a real phone :)
[22:11] <thomi> the difficult bit (IIRC) is provisioning them in a sensible way
[22:13] <kdub> thomi, cool
[22:16] <racarr> RAOF: I am looking and I think mir_egl_native_display_is_valid is fine
[22:17] <racarr> RAOF: Were you passing it MirConnection maybe?
[22:17] <racarr> That no longer works you need mir_connection_get_egl_native_display
[22:20] <RAOF> racarr: I mean, if you replace mir_egl_mesa_display_is_valid() with mir_egl_native_display_is_valid() with no other changes in the Mesa EGL platform patch, mir_egl_native_display_is_valid will always return false.
[22:28] <racarr> RAOF: Hmm
[22:28] <racarr> RAOF: Testing now
[22:30] <racarr> It was using mclg::MesaNativeDisplayContainer::validate from mir_egl_mesa_display_is_valid
[22:30] <racarr> and mcl::EGLNativeDisplayContainer::validate from the mir_client_library.cpp impl
[22:30] <racarr> err
[22:30] <racarr> ::instance
[22:30] <racarr> ::instance is static on mcl::EGLNativeDisplayContainer only
[22:30] <racarr> what happens...;)
[22:32] <racarr> RAOF: Oh hmm its true
[22:32] <racarr> I can't understnad how it happens!
[22:33] <RAOF> Why do we have both again?
[22:34] <racarr> RAOF: Eh I guess we don't necessarily need both though it's hard to make a strong argument that mir_egl_native_display_is_valid doesn't belong either I think
[22:34] <racarr> but why doesn't it work seems more important the code path should be the same:/
[22:34] <racarr> I mean literally they are both one line functions
[22:35] <racarr> I onder if there are bits lost in casting somewhere
[22:35] <racarr> thats the only difference
[22:35] <racarr> unless something strange is happening with translation units and multiple instances of the static instance are created
[22:37] <racarr> I guess maybe it is a weird function
[22:37] <racarr> my laziness about deleting it is now ovveridden by my laziness about fixing it
[22:40] <racarr> RAOF: Removed in r590 ;)
[23:20] <robert_ancell> any C++ experts can help me with a problem I'm having with virtual methods, shared pointers and constructors?
[23:20] <robert_ancell> I have code http://paste.ubuntu.com/5693963/ and error http://paste.ubuntu.com/5693965/
[23:28] <RAOF> robert_ancell: No (co?)variance in std::shared_ptr.
[23:28] <robert_ancell> RAOF, say what?
[23:29] <racarr> There is for return types though right?
[23:29] <RAOF> robert_ancell: A std::shared_ptr<NullDMMessageHandler> is NOT a std::shared_ptr<DMMessageHandler>, even though a NullDMMessageHandler is a DMMessageHandler.
[23:30] <robert_ancell> RAOF, so this is copied from mir/src/server/frontend/socket_session.h, where it does the same sort of thing except it uses structs
[23:31] <racarr> Yeah I think in this case either the return types are covariant and it works or the copy constructor is invoked...
[23:31] <racarr> we use this pattern a bunch
[23:32] <racarr> though um...-.- I don't know why it doesn't work ;)
[23:32] <racarr> robert_ancell: -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_C_COMPILER=/usr/bin/clang
[23:32] <robert_ancell> racarr, really? It would work in clang and not gcc?
[23:32] <racarr> robert_ancell: No but it might have better errors
[23:32] <robert_ancell> It does work if I switch them to structs, but that's not clear to me why that would make a difference
[23:33]  * robert_ancell gets massive flashbacks of the last time he worked with C++ and it was super inconsistent
[23:33] <racarr> robert_ancell: I bet it would also work
[23:33]  * RAOF thought the only difference between "struct" and "class" was the default visibility?
[23:33] <racarr> with class NullDMMessageHandler : public DMMessageHandler ?
[23:34] <racarr> RAOF: The other difference is
[23:34] <racarr> private is the default base class access-specificer for classes
[23:34] <robert_ancell> racarr, with them both struct DMMessageHandler, and struct NullDMMessageHandler. Which is what is done in the frontend code
[23:34] <racarr> and public for structs
[23:34] <racarr> robert_ancell: ^ Need public inheritance is the problem I think :)
[23:34] <racarr> so either struct or explicit public inheritance
[23:35] <robert_ancell> racarr, bingo - that did it
[23:35] <robert_ancell> what is the default inheritance?
[23:36] <RAOF> private for classes.
[23:41] <racarr> public for structs
[23:59] <racarr> whoops...
[23:59] <racarr> I made a circular dependency in the server configuration XD