[00:48] <kgunn> racarr: lol...like all the code...?
[05:06] <Mirv> kgunn: ok, and yes still trying to get all apps green
[06:43] <RAOF> Really? EventHub uses inotify to watch /dev/input to do hotplug? :(
[07:00] <tvoss> RAOF, we have a bug open to adjust that admittedly wrong behavior :)
[08:51] <RAOF> The EventHub is a big ball of spaghetti, isn't it.
[09:09] <tvoss> RAOF, it is, we need to split it up a little :) we haven't done so far to avoid too big of an investment
[09:11] <tvoss> RAOF, however, as we prepare for the scenegraph changes, we will tackle the EventHub/InputReader, too
[09:11] <tvoss> RAOF, if you want to see convoluted, special-cased code, look at InputDispatcher ;)
[09:11] <tvoss> that's real fun
[09:11] <RAOF> I'm less interested in that, because dispatching happens after libtouchpad :)
[09:13] <RAOF> Wheras EventHub is all up in libtouchpad's business.
[09:16] <tvoss> libtouchpad?
[09:17] <RAOF> https://github.com/whot/libtouchpad
[09:17] <RAOF> AKA: make touchpads not horrible.
[09:18] <tvoss> RAOF, hmmm, interesting, will have a look
[09:19] <RAOF> Not much there yet, but I plan to help Peter migrate the various bits of functionality from xf86-input-synaptics.
[09:19] <RAOF> But 8:30 says “time to stop work” :)
[09:27] <duflu> RAOF: Yes there's a problem if I reach my EOD before you :)
[10:14] <alan_g> greyback: would you check another tweak to unity-mir for me? https://code.launchpad.net/~alan-griffiths/unity-mir/make-portable-across-Mir-versions/+merge/194479
[10:44] <alan_g> greyback: (repeat in case you missed it) would you check another tweak to unity-mir for me? https://code.launchpad.net/~alan-griffiths/unity-mir/make-portable-across-Mir-versions/+merge/194479
[10:45] <greyback> alan_g: I missed the first ping. Yes I'll look now
[10:45] <alan_g> greyback: thanks
[11:13] <greyback> alan_g: approved, thanks
[11:13] <alan_g> greyback: ta
[13:51] <greyback> alf__: question for you: when a display is connected or removed, how is a new CompositingFunctor created/destroyed? Is it that the MultiThreadedCompositor is stopped and then started?
[13:51] <greyback> And then a second more general question: how is vsync respected? I don't see what blocks after a frame is ready, until vsync is done
[13:53] <alf__> greyback: 1. Yes, the MultiThreadedCompositor is currently torn down and set up from scratch
[13:56] <greyback> ok
[13:56] <alf__> greyback: 2. the blocking happens in DisplayBuffer::post_update(), which is currently called internally by the DisplayBufferCompositor since it needs to call the right overload (with or without bypass)
[13:57] <greyback> alf__: got it. Thanks!
[13:59] <alf__> greyback: yw
[14:41] <kgunn> robotfuel: hey...i'm probably gonna miss the standup (have an external call)...did you happen to file a ci feature bug for adding our demo clients ?
[14:41] <kgunn> i know we spoke a few days ago...just following up
[14:42] <robotfuel> kgunn: yes, I already have a test runner for it as well that will pass or fail a demo after running x number of seconds depending on return code or stderr
[14:43] <kgunn> robotfuel: cool...is it strictly binary for running or not ? or does it look at the performance as its pass/fail ?
[14:44] <kgunn> robotfuel: just thinking if we could look at the fps # it would help prevent things like this...https://bugs.launchpad.net/mir/+bug/1249210
[14:44] <robotfuel> kgunn: we will add performance eventually as it's printed on tests in standard out, but we need to get data, before we can pass fail based on it.
[14:45] <kgunn> robotfuel: cool....glad to know you're on it
[14:45] <kgunn> appreciate it
[15:58] <kgunn> kdub: so i thot i'd be clever and try to build mir on the device to test the integration tests
[15:58] <kgunn> sounds like a yo dawg meme
[15:58] <kgunn> kdub: so all was going ok until i got to cmake ..
[15:59] <kgunn> kdub: then it complains about the boost libs
[16:00] <kgunn> kdub: i was now going to try to install them...but just wondering why that's not taken care of through all the install steps (devscripts, build-essential etc)
[16:03] <kdub> kgunn, i think there is a tool in devscripts for that... i usually use pbuilder-satisfydepends though
[16:04] <kdub> dpkg-genbuilddeps
[16:04] <kgunn> kdub: hmmm...i'm doing apt-get install libboost-dev-all
[16:05] <kdub> that should work too
[16:05] <kgunn> yeah...more than 1 way to skin a cat
[16:34] <kgunn> kdub: just to make sure (while i wait on the world to download)...if i simply say "YES" in the rules file for integration test, they should run as part of the build correct?
[16:36] <kdub> i believe so, but its not something i've tried recently
[16:37] <greyback> Hey, am I reading this wrong: http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/include/platform/mir/graphics/display.h <- does create_gl_context() create a GL context which spans all physical displays?
[16:37] <kdub> greyback, i think thats how it works
[16:38] <greyback> kdub: hmm , I was expecting a gl context per framebuffer
[16:38] <kdub> alf__, would object if i'm wrong though :)
[16:39] <kgunn> greyback: fwiw, i've actually seen both...context per & 1 for many
[16:40] <greyback> kgunn: ok. I know both do-able, but I thought i heard someone mention Mir did context per fb. Was just checking
[16:40] <greyback> think 1 context per many makes my life easier
[16:40] <kgunn> still a good question...maybe alf__ will enlighten us
[16:42] <kgunn> i really really heart verizon and their damn wifi route today :-|
[17:14] <alf__> greyback: Each DisplayBuffer gets its own GL context. However, all contexts, including the ones returned by create_gl_context(), are created sharing a common base share context, so they can all access shared resources (like textures).
[17:15] <greyback> alf__: ah cool
[17:15] <greyback> I didn't know that could be done
[17:21] <alf__> greyback: for a caveat about multithreading with shared contexts see the comment in src/server/compositor/gl_renderer_factory.cpp
[17:22] <greyback> alf__: understood
[17:23]  * greyback eod
[19:25] <racarr> Had a full system hang from mir_demo_server_shell :(
[20:06] <doneill_> sam113101: we should've been talking Mir over here, hah!
[20:07] <sam113101> doneill_: yeah
[20:07] <sam113101> doneill_: do you work on mir?
[20:07] <doneill_> Anyway, I suspect you'll bump into Unity-isms in Mir when you start implementing. I'd suggest poking around the Unity8 code and borrow gfx/input initialization from there.
[20:08] <doneill_> No, I work on Ubuntu Touch apps, but at this stage it requires being at least moderately familiar with Mir and how it works.
[20:09] <sam113101> ok
[20:09] <doneill_> I'm not in a very different position than you, except instead of weighing the options I'm using both Mir and Wayland.
[20:18] <robotfuel> racarr: ping
[20:58] <racarr> robotfuel: pong
[20:58] <robotfuel> racarr: I asked the question in #mir
[20:59] <robotfuel> racarr: :D
[20:59] <racarr> I see
[20:59] <racarr> I dontknow about the bug but I have seen it before(just haven't investigate yet)
[20:59] <racarr> I will check it out once I finish 1249210
[21:19] <racarr> I basically understand what is happeningwith 1249210 and have the fix butI dont quite understand
[21:19] <racarr> why it results in halfFPS when bypassed
[21:41] <racarr> robotfuel: Investigating now as soon as I get a clean build dir:)
[22:06] <kgunn> updatin' to trusty....