bschaeferRAOF, hey, been using normal X and no event queue overflowing00:15
RAOFbschaefer: Ta.00:16
RAOFSo we're doing something that's slowing you down.00:16
bschaeferRAOF, np, is there a way I could start debuging this?00:16
RAOFOh! Next time you see that, could you check dmesg? It's entirely possible that what's slowing you down is that the GPU is hung and getting reset :)00:16
bschaeferRAOF, recompiling00:16
bschaeferRAOF, yes I can! Is it fine checking it on a reboot?00:17
RAOFYes, but dmesg  will obviously have been blown away by a reboot :)00:17
bschaefer[ 1204.260268] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung00:17
RAOFBut you should be able to find that in syslog.00:17
bschaeferthat sounds bad00:18
bschaeferRAOF, cool, Ill switch back over to xmir and gather some more info!00:18
bschaeferbut that was a segfault in libgrid.so/compiz which I was messing around with that...so im guessing that was me :)00:20
kdubif anyone's got some spare cycles :) lp:~kdub/mir/remove-surface-target00:52
RAOFkdub: InputChannel seems like the wrong name for that class. But I can't offhand think of a better one.01:11
kdubRAOF, yeah, i just adopted a name that was already there01:12
RAOFActually, is there any particular reason it shouldn't be SurfaceInfo?01:13
RAOFThat's what it appears to contain.01:13
RAOFAlso, ♪ doxygen comments, doxygen comments ♫01:14
kdubwell, SurfaceInfo is an object that contains the data common to both the input and graphics side of things01:15
kdubso as it is now, both have a pointer to the object with all the data, instead of them trying to both get at the same data via inheritance01:15
kdub(which isn't threadsafe in trunk anyways)01:15
RAOFBut an InputChannel is *also* just an object that contains the data common to both the input and graphics side of things?01:16
kdubwell, its the interface that the input system gets at that data01:16
kdubreally, both the compositor and the input stack should get a SurfaceInfo object and a Renderable/Channel (respectively)01:16
kdubbut that made for more and more churn01:16
RAOFI don't want to make the perfect the enemy of the good here, but client_fd() and server_fd() are both also info about a surface, and it looks to me like everywhere you pass an InputChannel you could pass a const SurfaceInfo, *and* that would be clearer.01:20
kdubi agree it would be cleaner01:21
kdubwell, actually, i have to think about it a bit more01:22
kdubthe input system registers one object...01:22
RAOFI also don't see it as being significant extra work, but that's from my perspective of reading over the MP and not being the *target* of that extra work, so may well be wrong :)01:22
RAOFOh, I guess it would mean that SurfaceInfo is not atomically correct - you'd need to populate it with data from two separate places...01:23
RAOFSweet! Anything including glib fails to build with -Werror under clang.02:00
RAOFAt least with clang-3.4; we're good with clang 3.2 for a while.02:19
dufluglib requires everything start with "g", including the compiler02:20
dufluAlthough that is almost surprising because glib has long been ported to Windows and beyond. So it has good compiler portability02:21
duflu-good +adequate02:21
RAOF‘register’ is deprecated in C++11 (and maybe C11?), which is why clang fails.02:23
RAOFPresumably g++ will fail there too, once it catches up with the standard.02:23
RAOFduflu: Oh, by the way - have you thought about submitting a paper for LCA?02:30
RAOFSince you'll be in the neighbourhood anyway :)02:30
dufluRAOF: Wha?02:30
dufluRAOF: Hmm, why must they deprecate "register" when it would be less harmful to just ignore?... :S02:31
RAOFLinux.conf.au. Is in Perth in January, where I presume you will also be.02:31
dufluRAOF: Yes, I see. They fail to mention that on the main LCA site02:32
RAOFOh, that it will be in Perth? Really?02:32
dufluRAOF: Oops, that's linux.org.au that's out of date02:33
RAOFhttp://linux.conf.au/ says ‘Where: University of Western Australia’, which strongly suggests Perth :)02:34
duflu-org +conf02:34
dufluAnd you'll see it02:34
duflukgunn: This estimates work, I feel will take longer. But I also feel adding a few days may not improve the accuracy of my findings. I have a lot to learn about libmirserver and our approach to "buffers" still03:33
kgunnduflu: i hear you03:34
kgunnhmmm, anyone experienced using xmir just fine...then after rebooting once, seemingly u-s-c not starting, end up in vanilla x03:42
* duflu updates and tests03:46
robert_ancellRAOF, with your drm changes Mir no longer starts for me. It appears to be because it is picking card0 to use, which is the nvidia card in my laptop. It used to pick card1 because it prefererred intel over nouveau.03:48
robert_ancellRAOF, Q1 - should card0 work anyway?03:48
robert_ancellQ2 - How would we detect that card1 is the more appropriate card?03:49
RAOFrobert_ancell: Does card0 have any outputs attached?03:49
robert_ancellRAOF, how would I know?03:49
RAOFls /sys/class/drm03:50
duflukgunn: Yes, I'm now getting regular X with type=unity03:51
RAOFYou'll get a bunch of card0, card1, card1-$DISPLAY_CONNECTOR, and (if card0 is connected to anything) a bunch of card0-$DISPLAY_CONNECTOR03:51
dufluChecking for cause...03:51
robert_ancellRAOF, http://paste.ubuntu.com/5839255/03:51
robert_ancellNo DP - but otherwise the same?03:51
RAOFYup, you've got output attached to both.03:51
RAOFOr, at least, *connectors* attached to both.03:52
duflukgunn, robert_ancell: Yup, lightdm 1.7.5bzr1634saucy0 is not starting the system compositor. It's using legacy X even with type=unity03:52
RAOFWe've previously determined that you don't have a vga_switcheroo debugfs switch to frob, haven't we?03:52
dufluGot a bug yet?03:52
robert_ancellduflu, and the logs say?03:52
* duflu looks03:52
robert_ancellRAOF, last we tried I don't think I had any switches..03:53
RAOFrobert_ancell: So, there's already a herustic in there to not start on any GPU which doesn't have any connectors, and that fixes *my* laptop.03:54
robert_ancellRAOF, the specific thing it's failing on is gbm_surface_lock_front_buffer, not sure if that helps at all03:54
duflurobert_ancell: lightdm logs say starting USC, but silently does not and uses plain X... ?03:55
robert_ancellduflu, can I see?03:55
duflukgunn: Can you log a bug for it?03:55
RAOFI'm not sure why it'd fail there, although possibly because we're doing something stupid and asking for an invalid framebuffer, like 0x0.03:55
kgunnduflu: i saw same in the log...just complains no usc start03:56
RAOFrobert_ancell: To fix this in general I think we need to create a GBM backend for each GPU, actually probe the connected outputs, and bring up display on each connected output. This would fix your case because your nvidia card has no connected outputs (although it does have connectors)03:56
kgunnwill do03:56
duflurobert_ancell: USC log shows command line help, as if lightdm is giving bad options03:56
dufluAt least fallback works :)(03:56
robert_ancellduflu, sounds like you have an old u-s-c that doesn't support the vt option03:57
duflurobert_ancell: No, the command line help mentions vt03:57
robert_ancellduflu, and what does lightdm.log say the command line was?03:57
duflurobert_ancell: This is getting messy. I'll put it in a bug03:58
dufluIn kgunn's bug03:58
robert_ancellRAOF, can I do anything to debug from this end?03:59
duflurobert_ancell: USC doesn't understand --{from,to}-dm-fd03:59
robert_ancellduflu, huh, that's weird04:00
dufluGlad to see automatic fallback is seamless tho04:00
robert_ancelldid something change in the option parser code?04:00
dufluNo idea04:01
robert_ancellRAOF, i.e. is this just a matter of putting more code into is_appropriate_device?04:04
RAOFrobert_ancell: We could do a full output probe in is_appropriate_device; I think that would fix it for you.04:06
robert_ancellRAOF, what's the API for that? I'll hack it up here04:07
RAOFrobert_ancell: You want to pull the drm fd opening bits out of int mggh::DRMHelper::open_drm_device(UdevHelper const& udev)04:07
RAOFThen set_master on that fd (see int mggh::DRMHelper::open_drm_device(UdevHelper const& udev))04:08
RAOFThen do the actual probe - kms_display_configuration.cpp and drm_mode_resources.cpp have that code.04:10
ubot5`Launchpad bug 1197232 in Unity System Compositor "Lightdm can't start Mir (unity-system-compositor) and falls back to legacy X" [High,Confirmed]04:10
kgunnoh...you already saw it04:10
RAOFrobert_ancell: Hm. I think you might be able to get away with just getting up the setting drm master bit, and then creating a KMSDisplayConfiguration from that fd.04:12
robert_ancellRAOF, ta04:12
RAOF(That list of steps should make it obvious that this is not a correct fix ☺)04:13
RAOFWoot! std::initializer_list!04:14
robert_ancellRAOF, but is that conceptually the right thing to do? i.e. open, set master, probe outputs, bail if there aren't any04:14
RAOFrobert_ancell: Conceptually the right thing to do is to open, probe outputs, and only put up displays on anything with an output.04:15
RAOFSo it's almost the right thing to do conceptually.04:15
robert_ancellduflu, looks like my --version change broke it..04:16
RAOFie: the end state that we need to be in is for the GBM platform to have all the drm devices open, and handle that appropriately.04:16
robert_ancellRAOF, that's what X does right? (according to the X log)04:17
RAOFWell, except I don't know if it handles two gpus, both of which have connected outputs.04:18
robert_ancellduflu, kgunn, was this from the staging or the system-compositor-testing PPA?04:24
kgunnrobert_ancell: i'm pinned to system-comp-testing04:25
robert_ancellduflu, fix is https://code.launchpad.net/~robert-ancell/unity-system-compositor/fix-dm-fd-options/+merge/17272904:26
robert_ancellBoost options uses some weird templating stuff.04:26
robert_ancellDoes anyone know why std::cerr doesn't seem to work from inside the gbm code?04:28
duflurobert_ancell: SCT PPA04:30
RAOFrobert_ancell: It sholud work inside the gbm code? It worked for me when I was doing printf debugging.04:34
RAOFrobert_ancell: Although if you're running ‘make test’ then that eats all test output, for maximal annoyance.04:34
RAOFAlthough now *I* can't get cout or cerr to print anything?=04:40
robert_ancellRAOF, yeah, odd right!>04:41
RAOFHah, no false alarm.04:42
RAOFexception raised before it would have printed something04:42
RAOFNope, works fine here.04:45
robert_ancellRAOF, maybe I did the same thing04:46
tvossgood morning :)05:22
tvossRAOF, robert_ancell for maximum make test noise, try ctest -V :)05:23
* RAOF stalks robert_ancell05:43
dufluWow Mir builds really quick when the tests are disabled for you ;)05:51
RAOFrobert_ancell: It's possible that I've mislead you, and there's something cheaper we could use as a herustic.05:52
RAOFrobert_ancell: Can you pastebin the output of running "umockdev-record /sys/class/drm/card*"?05:52
robert_ancellRAOF, I seem to have it working05:52
RAOFAh, sweet.05:53
robert_ancellRAOF, see lp:~robert-ancell/mir/gbm-check-connections and see if that makes sense05:53
robert_ancellI don't think we need DRM master unless we're actually rendering something05:53
RAOFThat'd be true. Or, rather, unless we're trying to change the mode.05:54
robert_ancellIt works for me, but I'm trying to fix the tests05:54
robert_ancellcard0 has 0 connections, and card1 has 1 so it picks that one05:54
dufluOh, it's a Wednesday so Mir doesn't work again :(05:55
dufluMy fault for updating... something...05:55
* duflu reboots05:56
robert_ancellduflu, hikiko, racarr, alf, kgunn, tvoss, thomi, meeting06:00
robert_ancellkdub, too06:01
tvossrobert_ancell, mind adding me to the hangout, would like to join on the ipad06:01
duflubye, Bye, BYE, by06:28
dholbachgood morning06:42
dufludholbach, hi06:42
dholbachhey duflu06:42
dufluRAOF: glDrawArrays now SIGSEGV's for me in Mir clients :(06:43
dufluThat's raring, maybe saucy is still good06:43
* duflu checks06:43
dufluNop, saucy is broken too06:45
ubot5`Launchpad bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,New]06:49
dufluRAOF: What changed in Mesa?... Or should have changed? https://bugs.launchpad.net/mir/+bug/119726006:58
ubot5`Launchpad bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,New]06:58
RAOFI'm not sure; investigating.06:59
dufluBecause the lp:mir that worked yesterday doesn't any more. The only thing I changed was my Mesa debs from PPAs06:59
RAOFI don't think I changed anything in the Mesa ppas?07:00
RAOFduflu: Most recent build of Mesa was on the 28th.07:01
dufluRAOF: Yeah I have avoided system updates for a few days for this kind of reason07:02
dufluRAOF: Still looks like Mesa07:02
RAOFKindly wait while my internet pigeons grab me the crumbs my router will reassemble into the PPA's packages so I can test the latest stuff.07:03
dufluOh that reminds me07:03
* duflu sends another email07:03
RAOFMan, your internet is so awesome!07:08
dufluI think my copper has gaps, and I'm relying on slightly moist soil in between07:11
RAOFTroubling in Perth. You'll lose all internet in the summer!07:13
dufluRAOF: Oddly, Summer is when it last worked properly07:31
dufluSo my hypothesis must be wrong07:31
RAOFPossibly you're missing some insulation, so it's grounding when the soil is moist.07:32
dufluRAOF: Well if Telstra don't find/fix a problem I have a lot of wiring to experiment with :(07:32
* duflu doesn't want to have to rig up a phone socket in the front garden just to prove a point :P07:36
alfmlankhorst: Is the dmabuf system memory pinning issue for gallium or radeon only?07:45
mlankhorstfor ttm07:46
mlankhorstso strictly speaking nouveau too07:46
alfmlankhorst: ok, so intel escapes :)07:46
dufluSounds like a big deal. We may as well just have shm :)07:47
mlankhorstwell that's pretty much it07:48
duflualf: How is a "Prime" fd guaranteed valid across processes?07:48
alfduflu: we send it as we would any fd, through unix sockets07:49
* duflu still doesn't get it. The allocation of the fd number is local to the client. So how does it work coming from the server process?07:49
alfduflu: the client gets a different fd, which is backed by the same internal file information internally in the kernel (like when you dup())07:56
alfduflu: so it's a cross-process dup()07:56
duflualf: OK. So I missed the part where the fd int changes...07:57
duflugrayback: Someone said you had similar issues to https://bugs.launchpad.net/mir/+bug/119726008:06
alfgreyback: FYI, duflu encountered a similar problem with the one you had yesterday with Mir egl clients, and RAOF is looking into it08:06
ubot5`Launchpad bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,New]08:06
duflugreyback, ^08:06
alfduflu: talk about perfect coordination :)08:07
duflualf: I am disturbed by the synchronisation of our thoughts08:07
dufluBut it might be handy08:07
greybackalf: duflu: thanks for the update! I managed to get a working system from an older spin, so I'm ok for now08:07
duflugreyback: What worked for you? Was it Mesa updates?08:08
dufluOr "down-dates"?08:08
greybackduflu: older mesa release08:08
dufluCool, thanks08:08
dufluRAOF: FYI ^08:10
tvossduflu, alan_g, RAOF so what is a good way forward to handle the issue of missing build-dependencies for tests?08:33
duflutvoss: I was going to just improve the CMakeLists around the place to disable the tests that are untestable08:33
dufluAnd keep as much as possible enabled08:33
alan_gIf build dependencies are missing cmake should report it08:34
alan_g(by failing)08:34
tvossI think we all agree that just disabling tests is a bad idea. My pov: build fails when tests cannot be built and run. The tests are as important as the actual code08:34
duflualan_g: Yeah it will always be reported. Just as warning, not error08:34
alan_gwarnings get ignored08:34
alan_gIt needs to be an error08:34
tvossduflu, I'm not entirely sure that this scales. We add a massive amount of logic to the build system setup just to end up in a situation where we potentially disable all tests anyway08:35
duflutvoss: I disagree. Outside of Ubuntu NO ONE will care about test failures. Same as when you're packaging any project from an external upstream.08:35
dufluPeople don't run tests. They rely on the maintainers to run tests and verify they pass08:35
tvossduflu, then we can as well have an option: MIR_DISABLE_TESTS08:35
duflutvoss: I think disabling all tests is a bad move. I'm happy to make it possible to run as much testing as possible08:36
dufluHmm, maybe I need to not sound like I'm arguing both sides08:36
tvossduflu, well, if no one is going to run the tests except for us, we shouldn't invest the time/effort/hassle to make it possible for them :)08:37
duflutvoss: It's for me, I am going to fix it :)08:37
dufluI care about test failures. Other distros don't. I mean...08:37
tvossduflu, let's just have an option MIR_DISABLE_TESTS_DURING_BUILD that people can explicitly request08:38
tvossduflu, if that option is set, we skip the checks for test build-deps anyways and everyone is happy08:38
alan_gduflu: tvoss - alf has thoughts too: https://bugs.launchpad.net/mir/+bug/1196987/comments/308:38
ubot5`Launchpad bug 1196987 in Mir "Most tests are silently disabled if libumockdev-dev is missing" [Medium,Confirmed]08:38
duflutvoss: OK, so long as tests are enabled by default. And preferably avoiding double negatives (don't call it "DISABLE")08:38
dufluCall it MIR_ENABLE_TESTS (default true)08:39
tvossduflu, @double negatives: fair point, it is MIR_ENABLE_TESTS08:39
dufluThen I will add more granularity when I get around to it...08:39
tvossduflu, fair, but as you said: only we care about the tests, external packagers most likely will not care08:39
duflutvoss: Remind me why you need the option? We already skip *all* tests when umockdev is missing. That's enough for other distros too08:40
tvossduflu, yup, but I want to make it an explicit and conscious choice instead of taking that decision automatically08:40
tvossduflu, if someone switches the option to OFF, I would like to have a big warning on the terminal that it is a bad idea08:40
duflutvoss: Hmm, oookaaay. So long as the CMake error tells the user how to disable them :)08:41
alfalan_g: duflu: tvoss: this is a chance to make some of our other dependencies (e.g. gmock) test only dependencies, i.e., don't fail if gmock is missing nad MIR_ENABLE_TESTS=false08:41
dufluIt's a good first step. And one we have time for right now08:41
tvossalf, sure, I think the dep checking for tests should be moved to subdirectory tests in the respective CMakeLists.txt, and we only inlcude that subdirectory if the enable option is ON08:42
tvossduflu, +108:42
* alan_g so long as cmake fails by default if anything (including tests) can't be built and run 08:42
tvossalan_g, that's the plan08:43
dufluAnd it's made very clear to the user *how* to build without the tests, and get over the line08:43
tvossduflu, that's definitely doable08:43
alan_gduflu: and equally clear which dependencies are missing08:44
tvossalan_g, can you look into adding the respective option?08:44
dufluAlright. Tests enabled and passing means "The Mir team fully expects Mir to work on this system". Anything else and we make no guarantees08:45
alan_gtvoss: sure (although duflu has grabbed the bug)08:45
dufluAlthough, AFAIK you can successfully build Mir without the requisite Mesa changes :)08:45
duflualan_g: Not as of 2 minutes ago08:46
tvossalan_g, have fun then :)08:46
dufluSigh. I think I just agreed to having to do all future Mir work on my slow saucy machines :P08:46
=== yofel_ is now known as yofel
alan_gduflu: @"AFAIK you can successfully build Mir without the requisite Mesa changes" - sounds like missing tests08:47
duflualan_g: Not sure. Needs checking08:47
dufluAlso, that's a question we should all know the answer to08:48
dufluBasic Mir dependencies...08:48
alan_gduflu: +108:48
duflualan_g: You (or someone) restyled doxygen? ... http://unity.ubuntu.com/mir/index.html08:52
alan_gduflu: ack08:53
duflualan_g: Feels a bit better08:53
alan_gduflu: glad you like it.08:55
duflualan_g: I think the function docs feel cluttered still. But that's likely only because so many lack documentation and it's just headers08:57
hikikoalan_g, can I ask you something for mir on mir?08:57
alan_ghikiko: sure08:58
alan_gduflu: there's more to be done, but that got things closer to "house style"08:59
RAOFNeeds more aubergine :)09:00
tvossRAOF, ;)09:00
tvossRAOF, please file a bug ;)09:00
* alan_g ducks09:00
* tvoss thinks that it might be possible to get rid of the weird -DBOOST_ASIO_DISABLE_* cpp definitions for the package build09:01
hikikoI have the following issue: I was starting the nested server and then the nested was connected to the host server, but the result wasn't exactly a nested server but mostly a connected one, so I moved the code to the mir_demo_server example and performed the connection before anything and the result was much better but! I'd like to do it properly and move the connection code to the mir initialization, so I wonder if you can give me an idea on where09:01
hikiko to look at... (I saw that there's the run_mir.cpp and DisplayServer in src/server do you think is this the right place?09:01
dufluRAOF: A little bit: http://design.ubuntu.com/brand/colour-palette#the-amount-of-colour-we-use09:03
alan_ghikiko: I don't follow "the result wasn't exactly a nested server but mostly a connected one"09:03
hikikowell it was running on a different tty09:03
hikikobut it was connected to the mir server09:03
hikikobecause the connection was performed after the server was starting09:04
hikikoif I move the code at the beginning of the mir_demo server09:04
hikikothe nested_mir appears inside the host server09:04
hikikowhich I guess is what we want09:04
hikikoso, I'd like to remove the connection from the demo_mir_server09:05
hikikoand put it somewhere in the mir startup09:05
alan_ghikiko: let me have a look at your code and we'll hangout in half an hour?09:06
alan_gWhich branch?09:06
hikikoyes but let me push a recent version in 5 minutes09:06
hikikothis one09:07
alan_ghikiko: let me know when you've pushed09:07
dufluHmm, it seems a lot of people are jumping in to mir_demo_server because of its name. When they actually would benefit from mir_demo_server_shell instead. I think we have a minor communication issue09:08
duflu_shell sounds like a shell but we need to communicate it is a _server too09:09
hikikoyou can start looking at it if you have some time the changes aren't big I was just moving the connection part here and there :) pushed right now :)09:10
RAOFBah, stupid mesa.10:35
dufluBah, dinner10:46
dufluThat doesn't even make sense10:46
=== alan_g is now known as alan_g|afk
alfRAOF: alan_g: I was thinking... Mesa doesn't need to link to libmirclient, it just needs some headers. It does need access to the  mir_egl_mesa_display_is_valid() symbol which is provided either by libmirserver or libmirclient, but it can pick that up automatically during dynamic linking.11:23
alfRAOF: alan_g: which I guess is another reason to not link to libmirclient...11:23
=== alan_g|afk is now known as alan_g
alftvoss: @mesa, I think the best way (at least the best that has come up so far :)), is for mesa to dlopen(NULL), dlsym("mir_server_egl_mesa_display_is_valid"), dlsym("mir_client_egl_mesa_display_is_valid") and try all of the available mir_*_is_valid() functions when checking.11:42
tvossdidrocks, hey there, looking at pulling out gmock again. Remind me, is the ftbfs for gmock fixed, yet?12:05
didrockstvoss: the fixed package is available on the link I gave you12:05
didrockstvoss: but all projects needs now to build their own gmock from this source, no more shared library12:05
didrocksso we nede to patch the rdepends12:05
tvossdidrocks, trying to get the rdepends but apt-rdepends tells me that it cannot resolve reverse build-deps12:08
didrockstvoss: try reverse-depends -b12:09
tvossdidrocks, and I'm only looking into main, right?12:10
didrockstvoss: no, we'll need everything to be ported12:12
didrockstvoss: otherwise, we can't move further along12:12
tvossdidrocks, ack12:13
tvossdidrocks, however reverse-depends -b is a manageable list12:13
didrockstvoss: it is, just need to have time for it :)12:13
tvossdidrocks, fair. so could we live with mir carrying its internal gmock version when entering universe and treating as another reverse build-dependency of gmock once we landed?12:15
didrockstvoss: no, we can't get it with this internal version12:16
tvossdidrocks, why is that?12:17
didrockstvoss: because it's not what we do for components in the distro12:17
didrockstvoss: and we know that with time pressure, we'll overpass it12:17
didrocksthis already happened in the past12:17
didrocksso let's try to have it ready before entering12:17
didrocksknowing that step1 is having it building on armhf and powerpc anyway :)12:17
tvossdidrocks, we have got a problem then: no one has time to fix the reverse-build-dependencies of gmock, but mir needs the fixed gmock version12:18
tvossdidrocks, how can we push forward here?12:18
didrockstvoss: well, find time for it12:18
didrockswhich isn't going to happen if we spend all our time discussing about it12:19
didrocksthere are enough other blockers anyway on the list, this one shouldn't be the priority right now12:19
didrocksthe armhf and powerpc ones should be12:19
tvossdidrocks, for the powerpc ones. I thought we agreed that we disable the tests on powerpc?12:24
didrockstvoss: yeah, it just needs to get done12:24
tvossalan_g, we might want to use the MIR_ENABLE_TESTS option for that, too :912:24
tvossalan_g, are you looking into that option?12:35
=== greyback is now known as greyback|lunch
=== harrow` is now known as harrow
hikikohi, question: what does the gbm/gbm_display.cpp configure() function?12:57
hikikoI am trying to understand if I need something like that for mir-on-mir because if I leave the func completely empty I get compile errors12:58
=== greyback|lunch is now known as greyback
alan_gtvoss: preview here: https://code.launchpad.net/~alan-griffiths/mir/fix-1196987/+merge/17279813:02
alfhikiko: It configures the displays (e.g. sets up the monitor etc). You will eventually need to implement it, but probably don't need it right now. What error do you get?13:02
hikikoalf, https://pastebin.canonical.com/93745/13:05
hikikoi think it's irrelevant13:06
hikikosorry :)13:06
alan_galf: are we intending to use libumockdev for anything other than unit tests?13:16
alfalan_g: We may want to use it for tests in general, not just unit tests.13:27
alan_galf: I suspected as much. ;)13:28
alan_galf: do you know of a better option than the LD_PRELOAD=libumockdev-preload.so ugliness?13:29
alan_gI really hate it that running unit-tests produces a core13:31
alfalan_g: The idea I had in mind was to create a MockUdev object (like we have MockGL), and forward the udev calls to symbols dlsym()-ed from a dlopen()-ed libumockdev-preload.so13:31
alfalan_g: which is not less ugly, but at least it is hidden :)13:32
alan_galf: thinking about it - how can *unit* tests depend on umockdev?13:32
alfalan_g: But I need to check if this will actually work as expected13:33
alan_gSure. I'm going to file a bug - feel free to grab ownership.13:33
alfalan_g: We are using a link-time seam for udev13:33
alan_galf: my point was that *unit* tests shouldn't be hitting udev13:34
alfalan_g: Well, link seams blur the line between unit and integration tests.13:40
alan_galf: OK. I've just logged the broken LD_PRELOAD seam. Not going to get into the unit/integration test debate.13:43
alfalan_g: thanks, btw, the direct use of udev in the display-configuration-change-handler MP, will go way when RAOF's C++ Udev classes land, hopefully along with an interface we can inject and mock.13:45
alfalan_g: At least, that's my plan :)13:47
alan_galf: cool.13:49
alan_galf: hikiko: There's a lot of info floating around "in people's heads" - we should reinstate the daily standup to keep folks in the loop. (Let's have a EU one at least.)13:49
alfalan_g: we can do it at 16:00 UTC (as before) to allow US people to join if they want to.13:53
alfalan_g: actually 16:00 UK time not UTC13:54
alan_gSure. A 5 minute hangout at 15:00UTC/17:00CET13:56
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
kdubyay, flipped images16:11
kdubvery cool :)16:23
kdubracarr, ping16:23
kdubalso, what if we had a policy that for interface Interface...16:34
kdubwe mock it using gmock and call it MockInterface16:34
kduband then typedef a NiceMock of MockInterface, calling it StubInterface16:35
kduband put all that in the include/test/mir_test_doubles/mock_interface.h file16:35
=== alan_g is now known as alan_g|EOD
=== seb128_ is now known as seb128
kgunnbregma: hey, i know arm builds were angry due to expecting valgrind....do you know what the proposed solution is ?....is it simply a option/switch on mir tests ? (e.g. was tvoss proposing some MIR_ENABLE_TESTS option fot that)20:02
bregmaI have a patch that just switches off tests with valgrind (the trivial solution) but one of the tests hangs (valgrind or no) on a deadlock condition, I've spent the last 2 days trying to track it down20:04
bregmain particular, TestClientIPCRender.test_accelerated_render deadlock on my arm device (an N7)20:05
kdubbregma, that test actually drives the driver... might be an actual bug on the n720:06
bregmamaybe, but valgrind actually spews a whole lot of double delete errors before the hang, so it's possible there's a code fault20:06
bregmaat this point I may just suggest that test be disabled until someone with more in-depth knowledge can look at it20:07
bregmait stymies me20:07
kgunnbregma: let's get didrocks ok with that....i will help convince :)20:28
bregmaI'll keep poking at it until he agrees20:29
* bregma gnaws at problems like a dog at a bone20:29
=== bschaefer_ is now known as bschaefer
mterryrobert_ancell, heyo!  So we talked about the greeter-mir API as being over DBus.  Mir doesn't seem to use DBus at all right now, is that right?21:03
robert_ancellmterry, correct, but the API would be to u-s-c, not Mir21:03
robert_ancelltvoss, around?21:06
mterryrobert_ancell, ah21:16
greybackracarr: ping21:19
racarrgreyback: Pong21:21
greybackracarr: hey, I might be mis-understanding SessionListener, but in the code I've written I'm not being notified of new sessions. Can you have a look: lp:~gerboland/+junk/qml-demo-shell/21:22
greybackracarr: see unity-mir/shellServerConfiguration_p.h for where I register a SessionListener21:23
racarrgreyback: Looking21:23
mterryrobert_ancell, anyway, same deal.  No current dbus use.  So I'll just make something up interface wise and you can correct me during review21:23
robert_ancellmterry, yep21:23
racarrgreyback: It's "the_shell_session_listener"21:24
racarrthat you need to override21:24
racarryou can use override keyword in C++1121:24
racarri.e. like21:24
racarrthe_session_listener() override21:24
racarrto get compile errors21:24
greybackracarr: ah was that it. Damn21:24
racarron stuff like this21:24
racarraha, no worries. I lost so much time to stuff like this before we switched to a G++ that supported override21:25
greybackmust've missed that. Ok21:25
* greyback kicks himself21:25
kdubits interesting how good your eyes get at scanning g++ explosions quickly22:29
kdubRAOF, I implemented that change we were talking about yesterday where input channel and surface info are submitted separately to the input system22:59
kdubdefinitely makes for nicer interfaces :)22:59
kdubthomi, do we have the infrastructure to get the nexus 4 tests run in our CI?23:06
thomikdub: let me ask, one second23:07
kdubcool thanks :)23:07
robert_ancellkdub, https://code.launchpad.net/~kdub/mir/cross-compile-script-boost-version/+merge/172686 - libboost-chrono-dev depends on libboost-chrono1.53-dev (and will be updated as future versions come out)23:09
robert_ancellSo agree with Alan here, if we don't care for a specific version, just use the unversioned -dev packages23:09
robert_ancellI wasn't sure if we intentionally had the specific versions for a reason, I have heard boost is somewhat API unstable23:10
kdubrobert_ancell, yeah, i just have to figure out boost's packaging a bit better to download what I need23:11
robert_ancellracarr, ping23:19
mterryrobert_ancell, so in u-s-c, what libraries are allowed?  glib is probs out.  So I imagine is Qt?23:34
mterryrobert_ancell, just looking at dbus solutions for c++23:35
robert_ancellmterry, I guess Qt is OK? We can always swap out later if a problem23:35
robert_ancellmterry, glib would be fine since lightdm is using it anyway23:36
mterryrobert_ancell, ok, that's easier than I thought.  I'll look at QtDBus first23:37
mterrymore c++y23:37
robert_ancellyeah, probably will fit better23:37
=== Debolaz is now known as Guest43193
racarrrobert_ancell: Pong23:51
robert_ancellracarr, hey, do you get the opposition to putting the pid in the protocol?23:53
kdubi was just writing a comment on that one :)23:59
RAOFmterry: tvoss has a super-funky C++ dbus library under development, you could find that :)23:59
racarrrobert_ancell: Sort of23:59
racarrI think the same way FDs are passed over the protocol in a side band23:59
racarryou could say the client credentials are23:59
mterrysuper funky eh?23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!