=== smspilla2 is now known as smspillaz
[05:55] <arsson> sooo how do i get mir working?
[05:59] <arsson> now i get only black screen when running mir
[08:12] <alf_> arsson: http://unity.ubuntu.com/mir/
[08:21] <arsson> already done that
[08:23] <arsson> i have nvidia card geforce gt420 and nouveau drivers. maybe it's that.
[08:38] <alf_> arsson: could be... do you get a black screen when running a sample client, or are you trying to run an X session over mir?
[08:43] <arsson> i go to lightdm and press ctrl+alt+f1 login and run mir
[08:43] <arsson> i don't know how to run any demos
[08:45] <arsson> but if i run mir in terminal it says like this  ERROR: /build/buildd/mir-0.0.2bzr543raring0/src/server/graphics/gbm/gbm_display_helpers.cpp(278): Throw in function void mir::graphics::gbm::helpers::EGLHelper::setup_internal(const mir::graphics::gbm::helpers::GBMHelper&, bool)
[08:45] <arsson> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
[08:45] <arsson> std::exception::what: Failed to choose ARGB EGL config
[08:47] <arsson> n i don't understand any of that jiberish
[09:28] <arsson> alf_ any idea?
[09:31] <alf_> arsson: sounds like a nouveau issue
[09:32] <alf_> arsson: I haven't had this on either radeon or intel
[09:34] <alf_> arsson: can you build https://github.com/robclark/kmscube and see if that works in a VT?
[09:36] <arsson> http://www.phoronix.com/scan.php?page=news_item&px=MTMxNzg  Right now Mir is said to only work with the Intel and Radeon open-source graphics drivers, but evidently is not yet working for Nouveau. In terms of binary drivers supporting Mir, Canonical claims to be pressuring AMD and NVIDIA to support it, but that will likely be quite some time until those blobs make the changes to fully support EGL and other requirements.
[09:41] <arsson> i really don't how to succesfully build anything if there is no good instructions and i'm finnish so english is a bit hard for me.
[09:54] <arsson> and when i install close source drivers unity disappears and other desktops too. only wallpaper is visible
=== hikiko is now known as hikiko_lunch
=== hikiko_lunch is now known as hikiko
[13:40] <hikiko> hello
[13:42] <hikiko> I was trying to write an example program using gbm to get sure that it can be used under X and I was getting compile errors from libdrm (drm.h) I've done some modifications (added some parts of the freebsd drm.h that were missing) and now it works but I don't know where to submit my patch... any ideas?
[13:51] <alf_> hikiko: can you pastebin the diff?
[13:52] <hikiko> alf_, i just saw that the latest version has a fix
[13:53] <hikiko> in drm.h you need to use an #if defined(_cplusplus) in drm_buf_map because void *virtual; will give you a compile error
[13:54] <hikiko> #if defined(__cplusplus)
[13:54] <hikiko> 	void __user *c_virtual;
[13:54] <hikiko> #else
[13:54] <hikiko> 	void __user *virtual;		/**< Mmap'd area in user-virtual */
[13:54] <hikiko> #endif
[13:54] <hikiko> something like that
[13:54] <hikiko> but latest libdrm here: http://dri.freedesktop.org/libdrm/
[13:54] <hikiko> has the macro
[13:56] <hikiko> which version of libdrm you use?
[13:57] <hikiko> I wonder if it is safe to compile the 2.4.43
=== francisco is now known as Guest14513
[14:06] <hikiko> http://paste.ubuntu.com/5667425/ alf_ that's the error without the change (using the installed drm.h)
[14:17] <alf_> hikiko: We are using whatever comes with raring devel (currently 2.4.43)
[14:17] <hikiko> :s
[14:18] <hikiko> I should have the same version then :s
[14:23] <alf_> hikiko: I wonder why we don't get a build error for that in mir...
[14:25] <hikiko> maybe because mir includes the xf86drm.h
[14:26] <hikiko> ah no it includes drm.h as well so we should get the error
[14:26] <hikiko> but we don't :s
[14:28] <hikiko> the most strange is that if I do apt-get source libdrm-dev I get the latest fixed drm.h but my /usr/include/drm/drm.h is different
[14:35] <hikiko> :/ it seems that there are 2 drm.h :p my mistake... drm/drm.h has the bug and libdrm/drm.h is the correct from libdrm-dev :p i was using the system's drm.h
[14:46] <hikiko> ok alf_ my mistake... there are 2 drm versions but mir uses pkg-config and gets the libdrm which doesn't have the bug :) i used pkg-config in my makefile and now my test uses the non-buggy header, sorry :)
[15:03] <alf_> status: Finished iteration-0 of vt-switching, have hacky working code locally... up next proper design for this
[15:05] <kdub> status, finishing up the hwc 1.1 branch and starting work on the framebuffer native window for android (deprecating the code we're using now)
[15:13] <kdub> alf_, what if i rename mga::FBFactory to mga::DisplayFactory and rename mga::DisplayFactory to mga::DisplayAllocator
[15:15] <alf_> kdub: The confusion comes from "Display", so I am not sure if this is going to be any clearer
[15:16] <alf_> kdub: Is there a different way to express (HWC|Android)Display?
[15:16] <kdub> those classes implement mg::Display though
[15:17] <alf_> kdub: ahh, you are right
[15:18] <kdub> i do agree though that the mga::FBFactory just uses "FB" because its a word that just sort-of fits there
[15:20] <alf_> kdub: in light of this, DisplayAllocator seems much better
[15:20] <alf_> kdub: although, I guess its only purpose is for testing? (e.g. your comment in the MP)
[15:20] <kdub> cool
[15:20]  * kdub goes to change it
[15:46] <racarr> Morning
[15:46] <racarr> status: *squitns at monitor while holding one hand over light*
[15:47] <racarr> actual status: Iterating on inprocess-egl soon, reviews, etc.
[15:49] <kgunn> racarr: homeless guy was wrong...i heard Easter happened yesterday
[15:50] <ogra_> depending on your country it is also happening today :)
[15:50] <ogra_> (i.e. germany has  easter monday ... national holiday ...)
[15:51] <smspillaz> ditto australia
[15:52] <racarr> kgunn: I'll let him know ;
[15:52] <racarr> )
[15:55] <kgunn> racarr: i saw kdub/alang gave a pretty exhaustive review...think this will be the week for inprocess egl to land once those are addressed?
[15:58] <kdub> alf_, name changes pushed
[15:58] <alf_> kdub: ok
[15:59] <racarr> kgunn: Should be :)
[16:00] <kgunn> racarr: awesome!
[16:01] <kgunn> racarr: so do you have (or plan to have a test) that runs 2 clients at once...one with its own buffs vs mir provided? (just thinking of a nasty test)
[16:02] <racarr> kgunn: With it's own buffers?
[16:03] <racarr> What kind of client do you mean
[16:03] <kgunn> was thinking shell-like
[16:04] <racarr> they get mir provided buffers just via
[16:04] <racarr> inprocess communication
[16:04] <racarr> hmm testing 1 in process and 1 out of process though...no...it has been tested but we don't really have any
[16:04] <racarr> integration tests that call in Mesa as well
[16:43] <racarr> ICE's...ugggh
[17:03] <racarr> iterated on enable-inprocess-egl
[17:03] <racarr> making tea then back to receive-input-in-clients
[17:09] <kgunn> racarr: is it worth it to add such a in/out of process simultaneous test...guess, with qt everything should be in process...so, not that interesting
[17:17]  * kdub just discovered you can link blueprints to branches...
[17:17] <kdub> kgunn, is that something that's helpful to do?
[17:19] <kgunn> kdub: i like linking stuff....i think more helpful than not
[17:39] <racarr> Let it grow is the best song for test driven refactoring: https://www.youtube.com/watch?v=hxUD2IX1UfM
[17:39] <racarr> (just to settle that question ;))
[17:53] <racarr> (https://www.youtube.com/watch?v=8KbW6UWFrCk of course being the second best song for refactoring)
=== racarr is now known as racarr|lunch
[18:31] <racarr|lunch> Back soon!
=== kdub is now known as kdub^lunch
=== racarr|lunch is now known as racarr
=== kdub^lunch is now known as kdub
[21:04] <racarr> Cleaned up and iterated on receive-input-in-client and enable-inprocess-egl did some reviews and doxygen and blabla
[21:05] <racarr> Guess I am going to work on a non hacked together branch of Qtubuntu with input that works on Mir :)
=== bschaefer_ is now known as bschaefer
[21:10] <racarr> kdub: Is      bzr branch lp:~kdub/aal+/ubuntu-platform-mir  the most current version of ~kdub/ubuntu-platform-mir
[21:10] <racarr> I need ubuntu-platform-mir now XD so I was going to do it
[21:10] <racarr> and was trying to find wher ethe launchpad branches moved and found this
[21:10] <kdub> racarr, yeah, thats how I switch out surfaceflinger from the ubuntu touch demos
[21:10] <racarr> Ok great!
[21:10] <kdub> i won't say its perfect though :)
[21:11] <racarr> I have a likely even more hacked together version
[21:11] <racarr> for running qtubuntu to test input
[21:11] <racarr> so I will combine them and make something
[21:24] <kdub> racarr, cool. the branch you reviewed there (thanks btw) should run on nexus 4 with no screen problems
[21:28] <racarr> :D
[21:28] <racarr> I wish I could test it...nexus 4 had an incident with the washing machine
[21:28] <racarr> down to nexus 7 atm
[21:37] <thomi> Hey everyone
[21:37] <robert_ancell> thomi, hello
[21:40] <thomi> building glmark for mir....
[21:40]  * thomi crosses fingers
[22:19] <RAOF> Woot
[22:19] <thomi> ugh
[22:21] <thomi> now I'm super-confused, perhaps someone can un-confuse me a bit...
[22:21] <thomi> the branch alf_ mentioned in his email (lp:~mir-team/glmark2/mir) doesn't contain the mir-* flavours he mentioned.
[22:21] <thomi> but lp:glmark2 does.
[22:22] <thomi> yet his email seems to indicate that active development is happening in the mir-team branch.... and it doesn't merge cleanly with glmark2 trunk either
[22:22] <thomi> so.... which branch am I supposed to be building?
[22:41] <poseidon> http://unity.ubuntu.com/mir/md__h_a_c_k_i_n_g.html says mir won't work on systems with nvidia cards (under running mir), is this correct?
[22:53] <RAOF> poseidon: No, that's incorrect, although you do need to be using the (default) nouveau drivers. *XMir* won't currently work on nvidia systems because we haven't patched nouveau for it yet, but XMir's not currently working anyway :)
[22:53] <RAOF> thomi: WHere's lp:glmark2?
[22:53] <RAOF> Oh, whoops. Missed the '2'
[22:54] <thomi> oh good, that makes sense then :)
[22:54] <thomi> my current strategy is to try and build lp:glmark2 and ignore the other branch
[22:54] <RAOF> Looks like alf_'s Mir work is already merged into lp:glmark2
[22:55] <Darxus> Yup.
[22:55] <thomi> which is odd, since that was merged *before* he sent the email on mir-devel
[22:56] <thomi> ahh well
[22:56] <thomi> I'll just ignore it, and build trunk
[22:57] <Darxus> RAOF: Are you doing some of the work on xmir?  Do you think that's likely to be a useful reference for finishing the xwayland stuff?
[22:58] <RAOF> Darxus: It's in the same problem-domain as XWayland, yes. At the moment we're targetting a full root-window-full server, though, so I don't think we're (yet) hitting the most difficult bits.
[22:59] <RAOF> Although we might run into and solve system-compository problems before xwayland.
[22:59] <Darxus> That makes sense, thanks.
=== thomi is now known as thomi|lunch
=== Darxus_ is now known as Darxus