| robert_ancell | kgunn, how did it go? | 00:07 |
|---|---|---|
| kgunn | robert_ancell: thanks again...vt mir demo working | 00:11 |
| robert_ancell | \o/ | 00:11 |
| kgunn | altho boot was still wonky | 00:11 |
| kgunn | let me check logs | 00:11 |
| kgunn | ok, symptom first...it hung first time in same way, striking keys like mad 2nd time...got it to boot | 00:14 |
| kgunn | so still jumped to vt8 | 00:14 |
| kgunn | but here's the usc log -> https://pastebin.canonical.com/93337/ | 00:15 |
| kgunn | at least it was quite diff this time | 00:15 |
| kgunn | gotta run...getting yelled at | 00:16 |
| RAOF | Ok, what the whatting what? | 01:16 |
| RAOF | duflu: Do you have any experience interposing libc symbols? Particularly: I want bin/unit-tests to wrap open() | 01:19 |
| duflu | RAOF: Yes, sadly | 01:20 |
| RAOF | Or, even more particularly, I want: | 01:20 |
| RAOF | // If directly opening the DRM device is good enough for X it's good enough for us! | 01:20 |
| RAOF | tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC); | 01:20 |
| duflu | RAOF: Your new symbols need to be in a new SO | 01:20 |
| RAOF | to go through the mock. | 01:20 |
| duflu | RAOF: They need to be in a new SO, _and_ LD_PRELOAD'd if they're to override libc | 01:21 |
| RAOF | duflu: Really? Urgh. Looking at the LD_DEBUG=binding output, I see that libudev is binding open() to bin/unit-tests, and my open64 wrapper is getting called (by pthreads, apparently), but libmirserver.so.0 never binds open(). | 01:22 |
| duflu | Cos normally libc gets in before all your SOs | 01:22 |
| duflu | RAOF: The SO will use its own, but if you want process-wide wrapping then LD_PRELOAD | 01:22 |
| RAOF | I don't suppose -Wl,-z interpose would make this less painful? | 01:22 |
| duflu | Hmm, could do | 01:23 |
| duflu | Not sure | 01:23 |
| duflu | RAOF: If it's not loaded early, properly, then you'll get some libraries using your version and some using libc's, which is bad | 01:23 |
| RAOF | Heh | 01:24 |
| duflu | And don't forget to call the real open(), which you will find by dlsym(RTLD_NEXT, "open") | 01:25 |
| RAOF | Yup. | 01:25 |
| RAOF | My wrapper works fine (as demonstrated by open64). | 01:25 |
| duflu | RAOF: We're lucky it's easy on Linux. When I did it in Windows I had to edit the binary instructions by hand at the start of each function :) | 01:28 |
| RAOF | That sounds like much more fun! | 01:28 |
| duflu | Which is not so easy on x86 because instructions vary in size. So you have to interpret them first. | 01:28 |
| RAOF | Couldn't you have just padded all your functions with enough noops to make that easier? | 01:31 |
| RAOF | Also: boo. -z interpose is not teh win. | 01:32 |
| RAOF | ... | 01:47 |
| RAOF | !!! | 01:47 |
| duflu | RAOF: Not my functions. They were Microsoft's :) | 01:51 |
| RAOF | So, my open() wrapper works, as evidenced by LD_PRELOADING it and gdb spitting out the debug spew I've made it emit. | 01:54 |
| RAOF | But, for some reason, tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC); is *not* wrapped. | 01:54 |
| RAOF | Oh. | 01:58 |
| RAOF | That's not fair. | 01:58 |
| RAOF | It's because that line is never called, because of an incorrect ‘!’ further up the function. | 01:59 |
| nall | trying to make this work on VMWare still | 03:47 |
| nall | mir_demo_client_egltriangle ends on creating a shared ptr for GBMClientBufferFactory and then the server starts executing | 03:48 |
| RAOF | nall: It's not going to work in vmware at the moment; we require dma-buf support from the kms driver, and vmware does not have that support. | 03:48 |
| nall | K,gotcha. Thanks | 03:49 |
| RAOF | We do *want* to support vmware, and a fallback non-accelerated case if possible. | 03:50 |
| RAOF | If you want to write code, there's code to be written :) | 03:50 |
| nall | Yeah, I'm just trying to figure out where to start. | 03:51 |
| nall | I'd love to run Ubuntu natively on my machine but it's a company computer and the only one I've got. | 03:51 |
| tvoss | good morning :9 | 04:06 |
| duflu | tvoss: Go back to bed you silly man | 04:08 |
| duflu | And good morning | 04:08 |
| tvoss | duflu, :) all good, today is my early-bird day :) | 04:09 |
| duflu | tvoss: Were you by any chance profiling Mir with 3 clients/surfaces? (like multiwin?) | 04:14 |
| tvoss | duflu, nope, I started single client | 04:15 |
| duflu | tvoss: Which one? | 04:15 |
| tvoss | duflu, I think not even an egl one | 04:15 |
| duflu | tvoss: Multiwin would create 3 surfaces, hence 18% I guess | 04:15 |
| tvoss | duflu, ack | 04:15 |
| tvoss | duflu, the shell/mobile guys were quite happy to hear about cpu optimizations, too | 04:16 |
| duflu | Though mathematically that does not scale accurately | 04:16 |
| tvoss | duflu, yup :) | 04:16 |
| duflu | tvoss: Yeah it's quite useful. Re-proposing just now | 04:16 |
| tvoss | duflu, did my comment make sense? | 04:16 |
| duflu | tvoss: Yes I added refs | 04:17 |
| tvoss | duflu, great | 04:18 |
| duflu | As usual, spent more time figuring out the gmock errors than making the change | 04:18 |
| tvoss | duflu, for the glclear: How about having an interface ScreenClear that is given to the renderer? We could add a null implementation | 04:19 |
| tvoss | oops, we made it slashdot :) | 04:19 |
| duflu | tvoss: Yes you got slashdotted | 04:19 |
| duflu | tvoss: Not sure which class, but the shell should be allowed to override the clear with anything | 04:19 |
| duflu | tvoss: But then that may become generalized as I figure out a framework for transitions and animations (my main task) | 04:20 |
| tvoss | duflu, ack, I just want to get rid of the glclear in a sane way on a short timescale | 04:21 |
| duflu | tvoss: https://code.launchpad.net/~thomas-voss/mir/wait-for-vt-to-become-active-before-setting-mode/+merge/171099/comments/381497 | 04:21 |
| tvoss | duflu, not entirely sure, I was thinking about a test case, but hard to come up with one | 04:22 |
| duflu | tvoss: There is no sane alternative to glClear until the shell renders a background of its own. And even then there's no benefit cos the wallpaper still takes up server CPU time | 04:23 |
| duflu | Also, I think it was much less than 19% yesterday | 04:24 |
| robert_ancell | RAOF, where is the debian branch for the mesa build? | 04:24 |
| RAOF | robert_ancell: In the ppa-somethingorother branch of github. | 04:24 |
| tvoss | duflu, fair, but do we really need to clear in the mobile case? the shell will fill the entire display anyways | 04:25 |
| tvoss | robert_ancell, RAOF good morning :) | 04:25 |
| RAOF | tvoss: Good morning. | 04:26 |
| robert_ancell | tvoss, very early morning to you | 04:26 |
| tvoss | robert_ancell, yup, my early bird day such that I can hug you guys :) | 04:26 |
| RAOF | tvoss: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 is ready to roll, and should help us understand where sabdfl's laptop is failing | 04:26 |
| tvoss | RAOF, great, let me give it a review | 04:27 |
| tvoss | RAOF, sabdfl was hit by an Input/Output error while setting the mode on the vt, which made me look into the X code for setting up shared vt's -> VT_WAITACTIVE | 04:27 |
| tvoss | RAOF, fails CI on amd64 | 04:28 |
| RAOF | tvoss: Ah, it's just finished then. | 04:28 |
| duflu | tvoss: The switching animation on mobile still shows black background, briefly, no? | 04:29 |
| duflu | As the old surface moves away, it no longer fills the screen | 04:30 |
| tvoss | duflu, nope :) that's faked, the shell always paints completely on top and just moves a screenshot of the surface around | 04:30 |
| duflu | Hence you need a glClear before that | 04:30 |
| duflu | tvoss: I mean when it's done properly. You still need a clear | 04:30 |
| duflu | Most frames... but not all | 04:30 |
| tvoss | duflu, +1 :9 | 04:30 |
| duflu | I am trying to avoid any nasty occlusion calculations like compiz does | 04:31 |
| duflu | For as long as possible | 04:31 |
| duflu | But we'll need it for basic fullscreen testing | 04:31 |
| RAOF | tvoss: Boo. That doesn't happen locally, of course. | 04:32 |
| tvoss | RAOF, a quick one at first glance: in class UdevHelper: mind making the ctx pointer private? or class -> struct if you only want value-semantics? | 04:33 |
| RAOF | It's a failure to interpose the open() wrapper, which I *thought* I could get away with but it looks like duflu is annoyingly correct | 04:33 |
| RAOF | ☺ | 04:33 |
| tvoss | robert_ancell, welcome back :) | 04:33 |
| robert_ancell | session crash :( | 04:33 |
| RAOF | tvoss: Sure. I | 04:33 |
| duflu | LD_PRELOAD FTW | 04:34 |
| RAOF | tvoss: As the comment mentions, it's going to want to grow into a fully-functional libudev wrapper. | 04:34 |
| RAOF | duflu: On *my* system LD_PRELOAD is unnecessary :( | 04:34 |
| RAOF | Which is going to make testing the fix rather annoying. | 04:35 |
| tvoss | RAOF, fair, but just make the class a struct then :) | 04:35 |
| RAOF | tvoss: Ok. | 04:35 |
| tvoss | hmmm, how can we check if the kernel supports vt's at runtime? apart from randomly opening the actual vt? | 04:39 |
| robert_ancell | tvoss, I have wondered that myself | 04:39 |
| tvoss_ | back :) | 04:41 |
| * tvoss_ notes https://bugs.launchpad.net/mir/+bug/1194210 | 04:44 | |
| ubot5 | Launchpad bug 1194210 in Mir "XMir hang during google hangout on intel sandybridge" [Undecided,Incomplete] | 04:44 |
| tvoss_ | RAOF, but I had those weird hangs w/o xmir, too | 04:44 |
| tvoss_ | mhall119, ping | 04:44 |
| tvoss_ | duflu, take it with a grain of salt: but why not leave away the const-qualifier on the transformation and get rid of the mutables? :) | 04:47 |
| tvoss_ | I see your intention and it's a nice idea, but three members requiring mutable indicates that const might not be appropriate :) | 04:47 |
| tvoss_ | duflu, apart from that, I'm fine | 04:49 |
| duflu | tvoss_: I would prefer all read-only "getters" be const, regardless of the mutables required | 04:50 |
| duflu | If they're not const then that creates problems for const callers | 04:51 |
| tvoss_ | duflu, fair | 04:51 |
| mhall119 | tvoss_: pong | 04:52 |
| === alf is now known as alf_ | ||
| tvoss_ | mhall119, for your question what XMir: a vanilla Xorg which knows about Mir, credits to RAOF, here is the diffstat: | 04:53 |
| tvoss_ | <RAOF> ChangeLog |121618 ++++++++++++++++++++++++++++++++++++ | 04:53 |
| tvoss_ | <RAOF> configure.ac | 11 | 04:53 |
| tvoss_ | <RAOF> hw/xfree86/Makefile.am | 9 | 04:53 |
| tvoss_ | <RAOF> hw/xfree86/common/xf86Bus.c | 2 | 04:53 |
| tvoss_ | <RAOF> hw/xfree86/common/xf86Config.c | 12 | 04:53 |
| tvoss_ | <RAOF> hw/xfree86/common/xf86Globals.c | 3 | 04:53 |
| tvoss_ | <RAOF> hw/xfree86/common/xf86Helper.c | 9 | 04:53 |
| tvoss_ | <RAOF> hw/xfree86/common/xf86Init.c | 55 | 04:53 |
| tvoss_ | <RAOF> hw/xfree86/common/xf86Priv.h | 3 | 04:54 |
| tvoss_ | <RAOF> hw/xfree86/xmir/Makefile.am | 26 | 04:54 |
| tvoss_ | <RAOF> hw/xfree86/xmir/xmir-output.c | 225 | 04:54 |
| tvoss_ | <RAOF> hw/xfree86/xmir/xmir-private.h | 83 | 04:54 |
| mhall119 | probably should have pastebin'd that | 04:54 |
| RAOF | Ignore the ChangeLog addition, that's spurious :) | 04:55 |
| tvoss_ | mhall119, probably, it's before third coffee here, don't expect me to be that clever | 04:55 |
| tvoss_ | RAOF, mind pastebinning the diff-stat, then we can link it on G+, too | 04:55 |
| mhall119 | it's almost 1am here, so I won't likely remember this in the morning anyway :) | 04:55 |
| tvoss_ | mhall119, \o/ | 04:55 |
| * tvoss_ tries a sudo apt-get install kubuntu-desktop | 04:56 | |
| RAOF | tvoss_: http://paste.ubuntu.com/5797514/ enjoy. | 04:56 |
| tvoss_ | RAOF, thx | 04:56 |
| RAOF | tvoss_: Oh, any advance on the client-focus-notification thingies? | 04:58 |
| tvoss_ | RAOF, nope, you just bumped its priority :) | 04:59 |
| RAOF | I would rather like to be able to switch sessions without having all input go to both :) | 04:59 |
| tvoss_ | RAOF, that's a very sane requirement :) | 05:00 |
| tvoss_ | RAOF, robert_ancell mind having a final look here and top-approve? https://code.launchpad.net/~vanvugt/mir/fix-1193020 | 05:07 |
| robert_ancell | tvoss_, duflu, approved | 05:10 |
| tvoss_ | robert_ancell, thx | 05:10 |
| duflu | robert_ancell, ta | 05:12 |
| * duflu -> lunch | 05:12 | |
| tvoss_ | duflu, enjoy | 05:13 |
| RAOF | robert_ancell: Feel like approving https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140 while I'm on a wait-for-CI-review-fest? | 05:17 |
| robert_ancell | RAOF, I don't know why he moved the demos to libexec - that doesn't make sense to me | 05:17 |
| robert_ancell | But if you installed them, you do want to be easily able to run them | 05:18 |
| robert_ancell | it's not like they're in the main package | 05:18 |
| didrocks | hey RAOF! I think this is perfect timing :) | 05:20 |
| robert_ancell | didrocks, speak of the devil :) | 05:20 |
| robert_ancell | didrocks, why demos into libexec? | 05:20 |
| didrocks | robert_ancell: hey! see RAOF's answer! https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140/comments/381521 | 05:21 |
| tvoss_ | duflu, you've got a conflict on https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/171070 | 05:21 |
| robert_ancell | didrocks, well, the manpages issue doesn't warrant them moving and if you install the package you expect them to be easily runnable | 05:21 |
| didrocks | robert_ancell: and getting 8 demo_mir_ in your path? :) | 05:22 |
| robert_ancell | didrocks, yes. The package contains 8 demo applications.. | 05:23 |
| didrocks | robert_ancell: I think as they are seeing as examples, we should do as for other demos, like the Qt ones and having them in a path that's not polluting the $PATH | 05:23 |
| didrocks | seen* | 05:23 |
| robert_ancell | didrocks, which qt package is this? | 05:23 |
| didrocks | robert_ancell: http://packages.ubuntu.com/raring/i386/qt4-demos/filelist | 05:24 |
| robert_ancell | didrocks, you can approve if you want | 05:27 |
| tvoss_ | hmmmm, kubuntu-desktop seems to be in -proposed. didrocks, any idea when that is going to land? | 05:28 |
| didrocks | robert_ancell: thanks! | 05:28 |
| didrocks | tvoss_: kubuntu-desktop? did you look at the migration excuses? | 05:28 |
| tvoss_ | didrocks, nope | 05:28 |
| didrocks | tvoss_: are you sure about kubuntu-desktop? https://launchpad.net/ubuntu/+source/kubuntu-meta seems that it wasn't uploaded nor blocked for some days | 05:31 |
| tvoss_ | didrocks, kubuntu-devel's topic says so :) | 05:31 |
| didrocks | robert_ancell: I think kgunn gave to you the bug list we need to check before getting mir into distro? | 05:31 |
| didrocks | tvoss_: well, I trust launchpad for facts, they are maybe talking about kde components, not the package | 05:32 |
| tvoss_ | didrocks, ah okay | 05:32 |
| didrocks | tvoss_: did you see my question on lttng* btw? | 05:32 |
| didrocks | (yesterday evening) | 05:32 |
| robert_ancell | didrocks, yep | 05:33 |
| didrocks | Thanks robert_ancell :) | 05:33 |
| tvoss_ | didrocks, on irc? if so, bear with me, I was doing the session dance | 05:34 |
| didrocks | tvoss_: ok, the question that colin and I had was libmirserverlttng.so and libmirclientlttng.so needs to be in system library path | 05:35 |
| didrocks | tvoss_: as there is no ABI/soname, they normally should be seen as private lib | 05:35 |
| didrocks | so not really sure how lttng picks them, what's the mechanism? | 05:35 |
| tvoss_ | didrocks, lttng does not pick them, they define and implement lttng probes that feed to the trace if activated | 05:35 |
| tvoss_ | alf_, ^, mind helping out didrocks? | 05:36 |
| tvoss_ | didrocks, I think they should have an ABI/soname, though | 05:36 |
| didrocks | tvoss_: the question I guess is how are they activated? Do we tell lttng "please use those libs?" | 05:37 |
| tvoss_ | didrocks, nope, the implementation in the libs tells lttng on activation: here I am | 05:38 |
| tvoss_ | didrocks, so it's not a "plugin" to lttng | 05:38 |
| didrocks | hum, I'm a little bit lost on the activation mecanism :) | 05:38 |
| alf_ | didrocks: they are dlopened by Mir internally | 05:39 |
| alf_ | didrocks: right now it's dlopen("limirclientlttng.so"...) | 05:39 |
| didrocks | alf_: ah, so we can install them in a private lib, rather? | 05:39 |
| didrocks | dir* | 05:39 |
| didrocks | alf_: like /usr/lib/x86_64-linux-gnu/mir/tools/ ? | 05:40 |
| alf_ | didrocks: Yes. In that case will I need to use the path when dlopen-ing or will the path be added to LD_LIBRARY_PATH externally? | 05:40 |
| didrocks | alf_: I think on compilation, we set that path in a .h for dlopen-ing, as we can multiarch it | 05:41 |
| didrocks | alf_: mind if we look at that together this morning? | 05:41 |
| didrocks | (like in a couple of hours) | 05:41 |
| alf_ | didrocks: sure, ping me | 05:42 |
| didrocks | thanks! | 05:42 |
| tvoss_ | alf_, where does the mir log go to, right now? | 05:48 |
| RAOF | tvoss_: You hunted down an “abort in global dtor” bug in the past, didn't you? | 05:48 |
| tvoss_ | RAOF, yup, how can I help? | 05:49 |
| alf_ | tvoss_: In stdout/stderr but it's not visible on the desktop since we put the VT in graphics mode. You can redirect it or use glog with a file output | 05:50 |
| RAOF | tvoss_: I'm shared-libbing mir-test-doubles (because I need their implementation of open() to be first in the link order), and the unit-tests fail with an abort in testing::internal::GTestLog::~GTestLog | 05:50 |
| robert_ancell | didrocks, please review https://code.launchpad.net/~robert-ancell/mir/copyright-fix/+merge/171215 | 05:51 |
| tvoss_ | RAOF, let me have a look. Why are we hit by those fini issues? I still suspect -Bsymbolic-functions, with the linker unloading so's too early | 05:51 |
| tvoss_ | RAOF, mind running it through ltrace real quick? | 05:53 |
| robert_ancell | bye all | 05:53 |
| RAOF | tvoss_: Not at all. | 05:53 |
| RAOF | robert_ancell: Night. | 05:53 |
| tvoss_ | robert_ancell, night | 05:53 |
| didrocks | robert_ancell: have a good night! | 05:53 |
| RAOF | tvoss_: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/ is the branch. | 05:54 |
| RAOF | Wow, ltrace spews a lot of debug output :) | 05:55 |
| tvoss_ | RAOF, yup, that's how tracked it down last time | 05:55 |
| RAOF | Hm. I take it that “ltrace bin/unit-tests’ shouldn't deadlock? :) | 05:56 |
| tvoss_ | RAOF, if that is the case, it's almost surely an issue in a pthread_mutex_destroy | 05:57 |
| RAOF | tvoss_: Oh, you mean “[ FATAL ] /home/chris/Canonical/Mir/mir/proper-drm-device-probe/3rd_party/gmock/gtest/include/gtest/internal/gtest-port.h:1486:: pthread_key_delete(key_)failed with error 22”? | 05:57 |
| tvoss_ | RAOF, something like that :) | 05:57 |
| RAOF | Sorry, should have given that output upfront! | 05:57 |
| tvoss_ | RAOF, no worries | 05:58 |
| tvoss_ | RAOF, building your branch right now | 05:58 |
| tvoss_ | alf_, for the log: I would think something like /var/log/mir/mir.0.log makes sense | 05:58 |
| tvoss_ | glog does log rotation, too | 05:58 |
| tvoss_ | alf_, but I would expect the shells pulling in mir to be able to adjust that, so unity-system-compositor setting up the logging | 06:00 |
| alf_ | tvoss_: makes sense | 06:01 |
| tvoss_ | alf_, let me file a bug on usc | 06:02 |
| duflu | tvoss_, and again :) https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/171070 | 06:10 |
| tvoss_ | duflu, didrocks do thread-local storage keys cease to exist on so unload? | 06:10 |
| duflu | tvoss_: No, SOs are not tied to threads | 06:11 |
| duflu | And they have no automatic destructor | 06:11 |
| tvoss_ | duflu, hmmm, so in the fini operation of unit-tests, a delete on a pthread key results in an error, although the key was existant before ... | 06:12 |
| duflu | tvoss_ : You might have another SO/fini bug if it's an old distro | 06:13 |
| tvoss_ | duflu, it's saucy | 06:13 |
| duflu | Not likely then | 06:13 |
| tvoss_ | duflu, nope | 06:14 |
| duflu | tvoss_: Also pthread_key_delete works by value. It's only an ID. So any error means the key is not a valid one... or you got heap corruption prior | 06:14 |
| tvoss_ | duflu, right ... just waiting for my debug build to finish | 06:15 |
| tvoss_ | didrocks, is there a list of changes to low-level userland stuff in saucy? | 06:15 |
| didrocks | tvoss_: yeah, I confirm what duflu says, the libs are loaded globally to a process, weird that you have this pthread issue then | 06:15 |
| didrocks | tvoss_: saucy-changes ML | 06:15 |
| didrocks | it's the only way to track what's in | 06:15 |
| duflu | I thought Linux was over these kinds of bugs. It's almost certainly an application bug | 06:15 |
| didrocks | still some copyright issues to fix for robert :) https://code.launchpad.net/~robert-ancell/mir/copyright-fix/+merge/171215 | 06:16 |
| tvoss_ | duflu, right, but I wonder what makes it pop up right now | 06:16 |
| didrocks | this deserves a coffee I guess now :p | 06:16 |
| tvoss_ | didrocks, exactly | 06:17 |
| didrocks | heh | 06:17 |
| tvoss_ | duflu, RAOF ah, heap corruptoin :) | 06:18 |
| tvoss_ | at least gdb says so, valgrind to the rescue then | 06:19 |
| tvoss_ | okay, there is heap corruption on fini of libmir-test-doubles.so | 06:22 |
| tvoss_ | arising from a std::string::~string | 06:23 |
| RAOF | alf_: How much would you like a UdevEnumerator RAII wrapper? It's on my TODO list anyway. | 06:29 |
| alf_ | RAOF: I don't consider it urgent enough to block the MP (especially if it's in the queue anyway). | 06:30 |
| RAOF | Cool. | 06:30 |
| duflu | tvoss_, arising from std::string ? | 06:32 |
| duflu | buffer overrun? | 06:33 |
| tvoss_ | duflu, checking | 06:33 |
| tvoss_ | RAOF, did you just push an update to the prober branch? | 06:33 |
| RAOF | tvoss_: Yeah, but just stylistic changes. | 06:34 |
| tvoss_ | RAOF, there are some stray characters in there :) | 06:34 |
| RAOF | RGARGHUH. | 06:35 |
| RAOF | Hurray for stray non-printing characters! | 06:37 |
| tvoss_ | RAOF, oh, and std::static_cast -> static_cast | 06:40 |
| RAOF | Yeah. | 06:40 |
| RAOF | Got that one myself :) | 06:40 |
| RAOF | tvoss_, duflu: Looks like it's double free()ing the string? | 06:46 |
| tvoss_ | RAOF, yeah, but it's racy and I'm not able to track down the string location | 06:47 |
| duflu | tvoss_: Is it a static global? Those can easily get double freed | 06:47 |
| tvoss_ | duflu, already searched for static std::string, nothing test-doubles, next is look through source files and see if we have global strings somewhere | 06:47 |
| tvoss_ | duflu, although fini should be threadsafe, shouldn't it? | 06:48 |
| duflu | Bisect! | 06:48 |
| RAOF | Happens when having an indirect link of libmirserver0 | 06:48 |
| duflu | tvoss_: Well, no I don't think so. Fini doesn't have to be thread safe. It's only every called once, in theory | 06:48 |
| duflu | tvoss_: Ah linking to client & server libraries? | 06:49 |
| RAOF | It does do that, yes. | 06:49 |
| duflu | If so then it can happen if there is a global symbol of the same name (as in our input code that's duplicated) | 06:49 |
| duflu | The first loaded copy gets destructed twice. And the second, never. | 06:49 |
| duflu | Or not global, but a static class member even | 06:50 |
| duflu | The solution is to replace it with a static getter function that returns a reference to the real variable (which is static inside the getter function) | 06:50 |
| didrocks | is it me or Mir trunk doesn't build anymore? | 06:52 |
| tvoss_ | duflu, okay, let me scan through the code | 06:52 |
| tvoss_ | didrocks, it's obviously you ;) | 06:52 |
| duflu | tvoss_: See r566 as an example | 06:52 |
| didrocks | tvoss_: saucy, right? | 06:52 |
| tvoss_ | duflu, although it's a question whether this is faulty linker behavior | 06:53 |
| duflu | tvoss_, that's a premature and usually naiive argument :) | 06:54 |
| tvoss_ | didrocks, ack | 06:54 |
| tvoss_ | duflu, well, my suspicion is that if you remove -Bsymbolic, it wouldn't result in issues | 06:54 |
| duflu | tvoss_, Yeah you're probably right. But you can modify statics like in r566 so you don't need to remove Bsymbolic | 06:55 |
| tvoss_ | duflu, I rarely blame the compiler or the linker, but the exposed behavior contradicts the c++ standard. Not saying that is bad necessarily! | 06:55 |
| RAOF | Survey suggests that 3rd_party/gmock/gtest/include/gtest/internal/gtest-death-test-internal.h: static std::string last_death_test_message_; is a possible culprit. | 06:56 |
| duflu | Well, linkage rules are outside the scope of C* languages, unfortunately | 06:56 |
| didrocks | tvoss_: let's say I'm blaming ccache and I retry without it | 07:00 |
| tvoss_ | didrocks, branching trunk now :) | 07:00 |
| didrocks | tvoss_: I think it's fine, seems to be ccache + parallel build not playing fine | 07:01 |
| duflu | tvoss_, thanks for fixing my bug without even being aware :) | 07:05 |
| duflu | https://bugs.launchpad.net/mir/+bug/1194054 | 07:05 |
| ubot5 | Launchpad bug 1194054 in Mir "--vt N option seems to be unreliable/racing" [Medium,Fix committed] | 07:05 |
| tvoss_ | duflu, \o/ | 07:06 |
| tvoss_ | didrocks, ack | 07:07 |
| didrocks | tvoss_: duflu: RAOF: alf_: does mirplatformgraphics really belong to the same binary package than libmirserver0? | 07:10 |
| didrocks | (it will follow the same ABI stability I guess?) | 07:11 |
| RAOF | Oh, has loadable backends landed? | 07:11 |
| duflu | didrocks: They share all their code, and we fully expect parts to move around between them as a driver model materializes | 07:11 |
| RAOF | For the moment it's certainly in libmirserver0 | 07:11 |
| duflu | RAOF: Landed yes, but it's just the old library made dynamic instead of static | 07:11 |
| alf_ | didrocks: In the future I would expect to have separate packages for the various backends | 07:12 |
| didrocks | RAOF: duflu: alf_: ok, let's keep it that way, then, thanks! | 07:12 |
| * didrocks remerges his branch and multiarch that one as well before pushing | 07:12 | |
| tvoss_ | duflu, idea for testing vt's: we request the next free vt and do all of the activation magic and modesetting there | 07:14 |
| tvoss_ | RAOF, duflu any idea how we can get vts back? | 07:17 |
| RAOF | ECONTEXT. Back from what? | 07:17 |
| duflu | tvoss_: Ctrl+Alt+F7 to regular X, and then back to your VT (https://bugs.launchpad.net/mir/+bug/1189770) | 07:18 |
| duflu | ? | 07:18 |
| ubot5 | Launchpad bug 1189770 in Mir "[regression] Killing Mir with Ctrl+C often leaves the screen blank and difficult to recover " [High,Triaged] | 07:18 |
| duflu | tvoss_: I'm not sure any automated tests should be touching real hardware, by default... ? | 07:20 |
| tvoss_ | duflu, not sure that the trick works. Can we fix that issue somehow? | 07:20 |
| duflu | tvoss_: Not sure. Maybe our SIGINT handler needs to do cleaner shutdown | 07:23 |
| duflu | Which is simple | 07:23 |
| duflu | Haven't looked | 07:23 |
| duflu | tvoss_: The trick doesn't work if you're using unity-system-compositor :( | 07:34 |
| duflu | tvoss^ | 07:34 |
| tvoss | okay, found the reason for the double free | 07:54 |
| duflu | Woo | 07:54 |
| tvoss | but: that still does not solve the issue with the std::string dtor | 07:55 |
| tvoss | RAOF, ^ | 07:55 |
| RAOF | tvoss: How did you find the double-free? | 07:59 |
| RAOF | Also, what is it? :) | 07:59 |
| tvoss | RAOF, let me pastebin the diff | 07:59 |
| RAOF | Hm, or not :) | 08:02 |
| tvoss_ | RAOF, hold on, compiling :) | 08:12 |
| tvoss_ | RAOF, http://pastebin.ubuntu.com/5797856/ | 08:15 |
| tvoss_ | RAOF, there is still some issue reported by valgrind about an invalid free in a string | 08:17 |
| tvoss_ | RAOF, and busid is a std::string now | 08:17 |
| hikiko | hi | 08:20 |
| hikiko | question :) | 08:20 |
| hikiko | http://unity.ubuntu.com/mir/namespacemir_1_1compositor.html I am looking at the classes here, trying to understand the system and the session compositor... but I am a bit confused | 08:21 |
| hikiko | the system compositor is the Multithreaded Compositor? | 08:22 |
| tvoss_ | hikiko, nope, why should it? the system compositor is a process on its own | 08:23 |
| hikiko | tvoss_, could you explain me a bit the concept with the 2 compositors or tell me the classes to look at? | 08:24 |
| hikiko | system compositor == the whole mir? | 08:25 |
| tvoss_ | hikiko, no need to look at classes: every compositor is the whole of mir | 08:25 |
| tvoss_ | hikiko, the session compositor is just another client to the system compositor | 08:25 |
| tvoss_ | hikiko, both are independent processes | 08:26 |
| hikiko | every client == session compositor? | 08:26 |
| RAOF | hikiko: Every client of the system compositor is a session compositor. | 08:27 |
| tvoss_ | hikiko, nope, ordinary apps talk to the session compositor | 08:27 |
| hikiko | hmm I think that my problem then is that I didn't get what exactly the compositor does :S | 08:27 |
| hikiko | in case of mir server I understand | 08:27 |
| RAOF | Ish; we may well have a couple of non-compositor clients of the system compositor (such as a polkit authenticator) | 08:27 |
| hikiko | It combines/renders the win to a surface | 08:27 |
| tvoss_ | hikiko, it takes buffers and assembles a final output | 08:27 |
| hikiko | yes | 08:28 |
| tvoss_ | hikiko, in case of the system comp, that is sent to the display | 08:28 |
| tvoss_ | hikiko, in case of the session comp, that is sent to the system comp. | 08:28 |
| hikiko | so the windows of a client | 08:29 |
| hikiko | are assembled before being sent to the server | 08:29 |
| hikiko | and the server only displays the buffer with all the windows? | 08:30 |
| tvoss_ | hikiko, no, the windows of clients are surfaces known to the session comp | 08:30 |
| hikiko | so why the session compositor needs the server? | 08:30 |
| tvoss_ | hikiko, the session compositor is a server in itself. And: it does not know about displays and such and does not have access to the underlying hw | 08:31 |
| tvoss_ | hikiko, think about user session swithcing: all of these sessions are clients to the system comp | 08:31 |
| hikiko | I think I misunderstood what we call session then :s | 08:32 |
| tvoss_ | hikiko, ? | 08:32 |
| hikiko | mm | 08:32 |
| hikiko | tvoss_, let's say we have a client (a program that needs to open 2 windows) | 08:33 |
| tvoss_ | hikiko, what did you consider a session if not a user session? | 08:33 |
| tvoss_ | hikiko, okay | 08:33 |
| hikiko | a client connection | 08:33 |
| hikiko | but I am wrong obviously :) | 08:33 |
| hikiko | in the example with the 2 windows of a client | 08:34 |
| hikiko | the process is: | 08:34 |
| RAOF | We do have a concept of "session" in the codebase, don't we. | 08:34 |
| tvoss_ | RAOF, yup, every application is a session | 08:34 |
| hikiko | then I was right? | 08:34 |
| tvoss_ | hikiko, nope | 08:34 |
| RAOF | tvoss_: So, it's not entirely strange to be confused about the overloaded “session” nomenclature :) | 08:34 |
| tvoss_ | RAOF, it is overloaded for a good reason: all sessions are connections in the end | 08:35 |
| hikiko | ok what I am trying to understand is how mir would render the 2 windows of a client step by step | 08:35 |
| hikiko | because then everything mir does will be clear | 08:36 |
| hikiko | step 1: connection? | 08:36 |
| RAOF | hikiko: You can think of it like this - the system compositor is a Mir server that takes the contents of user-sessions (like Unity, GNOME, etc - a user login) and composites them to the hardware. | 08:36 |
| hikiko | so all the unity programs | 08:36 |
| tvoss_ | hikiko, step 1: ack | 08:36 |
| hikiko | are part of 1 session? | 08:36 |
| RAOF | hikiko: A session compositor is a Mir server that takes all the windows of a user's login and composites them into the user-session. | 08:36 |
| tvoss_ | hikiko, ack | 08:37 |
| hikiko | oh I see :) then I was completely wrong :) | 08:37 |
| hikiko | ok so, we composite every unity window on the client | 08:37 |
| hikiko | compose* | 08:37 |
| hikiko | and then | 08:38 |
| hikiko | what we do with the server? | 08:38 |
| tvoss_ | hikiko, hold on: what do you mean by "On the client" | 08:38 |
| tvoss_ | ? | 08:38 |
| hikiko | I mean | 08:38 |
| hikiko | if we start unity on a pc | 08:38 |
| hikiko | we have 1 buffer for each window | 08:38 |
| hikiko | we combine these buffers on a large buffer | 08:39 |
| hikiko | and then we sent it to mir | 08:39 |
| hikiko | (server) | 08:39 |
| RAOF | Ah, no. | 08:39 |
| tvoss_ | hikiko, nope | 08:39 |
| RAOF | We have one buffer for each window. | 08:39 |
| tvoss_ | hikiko, the combination of the buffers is done by mir, too | 08:39 |
| RAOF | A mir server combines these buffers onto a large buffer. | 08:39 |
| RAOF | And sends that large buffer off to a mir server. | 08:39 |
| RAOF | Which combines the large buffers onto the framebuffer. | 08:39 |
| hikiko | this is the same mir server? | 08:40 |
| tvoss_ | hikiko, nope, two processes | 08:40 |
| RAOF | No, two different mir servers. | 08:40 |
| RAOF | The first Mir server - the one that all the user's applications run in - is called the session compositor, because it takes all the windows of the user's session and composites them. | 08:41 |
| RAOF | The second Mir server - the one that all the session compositors talk to - is called the system compositor, because it takes the outputs of all the sessions and composites them onto the system's displays. | 08:41 |
| hikiko | and why we need to composite once in a buffer and once in the framebuffer? | 08:42 |
| RAOF | It makes things easier. | 08:43 |
| hikiko | we can't do the composition directly in the framebuffer? | 08:43 |
| tvoss_ | hikiko, we can, but we don't want for the session compositor in the first place | 08:43 |
| RAOF | Specifically - it makes running different users, and handling the transitions between them - easier. | 08:43 |
| hikiko | ok :) | 08:43 |
| tvoss_ | RAOF, plus: suspend/resume etc. | 08:44 |
| RAOF | tvoss_: And boot splash → greeter → session, yeah. | 08:44 |
| hikiko | actually i thought that we only compose once at the framebuffer and the session compositor was for a program's windows completely different from what we actually do :) | 08:44 |
| hikiko | that's why I was so confused | 08:44 |
| hikiko | so in my case the nested mir will have 2 server processes as well | 08:45 |
| tvoss_ | ? | 08:45 |
| RAOF | I'm not sure what you mean. | 08:46 |
| RAOF | There'll only be one nested server process (per user) | 08:47 |
| RAOF | But there'll be a nested server process and the system server process, yes. | 08:47 |
| hikiko | yes that's what I mean :) sorry I cant make myself very clear | 08:48 |
| hikiko | and RAOF | 08:48 |
| hikiko | the nested mir clients | 08:48 |
| hikiko | will use the nested mir session compositor | 08:48 |
| RAOF | tvoss_: What does that patch fix? I see exactly the same crash and exactly the same valgrind double free? | 08:48 |
| RAOF | hikiko: Right. | 08:49 |
| hikiko | so I have to change it to use a different socket for the clients | 08:49 |
| tvoss_ | RAOF, it get's rid of a spurious double free during repeated test execution of bin/unit-tests | 08:49 |
| hikiko | isn't it? | 08:49 |
| RAOF | hikiko: Yes; there'll be two sockets - the system compositor's socket, and the session compositor (nested) socket. | 08:50 |
| hikiko | RAOF, which classes implement the session compositor to get a look at? I guess the directory compositor is for the system compositor isn't it? | 08:50 |
| RAOF | hikiko: The session compositors and system compositors live outside mir; there isn't a class to implement. | 08:51 |
| RAOF | tvoss_: Ah, ok. So it doesn't do anything about the double free() on shutdown, then. | 08:51 |
| tvoss_ | RAOF, not yet, still tracking down | 08:52 |
| hikiko | so, i guess I have to look at the examples :) | 08:53 |
| RAOF | hikiko: What needs to be done for the nested compositor is implementing src/server/graphics/nested-gbm. | 08:53 |
| hikiko | and add some code to keep a socket where the nested_gbm accepts connections? | 08:54 |
| RAOF | Hm, yes. That too. | 08:54 |
| hikiko | cool :) I am going to start this thanks a lot RAOF and tvoss_ :) | 08:55 |
| tvoss_ | hikiko, would you mind keeping us posted how you come along? I think we can help unblock you in case of questions/issues easily | 08:56 |
| tvoss_ | raof, it seems like the gpu hang on intel is mostly caused by chrome | 08:59 |
| RAOF | Oh. | 08:59 |
| RAOF | That's inconvenient. | 08:59 |
| tvoss_ | RAOF, it is, but it also happens on vanilla x occasionally | 08:59 |
| RAOF | Upstream's also not going to be particularly helpful until I finish the SNA xmir implementation, either. | 09:00 |
| hikiko | sure tvoss_ atm I have only done a platform/display that compile but do nothing and now I'll try this socket change to test what Ive done using clients :) | 09:00 |
| RAOF | Downloading libstdc++ source. Things can only get more awesome. | 09:01 |
| hikiko | RAOF, and tvoss_ sorry but I have another question | 09:03 |
| RAOF | Go ahead! | 09:04 |
| hikiko | I understood it :) I was wondering what happens with the z order if we have 2 compositors but then I remembered that we composite all the user program windows in the buffer compositor (session) so there's no problem | 09:07 |
| hikiko | if we have 2 windows* | 09:07 |
| hikiko | of the same program | 09:07 |
| hikiko | but ok | 09:07 |
| hikiko | there's no problem | 09:07 |
| RAOF | Right! | 09:07 |
| tvoss | RAOF, for chrome/hangouts: if running firefox without using hangouts -> stable. Hangout in Firefox: almost immediate hang | 09:16 |
| didrocks | alf: ok, I've now the *ttng* modules installed in <libexecdir>/mir/tools/ for lp:~didrocks/mir/move-lttng-libs | 09:25 |
| didrocks | alf: you just need to change the dlopening I guess | 09:26 |
| tvoss | RAOF, hah | 09:30 |
| RAOF | tvoss: Oh, win? | 09:31 |
| tvoss | RAOF, the pthread_key is indeed removed twice, with the second attempt failing | 09:32 |
| tvoss | RAOF, it's triggered by GTEST_API_ extern ThreadLocal<Sequence*> g_gmock_implicit_sequence; | 09:33 |
| alf | didrocks: thanks, I will take a look a bit later | 09:39 |
| mlankhorst | how are hybrid display outputs handled with mir? | 09:40 |
| RAOF | mlankhorst: At the moment? They're not. | 09:52 |
| mlankhorst | could it be made to work? :p | 09:52 |
| RAOF | Absolutely. | 09:52 |
| mlankhorst | what pieces are missing atm? | 09:52 |
| RAOF | tvoss: valgrind+gdb suggest that testing::FLAGS_gmock_verbose might be the std::string being double-freed. | 09:53 |
| tvoss | RAOF, I really don't understand why we are seeing such issues popping up right now | 09:54 |
| RAOF | mlankhorst: The gbm platform would need to open both drm devices, rather than just the first. Then we'd need to create an EGL context on both. Then we'd need to handle multiple monitors in a less stupid way ;) | 09:54 |
| tvoss | mlankhorst, alf is the right guy to talk to :) | 09:54 |
| RAOF | tvoss: I'd guess it's because we don't link both mirclient and mirserver in to anything else? | 09:54 |
| RAOF | Or, at least, we don't link against anything that links against both mirclient and mirserver? | 09:55 |
| mlankhorst | I could probably use the xorg code as an example for drm device detection, we need to talk to udev anyway for this | 09:55 |
| tvoss | mlankhorst, we are having parts of that under review right now :) | 09:55 |
| RAOF | mlankhorst: Correct. See lp:~raof/mir/prober-drm-device-probe :) | 09:55 |
| RAOF | mlankhorst: For simple proof-of-concept GPU offloading you could probably get away with just opening both devices, handing one drm device to the GBMDisplay and the other to the GBMBufferAllocator. | 09:56 |
| RAOF | mlankhorst: Then you'd have display on one device and rendering on the other. | 09:57 |
| mlankhorst | RAOF: xorg doesn't like hybrids ;) | 09:57 |
| mlankhorst | in mir | 09:57 |
| RAOF | mlankhorst: Correct. I disabled gpu-only loading, didn't I? | 09:57 |
| RAOF | Or was that only for -radeon? | 09:57 |
| mlankhorst | dno | 09:57 |
| mlankhorst | the thing has outputs so it works | 09:57 |
| mlankhorst | I have one without outputs to test too | 09:57 |
| RAOF | The one without outputs will now start Mir on the device that *has* outputs! | 09:58 |
| RAOF | 8pm is probably EOD. | 09:58 |
| RAOF | So long, chappies! | 09:59 |
| mlankhorst | see ya mateQ! | 09:59 |
| duflu | RAOF: Bye. And mee too | 10:00 |
| duflu | See, I can't even type any more | 10:01 |
| mlankhorst | RAOF: btw that code is too difficult, you don't need to use setversion to test | 10:03 |
| tvoss | RAOF, so long :) | 10:04 |
| mlankhorst | RAOF: use drmModeGetResources(fd); if it returns NULL KMS is not supported on that node, and it should be ignored entirely (nvidia blob for example). After that just check ret->count_connectors and use drmModeFreeResources | 10:04 |
| mlankhorst | I only found out after checking with upstream, but it's the cheapest test, no need to traverse udev or anything like that.. | 10:08 |
| mlankhorst | RAOF: http://paste.debian.net/12543/ .. not even compile time tested :> | 10:18 |
| mlankhorst | oh it could be better still | 10:19 |
| tvoss | RAOF, okay, for the pthread_key_delete issue: the global initializer is executed twice | 10:19 |
| tvoss | didrocks, ^ | 10:19 |
| mlankhorst | open syspath/boot_vga, read it and if it's == '1' there you go, this one is the primary | 10:20 |
| didrocks | tvoss: rings to me like a bell, didn't we get something like that already hard to decipher? | 10:20 |
| tvoss | didrocks, yup, look here: http://pastebin.ubuntu.com/5798108/ | 10:21 |
| tvoss | didrocks, it executes the c'tor for the global object twice, for the same this pointer | 10:21 |
| didrocks | tvoss: indeed, good catch! | 10:28 |
| tvoss | didrocks, well, at least it's reproducible on my machine | 10:30 |
| tvoss | quick lunch | 10:43 |
| === tvoss is now known as tvoss|quick_lunc | ||
| === tvoss|quick_lunc is now known as tvoss | ||
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| greyback | racarr: who good to ask these questions to: http://studio.sketchpad.cc/flleQTzi4o | 14:36 |
| greyback | they're some Mir comments and questions I've assembled the last day or 2 | 14:36 |
| === mmrazik is now known as mmrazik|afk | ||
| kdub | hello | 15:11 |
| kgunn | kdub: mornin' | 15:27 |
| didrocks | alf: hey, any luck? :) | 15:38 |
| alf | didrocks: sorry, not yet (and probably not today), I was caught up in other work. I will take a look first thing tomorrow | 15:42 |
| didrocks | alf: ok good :) | 15:43 |
| didrocks | alf: should we open a bug for that add the tag so that kgunn can know exactly what's blocking Mir in distro? | 15:43 |
| kgunn | didrocks: alf....shoot me the link when there | 15:53 |
| didrocks | kgunn: added to https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy | 15:56 |
| olli | alf, still around | 15:57 |
| kgunn | didrocks: thanks....alf i'll try to get alan to look at when he returns...please stay on snapshot/mm | 15:57 |
| alf | olli: intermittently :) | 15:58 |
| alf | didrocks: thanks | 15:58 |
| didrocks | yw :) | 15:58 |
| olli | alf, I noticed some variance in 2 consecutive glmark2 runs on the same system | 15:58 |
| olli | is this expected/possible | 15:58 |
| didrocks | olli: reiterating that if you want me to comment on the google doc, please give me comment rights :) | 15:58 |
| olli | or do I need to check my background processes | 15:59 |
| olli | didrocks, didn't get to it yet | 15:59 |
| didrocks | olli: no worry, just wanted to ensure you read my request ;) | 15:59 |
| alf | olli: What kind of environment are you running glmark2 in? | 15:59 |
| olli | alf, xmir on intel | 15:59 |
| kgunn | olli: cpu load can effect benchmarks...altho, you'd have to have alot of stuff going on | 15:59 |
| alf | olli: how much variance do you see? | 16:00 |
| olli | didrocks, done | 16:00 |
| olli | alf, I got ~900 on saucy stock | 16:00 |
| olli | and then ~900 on saucy/xmir | 16:00 |
| olli | or 700 saucy xmir | 16:00 |
| didrocks | olli: danke schön | 16:00 |
| olli | I hadn't measured multiple runs on stock saucy though | 16:01 |
| kgunn | olli: can you do same for openarena? | 16:01 |
| kgunn | olli: btw, my system fixed :) | 16:01 |
| olli | alf, I'd assume that in general a small deviation (few %) are anticipated but not ~25% | 16:01 |
| alf | olli: right, 700->900 is not normal variance | 16:02 |
| kgunn | altho...hit one of the legit bugs that prevented me from running xmir (i can do the client demos tho) | 16:02 |
| kgunn | olli: alf i loathe the nebulous agregate # from benchmarks....fps are best | 16:02 |
| kgunn | openarena is sub 60 | 16:02 |
| kgunn | so it would be a better metric | 16:02 |
| olli | kgunn, I am working with chrisGagnon to get some repeatable tests in place | 16:03 |
| kgunn | olli: much thanks on that | 16:03 |
| didrocks | olli: testing playing openarena? I see :-) | 16:40 |
| Guest36302 | gpg: skipped "Robert Carr <robert.carr@canonical.com>": secret key not available | 17:09 |
| Guest36302 | Keep getting this when trying MIR | 17:10 |
| kdub | give out your secret key racarr ;-) | 17:10 |
| Guest36302 | debuild -i -I | 17:12 |
| Guest36302 | after this command is when I receive the message | 17:12 |
| kdub | perhaps the debian/changelog does not have your email as the latest entry? | 17:12 |
| Guest36302 | ah, probably. I guess this means I need to be logged into bzr | 17:13 |
| Guest36302 | I | 17:13 |
| racarr | My secret key is 21. | 17:14 |
| racarr | Insist on doing RSA in my head. | 17:14 |
| racarr | Guest36302: There is some flag you can pass to not sign that I don't remember or you can do dch -i and add an entry for yourself | 17:14 |
| === dpm is now known as dpm-afk | ||
| === mhall119_ is now known as mhall119 | ||
| racarr | Im going to attempt to refactor | 17:25 |
| racarr | the focus bits of the SessionManager | 17:25 |
| racarr | and the_focus_mechanism | 17:26 |
| racarr | and the_focus_sequence | 17:26 |
| racarr | in to something sensible for the shell...probably a single FocusArbitrator | 17:26 |
| racarr | does anyone have any thoughts? | 17:26 |
| racarr | on refactoring the focus machinery, not in general :p | 17:26 |
| racarr | kdub: Also I was wondering has anything come out of seperating surface state from msh::Surface | 17:27 |
| racarr | greyback is asking for API to be notified on surface state change | 17:27 |
| racarr | and that's weird at the moment | 17:27 |
| racarr | because you don't want to subclass the surface | 17:27 |
| kdub | racarr, well, still untangling dependencies a bit | 17:27 |
| racarr | but its not clear that | 17:27 |
| racarr | EventSink | 17:27 |
| racarr | is really the proper interface here. | 17:27 |
| kdub | no, probably not :) | 17:27 |
| racarr | sometimes I wish we just had signals | 17:28 |
| kdub | really, this is that 'interface' that i've been going on about... | 17:28 |
| racarr | kdub: Aha. mir::shell::Interface | 17:28 |
| racarr | DONE | 17:28 |
| kdub | from the shell's perspective, I think that a 'ask-decide-command' (wrt the surfaces) is a good way to go, as opposed to having a notification signal | 17:30 |
| racarr | mm | 17:31 |
| kdub | this is probably a bit off topic from the 'FocusArbitrator" that you were talking about | 17:31 |
| racarr | well, I mean signals can have responses, I guess what I meant by signal | 17:31 |
| racarr | is that a subscription | 17:31 |
| racarr | pattern is easiest | 17:31 |
| racarr | but often gets | 17:31 |
| racarr | tangled. | 17:31 |
| racarr | whereas we use... | 17:31 |
| racarr | I don't know what the opposite of a subscription pattern is XD | 17:32 |
| racarr | but explicit listeners, etc. | 17:32 |
| kdub | well, the opposite is :) keeping the state in one place | 17:32 |
| racarr | hmm sort of | 17:32 |
| racarr | I just mean we don't have any APIs like | 17:32 |
| kdub | what I mean by that is... if we have a callback signal, we 'im the shell, and the last time mir callbacked me, the position is at x1, y1' | 17:33 |
| racarr | add_surface_opened_handler(std::function) | 17:33 |
| racarr | etc. | 17:33 |
| racarr | they are all through the configuration | 17:33 |
| kdub | in addition to 'im mir, and I think the state is at x1, y1' | 17:33 |
| kdub | right | 17:33 |
| kdub | i like that :) | 17:33 |
| racarr | I think it's worthwhile yeah. | 17:34 |
| kdub | mir says, 'hey, new surface arrived over ipc, ask me about it' | 17:34 |
| racarr | mm | 17:34 |
| kdub | instead of saying ' a new surface arrived, here's the details, but... this is just an echo of the state' | 17:34 |
| kdub | i guess I just want state to 'flow' into the right components | 17:35 |
| kdub | instead of having a gob of state bunched up in a common place | 17:35 |
| racarr | mm | 17:35 |
| === thomi_ is now known as thomi | ||
| racarr | thomi: Hey! | 20:28 |
| thomi | o/ | 20:29 |
| racarr | now that qtubuntu and platform api mir are packaged and in PPAs | 20:29 |
| racarr | I think we should do some sort of | 20:29 |
| racarr | integration testing? | 20:29 |
| racarr | continuous integration? | 20:29 |
| racarr | *waves hands* | 20:29 |
| racarr | I dunno, I imagine like, we have the staging PPA, where everything just lands and it's built | 20:29 |
| racarr | but then to make it in to the next PPA or some such, i.e. phone-testing-ppa | 20:30 |
| racarr | some integration test has to pass that brings up Qt clients, does some autopiloting | 20:30 |
| racarr | etc | 20:30 |
| thomi | racarr: maybe send me instructions on what I need to do to try this myself? | 20:33 |
| thomi | is it as simple as adding the PPA and dist-upgrading? Or is there some manual configuration involved? | 20:33 |
| racarr | thomi: Um. well now that I think of it right now the packages are only buitl on arm XD | 20:38 |
| racarr | so maybe its too soon | 20:38 |
| thomi | racarr: hmm, are there plans to build for other archs? | 20:40 |
| racarr | thomi: Yeah, it's just not under CI yet because we are still waiting on the qtubuntu changes to land | 20:45 |
| racarr | so it's under ricmm integration ATM | 20:45 |
| thomi | racarr: ok | 20:49 |
| thomi | probably best to wait a bit then | 20:50 |
| racarr | Ok :) | 20:50 |
| === seb128_ is now known as seb128 | ||
| === seb128_ is now known as seb128 | ||
| === seb128_ is now known as seb128 | ||
| === seb128_ is now known as seb128 | ||
| mterry | racarr, I'm following the mir-with-unity sketchpad instructions again, filling them out to be more fool-proof. But I ran into a problem building qtubuntu: | 21:45 |
| mterry | ../ubuntucommon/libqubuntucommon.a(integration.o): In function `QUbuntuIntegration::createPlatformWindow(QWindow*)': | 21:46 |
| mterry | /home/phablet/tmp/qtubuntu/mir-with-packaging/src/platforms/ubuntucommon/integration.cc:140: undefined reference to `ua_ui_session_properties_set_remote_pid' | 21:46 |
| mterry | collect2: error: ld returned 1 exit status | 21:46 |
| racarr | mterry: https://code.launchpad.net/~robertcarr/platform-api/missing-mir-stub | 21:52 |
| racarr | merged with r73 of papi | 21:52 |
| mterry | racarr, aweosome | 21:54 |
| mterry | racarr, what is the a for in ua_? api? | 21:54 |
| racarr | mterry: application | 22:00 |
| robert_ancell | RAOF, did that gbm debugging help> | 22:19 |
| robert_ancell | ? | 22:19 |
| * kdub enters the swamp | 22:51 | |
| kdub | racarr, event sinks... are they per-surface, or per-session? | 23:20 |
| kdub | or rather, :) they are per-surface at the moment, could they be per-session? | 23:21 |
| racarr | kdub: They are per session | 23:40 |
| racarr | kdub: Handed by the session to each of it's surfaces | 23:41 |
| kdub | ah, yeah | 23:42 |
| robert_ancell | mterry, still there? | 23:45 |
| RAOF | Gah. What happened to all my beautiful backscroll? | 23:53 |
| racarr | RAOF: You missed some pretty juicy stuff. | 23:56 |
| racarr | A lot of things were said about you, I'm not sure they are appropriate to repeat. | 23:56 |
| racarr | kdub: Kind of out of the blue but you may have an opinion on this as it ties in a bit with the structure of msh::Surface | 23:58 |
| racarr | more with Session I guess. | 23:58 |
| kdub | racarr, pass one is just to lift these factories out of being so deep | 23:58 |
| racarr | kdub: So, in my attempt to refactor focus | 23:59 |
| racarr | Err, trying to find the best way to explain, sorry | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!