| === chihchun_afk is now known as chihchun | ||
| kgunn | racarr: lol...like all the code...? | 00:48 |
|---|---|---|
| === chihchun is now known as chihchun_afk | ||
| Mirv | kgunn: ok, and yes still trying to get all apps green | 05:06 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | Really? EventHub uses inotify to watch /dev/input to do hotplug? :( | 06:43 |
| tvoss | RAOF, we have a bug open to adjust that admittedly wrong behavior :) | 07:00 |
| RAOF | The EventHub is a big ball of spaghetti, isn't it. | 08:51 |
| 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:09 |
| 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:11 |
| RAOF | Wheras EventHub is all up in libtouchpad's business. | 09:13 |
| tvoss | libtouchpad? | 09:16 |
| RAOF | https://github.com/whot/libtouchpad | 09:17 |
| RAOF | AKA: make touchpads not horrible. | 09:17 |
| tvoss | RAOF, hmmm, interesting, will have a look | 09:18 |
| 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:19 |
| duflu | RAOF: Yes there's a problem if I reach my EOD before you :) | 09:27 |
| 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:14 |
| 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:44 |
| greyback | alan_g: I missed the first ping. Yes I'll look now | 10:45 |
| alan_g | greyback: thanks | 10:45 |
| greyback | alan_g: approved, thanks | 11:13 |
| alan_g | greyback: ta | 11:13 |
| === 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 | ||
| 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:51 |
| alf__ | greyback: 1. Yes, the MultiThreadedCompositor is currently torn down and set up from scratch | 13:53 |
| 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:56 |
| greyback | alf__: got it. Thanks! | 13:57 |
| alf__ | greyback: yw | 13:59 |
| 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:41 |
| 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:42 |
| kgunn | robotfuel: cool...is it strictly binary for running or not ? or does it look at the performance as its pass/fail ? | 14:43 |
| 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 |
| ubot5 | Ubuntu bug 1249210 in Mir "Mir client frame rate regression in r1196" [Critical,Triaged] | 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:44 |
| kgunn | robotfuel: cool....glad to know you're on it | 14:45 |
| kgunn | appreciate it | 14:45 |
| === dandrader is now known as dandrader|lunch | ||
| === alan_g is now known as alan_g|afk | ||
| 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:58 |
| kgunn | kdub: then it complains about the boost libs | 15:59 |
| 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:00 |
| kdub | kgunn, i think there is a tool in devscripts for that... i usually use pbuilder-satisfydepends though | 16:03 |
| === dandrader|lunch is now known as dandrader | ||
| === alan_g|afk is now known as alan_g | ||
| kdub | dpkg-genbuilddeps | 16:04 |
| kgunn | kdub: hmmm...i'm doing apt-get install libboost-dev-all | 16:04 |
| kdub | that should work too | 16:05 |
| kgunn | yeah...more than 1 way to skin a cat | 16:05 |
| 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:34 |
| kdub | i believe so, but its not something i've tried recently | 16:36 |
| 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:37 |
| greyback | kdub: hmm , I was expecting a gl context per framebuffer | 16:38 |
| kdub | alf__, would object if i'm wrong though :) | 16:38 |
| kgunn | greyback: fwiw, i've actually seen both...context per & 1 for many | 16:39 |
| 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:40 |
| kgunn | i really really heart verizon and their damn wifi route today :-| | 16:42 |
| 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:14 |
| greyback | alf__: ah cool | 17:15 |
| greyback | I didn't know that could be done | 17:15 |
| alf__ | greyback: for a caveat about multithreading with shared contexts see the comment in src/server/compositor/gl_renderer_factory.cpp | 17:21 |
| greyback | alf__: understood | 17:22 |
| * greyback eod | 17:23 | |
| === 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 | ||
| racarr | Had a full system hang from mir_demo_server_shell :( | 19:25 |
| === dandrader|bbl is now known as dandrader | ||
| doneill_ | sam113101: we should've been talking Mir over here, hah! | 20:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| robotfuel | racarr: ping | 20:18 |
| racarr | robotfuel: pong | 20:58 |
| robotfuel | racarr: I asked the question in #mir | 20:58 |
| 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 | 20:59 |
| 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:19 |
| racarr | robotfuel: Investigating now as soon as I get a clean build dir:) | 21:41 |
| kgunn | updatin' to trusty.... | 22:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!