[07:14] <sennn> i hope mir not blackscreen on my APU soon...
[07:15] <sennn> issue
[07:16] <sennn> anyone?
[07:18] <sennn> fine...
[10:27] <dandrader> alan_g, finally got custom messages between qt apps and unity8 through mir_socket working :)
[10:27] <alan_g> dandrader: Great!
[12:10] <alan_g> alf_: I've had to update to track changes on devel - could you recheck before I top-approve? https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244
[12:10] <alf_> alan_g: looking
[12:12] <anpok> ricmm: ping
[12:12] <anpok> alan_g: alf_: it got larger than I thought ~3k loc
[12:13] <alan_g> anpok: what is "it"?
[12:14] <anpok> avoiding includes between subcomponents
[12:14] <anpok> for reports
[12:18] <alan_g> I imagine a lot of that is moves and renames?
[12:18] <alf_> alan_g: looks good
[12:19] <anpok> yes moved header files around..
[12:20] <alf_> anpok: alan_g: I still think that moving everything into a report(ing) component is the cleanest way to deal with this...
[12:21] <alan_g> "everything"?! Surely just the reports?
[12:21] <alan_g> 8^)
[12:22] <alf_> alan_g: :)
[12:23] <anpok> alf_: i dont disagree, but just moving lttng/ and logging/ was not enough
[12:23] <anpok> we had a lot of report related stuff cluttered in other places too
[12:23] <anpok> == should be simpler now
[12:27] <alan_g> I wouldn't expect "a lot of report related stuff cluttered in other places too" - what's that?
[13:00] <anpok> alan_g|lunch: hm probably not a lot of .. just a few report logging implementations being provided within the components itself, and accessing component internals..
[13:07] <xnox> Yo =) !
[13:07] <xnox> i've installed mirout on my device
[13:07] <xnox> and when i do "mirout" via adb shell I get
[13:07] <xnox> "Could not connect to a display server."
[13:41] <ricmm> anpok: hi
[14:05] <anpok> ricmm: hi -> look at #mir
[14:43] <sil2100> om26er: hi!
[14:43] <om26er> sil2100, hello
[15:07] <chrisccoulson> kgunn, so, I ran this in gdb, and ua_ui_display_get_native_type seems to return NULL (which I verified by setting a breakpoint on eglGetDisplay)
[15:08] <chrisccoulson> i'm just a bit unsure whether this is actually expected, seeing as apps seem to work
[15:10] <kgunn> chrisccoulson: sorry...got interrupted...
[15:11] <kgunn> you were saying "remember what we talked about yesterday? (me wanting to get a valid display handle in oxide that I can pass to chromium for creating EGL contexts)"
[15:11] <kgunn> and "so, this is what I implemented: http://paste.ubuntu.com/6885671/"
[15:13] <chrisccoulson> kgunn, sorry, xchat crashed there
[15:14] <chrisccoulson> ok, so i still get a null display handle, but now i'm not sure if this is actually the expected behaviour, seeing as things seem to work
[15:15] <chrisccoulson> kgunn, i just ran qmlscene in gdb, and set breakpoints on eglGetDisplay and eglCreateContext, both of which seem to succeed, and this is what I see: http://paste.ubuntu.com/6885692/
[15:16] <kgunn> chrisccoulson: i'll admit i'm not as familiar with the upper stack...but do i read it right that the display id in the qmlscene is null as well?
[15:17] <chrisccoulson> kgunn, that's right. we get a null handle from ua_ui_display_get_native_type(), which gets passed to eglGetDisplay and somehow magically works
[15:17] <kgunn> chrisccoulson: so...wondering...shouldn't papi be taking care of all this egl shennanigans ?
[15:18] <kgunn> (which is maybe why it works)
[15:18] <kgunn> again i'm not as familiar...
[15:21] <chrisccoulson> kgunn, papi?
[15:22] <kgunn> chrisccoulson: platform api...which in turn is talking to mir
[15:22] <chrisccoulson> aha :)
[15:23] <kgunn> chrisccoulson: so i'm just spit-balling...but wondering if maybe, you can ask for egldpy id, but in the end it kind of ignores you and just takes care of some of the binding under the hood ?
[15:24]  * kgunn starts to root around in platform-api
[15:26] <kgunn> chrisccoulson: ...right, cause ua_ui_display_get_native_type() is actually from the platform-api i/f
[15:26] <kgunn> ricmm: is it normal for an app that might query ua_ui_display_get_native_type() to get null back ?? but still operate ?
[15:29] <chrisccoulson> kgunn, the other thing - even with a valid display handle, libhybris seems to actually ignore it - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/libhybris/trusty/view/head:/hybris/egl/egl.c#L173
[15:30] <chrisccoulson> (it passes EGL_DEFAULT_DISPLAY rather than the actual handle)
[15:34] <kgunn> chrisccoulson: true...(altho you could get a egl no display return if hybris ws considers it invalid...)
[15:34] <ricmm> kgunn: so that call is pretty transparent, it translates directly to mir_connection_get_egl_native_display()
[15:34] <ricmm> so whatever is coming from there, you get
[15:35] <ricmm> which ultimately will wrap hybris' EGL
[15:36] <chrisccoulson> ok, so it seems like what I'm seeing is actually pretty normal
[15:37] <chrisccoulson> so this could be a red herring wrt my original problem
[15:42] <chrisccoulson> kgunn, ricmm, so, IIUC, MirConnection::egl_native_display() will always return EGL_DEFAULT_DISPLAY on the device?
[15:42] <kgunn> certainly appears so
[15:42] <chrisccoulson> kgunn, ok, thanks. so i have another issue then
[15:43] <chrisccoulson> there are some android specific egl bits in chromium, i wonder whether we should actually be turning these on
[15:51] <kgunn> chrisccoulson: it would depend, but quite possibly that may be required...
[15:51] <kgunn> this is on n4 right ?
[17:42] <kdub_> alan_g, with this failure: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-trusty-armhf/402/console
[17:42] <kdub_> for CI on ~alan-griffiths/mir/fix-1276565
[17:42]  * alan_g looks...
[17:43] <kdub_> did you figure out what was happening on the builder? i see something similar on one of my branches
[17:44] <alan_g> kdub: no. But I got the impression that everything was very slow yesterday
[17:45] <kdub_> alan_g, okay, thanks
[19:58] <mhall119> kgunn: are there any docs for the mir screencasting feature?
[19:58] <kgunn> mhall119: nope
[19:58] <mhall119> :(
[19:58] <mhall119> is there a way to start/stop it from the commandline?
[19:59] <mhall119> like phablet-screenshot?
[19:59] <kgunn> its not even in archive yet
[20:01] <kgunn> right now its just an api on mir for a server to hook into
[20:01] <kgunn> its not intended to be something used arbitrarily
[20:02] <kgunn> or i guess i should say "server side aware obj:
[20:02] <kgunn> so like...shell will do something for AP testing...
[20:03] <kgunn> and if you wanted apps to be able to utilize this...we'd have to talk to ricmm about how to expose that out to app world in a trusted manner
[20:05] <mhall119> kgunn: I've been tasked with automating the creation of walk-thru videos with autopilot and screen recording, would it be possible for me to use whatever you're using to accomplish that?
[20:05] <mhall119> this doesn't need to be in an app, it can be something I launch from the terminal via adb, or however else
[20:05] <kgunn> mhall119: ah...yeah...likely
[20:06] <kgunn> so, if you're wanting to do something quicker than later....you could use unity8 on desktop that would rely on mir
[20:06] <kgunn> as you'd have a mouse
[20:07] <kgunn> otherwise...not sure what visual queue you'd have for pointer
[20:07] <kgunn> unless AP has some toggle to turn on a visual?
[20:08] <kgunn> also...we've got one bug on desktop in mesa we think we've solve...whereas on android we're running into a driver issue
[20:08] <kgunn> for which we don't have code yadda yadda
[20:11] <mhall119> kgunn: what do you mean I'd have a mouse?
[20:11] <mhall119> I thought unity8+mir on desktop didn't have non-touch input devices working yet
[20:12] <kgunn> mhall119: oh no...i think its _some_
[20:12] <mhall119> my plan was to have Autopilot dump a log of events and x,y coordinate for them, then programatically over-lay some visual on the video in post-production
[20:12] <kgunn> like some specific hw bewteen certain years
[20:12] <kgunn> mhall119: oh ok...sounds cool
[20:15] <mhall119> bregma: kgunn: so will the Unity8+Mir desktop session preview still happen for 14.04, with enough input device support to actually use it?
[20:16] <bregma> mhall119, that's the aim...  I already have enough devices :)
[20:17] <bregma> it really just needs cursor-relative device support and improved out-of-box touchscreen device recognition
[20:19] <bregma> keyboard works OK at the Mir level, but there are no keyboard shortcuts in the shell
[20:20] <bregma> mouse and trackpad are a problem because there's no cursor, could be a configuration problem?
[20:24] <anpok> greyback: any clue why we would permanently recomposit everything when the launcher is displayed?
[20:24] <greyback> anpok: not off hand, lemme see what unity8 is doing..
[20:44] <greyback> anpok: well I checked in case unity8 was continually rendering with the launcher open, but no. As a result, I've no idea why compositing hasn't stopped
[20:47] <greyback> anpok: I used "QML_RENDER_TIMING=1" to find out by the way, it prints frame stats for each frame
[20:48] <anpok> ah so it does not render
[20:48] <anpok> how is the fading of the phone shell implemented?
[20:48] <anpok> hm alpha value?
[20:49] <greyback> yeah,  t draws black rectangle with alpha on top of app surface
[21:30] <bregma> so, I grabbed the latest Mir 0.1.4 source package from Ubuntu and built it in a clean pbuilder (OK), then pushed it to a PPA where it failed on every single udev test ... has anyone else seen that, and is there a workaround?
[21:31] <anpok> bregma: did you run make test?
[21:32] <bregma> I ran dput -- it's a PPA and it's a source package from Ubuntu
[21:32] <anpok> greyback: hm worst case is now three blended buffers, i.e. if you launched camera, then some app .. then it will render Cam|APP|Phone Shell
[21:32] <anpok> because camera has larger buffer..
[21:46] <anpok> bregma: it sounds like tests being run without libumockdev
[21:46] <bregma> anpok, that would mean the package is broken
[21:50] <bregma> nope mir-0.1.4 build-depends on lubumockdev-dev, and it _did_ pass the tests in a pbuilder chroot, it only fails in a PPA sbuilder
[21:54] <anpok> is a libumockdev-preload.so accessible there? maybe there is an error message comaplaining about not being able to preload the library?
[21:58] <bregma> every unit test fails with "libudev: udev_monitor_new_from_netlink_fd: error getting socket: Invalid argument"
[22:22] <greyback> anpok: sounds good to me!