=== chihchun_afk is now known as chihchun [00:48] racarr: lol...like all the code...? === chihchun is now known as chihchun_afk [05:06] kgunn: ok, and yes still trying to get all apps green === chihchun_afk is now known as chihchun [06:43] Really? EventHub uses inotify to watch /dev/input to do hotplug? :( [07:00] RAOF, we have a bug open to adjust that admittedly wrong behavior :) [08:51] The EventHub is a big ball of spaghetti, isn't it. [09:09] 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] RAOF, however, as we prepare for the scenegraph changes, we will tackle the EventHub/InputReader, too [09:11] RAOF, if you want to see convoluted, special-cased code, look at InputDispatcher ;) [09:11] that's real fun [09:11] I'm less interested in that, because dispatching happens after libtouchpad :) [09:13] Wheras EventHub is all up in libtouchpad's business. [09:16] libtouchpad? [09:17] https://github.com/whot/libtouchpad [09:17] AKA: make touchpads not horrible. [09:18] RAOF, hmmm, interesting, will have a look [09:19] Not much there yet, but I plan to help Peter migrate the various bits of functionality from xf86-input-synaptics. [09:19] But 8:30 says “time to stop work” :) [09:27] RAOF: Yes there's a problem if I reach my EOD before you :) [10:14] 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] 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] alan_g: I missed the first ping. Yes I'll look now [10:45] greyback: thanks [11:13] alan_g: approved, thanks [11:13] greyback: ta === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === chihchun is now known as chihchun_afk === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [13:51] 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] 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] greyback: 1. Yes, the MultiThreadedCompositor is currently torn down and set up from scratch [13:56] ok [13:56] 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] alf__: got it. Thanks! [13:59] greyback: yw [14:41] 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] i know we spoke a few days ago...just following up [14:42] 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] robotfuel: cool...is it strictly binary for running or not ? or does it look at the performance as its pass/fail ? [14:44] 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] Ubuntu bug 1249210 in Mir "Mir client frame rate regression in r1196" [Critical,Triaged] [14:44] 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] robotfuel: cool....glad to know you're on it [14:45] appreciate it === dandrader is now known as dandrader|lunch === alan_g is now known as alan_g|afk [15:58] kdub: so i thot i'd be clever and try to build mir on the device to test the integration tests [15:58] sounds like a yo dawg meme [15:58] kdub: so all was going ok until i got to cmake .. [15:59] kdub: then it complains about the boost libs [16:00] 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] kgunn, i think there is a tool in devscripts for that... i usually use pbuilder-satisfydepends though === dandrader|lunch is now known as dandrader === alan_g|afk is now known as alan_g [16:04] dpkg-genbuilddeps [16:04] kdub: hmmm...i'm doing apt-get install libboost-dev-all [16:05] that should work too [16:05] yeah...more than 1 way to skin a cat [16:34] 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] i believe so, but its not something i've tried recently [16:37] 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] greyback, i think thats how it works [16:38] kdub: hmm , I was expecting a gl context per framebuffer [16:38] alf__, would object if i'm wrong though :) [16:39] greyback: fwiw, i've actually seen both...context per & 1 for many [16:40] kgunn: ok. I know both do-able, but I thought i heard someone mention Mir did context per fb. Was just checking [16:40] think 1 context per many makes my life easier [16:40] still a good question...maybe alf__ will enlighten us [16:42] i really really heart verizon and their damn wifi route today :-| [17:14] 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] alf__: ah cool [17:15] I didn't know that could be done [17:21] greyback: for a caveat about multithreading with shared contexts see the comment in src/server/compositor/gl_renderer_factory.cpp [17:22] alf__: understood [17:23] * greyback eod === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === alan_g is now known as alan_g|EOW === dandrader is now known as dandrader|bbl [19:25] Had a full system hang from mir_demo_server_shell :( === dandrader|bbl is now known as dandrader [20:06] sam113101: we should've been talking Mir over here, hah! [20:07] doneill_: yeah [20:07] doneill_: do you work on mir? [20:07] 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] 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] ok [20:09] 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] racarr: ping [20:58] robotfuel: pong [20:58] racarr: I asked the question in #mir [20:59] racarr: :D [20:59] I see [20:59] I dontknow about the bug but I have seen it before(just haven't investigate yet) [20:59] I will check it out once I finish 1249210 [21:19] I basically understand what is happeningwith 1249210 and have the fix butI dont quite understand [21:19] why it results in halfFPS when bypassed [21:41] robotfuel: Investigating now as soon as I get a clean build dir:) [22:06] updatin' to trusty....