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