[00:00] <RAOF> sturmflut: You can install the mesa packages to ~/.local and it's entirely safe (you then need to export LD_LIBRARY_PATH=$HOME/.local/lib to run things)
[00:02] <sturmflut> thomi, RAOF: Okay, thanks. I think I'll go to sleep for today (it's 1 am here in europe) and if the packages are not ready for my next try I'll look into building my own Mesa
[00:04] <thomi> sturmflut: unless something goes very wrong they should be there for your morning
[00:04] <sturmflut> New day, new Mesa
[00:13] <sturmflut> thomi: Looks like mesa-9.1~rc2-0ubuntu0+mir2-jenkins18 failed on amd64 and i386, or am I reading the results wrong?
[00:13] <robert_ancell> cgoldberg, nice, thanks!
[00:14] <thomi> sturmflut: yes, it seems it can't find mir_client_library.h
[00:14] <thomi> I wonder if that file has moved recently
[00:15] <robert_ancell> thomi, it has moved to <mir_toolkit/mir_client_library.h>
[00:15] <thomi> robert_ancell: hmm, then it looks like the mesa source hasn't been updated?
[00:16] <robert_ancell> thomi, probably likely
[00:16] <thomi> dri/src/egl/drivers/dri2/egl_dri2.h line 69
[00:17] <thomi> robert_ancell: who's the best person to fix that in mesa?
[00:17] <robert_ancell> thomi, I think RAOF or alf?
[00:17]  * thomi looks pointedly at RAOF
[00:25] <thomi> hmmm, ok, so there's some odd setup on our jenkins machine - we don't appear to be pulling down new mesa sources at all.... unless it's hidden away in a cron job somewhere
[00:35] <RAOF> thomi: I *did* test-build the mesa changes locally :)
[00:36] <thomi> RAOF: yeah, there's something really funky happening here :-/
[00:37] <thomi> it looks like someone had some fun getting around the fact that the jenkins server can't access freedesktop.org :)
[00:39] <RAOF> It doesn't need to access freedesktop.org? Just github.
[00:40] <thomi> RAOF: http://www.mesa3d.org/repository.html lists the mesa repository as git://anongit.freedesktop.org/git/mesa/mesa - is that innacurate?
[00:40] <RAOF> No, that's accurate. But that's not where the branches for Mir are.
[00:41] <RAOF> Because I don't have commit access there :)
[00:41] <RAOF> thomi: You're looking for https://github.com/RAOF/mesa - mir-ppa and mir-ppa-quantal branches.
[00:46] <thomi> RAOF: is that mirrored on launchpad at all?
[00:47] <RAOF> thomi: No
[00:48] <RAOF> thomi: Because it can't, because you can't import not HEAD branches.
[00:48] <thomi> oh :(
[00:49] <RAOF> It'd apparently be a couple of weeks work to fix bzr-git enough so that it worked, but we don't invest in bzr-git anymore :(
[00:49] <thomi> yeah :(
[00:50] <thomi> I'm looking at building a source package manually and dputing that to the PPA for today,a nd I'll find out what the story is here
[01:07] <kdub> hey duflu, could you give https://code.launchpad.net/~mir-team/mir/consolidate-crossbuild-scripts/+merge/154762 another look?
[01:08] <duflu> kdub: Will do, today
[01:08]  * duflu goes to get coffee
[01:08] <kdub> duflu, thanks
[01:44] <sturmflut> RAOF: I'll wait until the mesa packages are updated in the PPA, I built Mesa from your github repository branch but after setting LD_LIBRARY_PATH i get "symbol lookup error: /usr/lib/x86_64-linux-gnu/libGLESv2.so.2: undefined symbol: _glapi_tls_Dispatch" upon running anything
[01:45] <RAOF> sturmflut: That suggests that you either haven't installed it into the right path, or you haven't built it with the right options. Mesa has approximately 3 hojilion build options, so that's not hard. :/
[01:45] <sturmflut> Hooray
[01:45] <sturmflut> I foolishly thought I could get away with ./configure --prefix=/opt/mesa --with-egl-platforms=mir
[01:48] <sturmflut> RAOF: Okay, I forgot --enable-gles2
[01:52] <RAOF> You may wish to add --with-dri-drivers=i965 --with-gallium-drivers= (if you've got intel) or --with-dri-drivers= --with-gallium-drivers=r600 (or r300, or nouveau, if you've got one of those)
[01:53] <RAOF> For reference, my most recent build:
[01:53] <RAOF>  PKG_CONFIG_PATH=$HOME/.local/lib/pkgconfig ./autogen.sh --prefix=$HOME/.local/ --enable-gles1 --enable-gles2 --with-dri-drivers=i965 --with-gallium-drivers=swrast --enable-shared-glapi --enable-glx-tls --with-egl-platforms=drm,mir,x11
[02:01] <sturmflut> RAOF: Thanks, it is finally working again!
[02:02] <RAOF> Sorry for having it broken for so long. I'm going to break it again soon; hopefully not for as long :)
[02:06] <sturmflut> At least now I can confirm that glmark2 works on Mir
[02:11] <duflu> robert_ancell: Seems I'm not getting new Mir bug mail now... ?
[04:01] <duflu> RAOF: Much badness :(  https://bugs.launchpad.net/mir/+bug/1161196
[04:01] <ubot5> Launchpad bug 1161196 in Mir "All Mir demo clients using GL crash in eglInitialize()" [Critical,New]
[04:03] <RAOF> duflu: PPA skew. The latest mesa isn't built in there. If you build from github you'll get a working GL.
[04:04] <RAOF> Man, we really need eye-tracking-based focus detection.
[04:04] <duflu> RAOF: Umm, kay. What are the options for not having to build Mesa from source? The old rocket-scientists PPA worked
[04:05] <RAOF> The old rocket-scientists PPA won't work now; racarr's EGL changes landed, which were incompatible with the previous Mir EGL platform.
[04:05] <duflu> RAOF: OK, so same question :)
[04:06] <RAOF> duflu: Options include: having *me* build from source for you, or debuilding out of the mir-ppa branch on github; that'll get you packages you can install.
[04:06] <duflu> RAOF: Ah, OK. debuild is less painful
[04:06] <duflu> RAOF: So what do we expect the public to do if the public PPA no longer works?
[04:07] <RAOF> We expect the public PPA to work.
[04:07] <RAOF> The fact that it currently doesn't is (a) a bug, and (b) transitory.
[04:07] <RAOF> thomi's working on restoring the mesa autobuild, which silently broke.
[04:08] <duflu> RAOF: Sweet, ta. I will work around it till after Easter
[04:09] <RAOF> Actually, I can help there - I'll just upload to the PPA. We don't have to wait for autolanding.
[04:11] <duflu> RAOF: How goes Mesa upstreaming progress?
[04:11] <RAOF> Waiting on landing the dma-buf branch.
[04:12] <RAOF> Since that changes the client ABI there's little point in landing in mesa before that.
[04:13] <RAOF> Oh, boo. That's right. Stupid jenkins versioning.
[04:22] <duflu> RAOF: It's OK. demo_client_unaccelerated suffices for me today
[04:22] <thomi> RAOF: new mesa packages are now in the PPA for i386 and amd64
[04:23] <thomi> it might be a few days before the autobuild is back up and running. In the mean time, I can manually dput new mesa packages if you need them
[04:35] <RAOF> duflu: Yeah, -jenkins19 in the PPA now should work, I think.
[04:35] <RAOF> Care to test?_
[04:36] <RAOF> GAH! Eye-tracking based focus, please!
[04:50] <duflu> RAOF: Yeah will test it soon thanks
[04:59] <racarr|lunch> https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888 exists
[04:59] <racarr|lunch> Oh wow...racarr|lunch
=== racarr|lunch is now known as racarr
[05:00]  * RAOF presumed racarr was just having a super-long lunch :)
[05:00] <racarr> best lunch EVER
[05:11] <duflu> RAOF: EGL works ta
[05:41] <RAOF> Time for a last burst of SWIV:ANH-driven-development.
[05:42] <racarr> ?
[05:42] <RAOF> Does anyone else see the unittests sometimes failing to complete?
[05:42] <RAOF> racarr: Star Wars IV: A New Hope.
[05:43] <racarr> ah!
[05:43] <RAOF> An excellent way to add atmospheric music to your test runs!
[05:43] <racarr> "Christopher, we see you've disabled your test runs is everything alright?
[05:43] <racarr> "
[05:44] <RAOF> "Everything's fine" :)
[05:45] <smspillaz> the next big thing:
[05:45] <smspillaz> http://scottberkun.com/2007/asshole-driven-development/
[05:45] <smspillaz> productivity up 200%!
[05:50] <RAOF> Dear C++: I wish you didn't have to recompile all the reverse-dependencies when I change a private member.
[05:50] <smspillaz> RAOF: don't expose private members in header filex kthxbye
[05:50] <smspillaz> *files
[05:50] <smspillaz> (even under private:)
[05:50] <smspillaz> :p
[05:50] <RAOF> But pimpl is such a drag!
[05:51] <RAOF> It even _sounds_ bad :)
[05:51] <smspillaz> I think that's why nobody uses it
[05:51] <smspillaz> someone though "haha, pimpl, thats a funny name"
[05:51] <smspillaz> and then the image that it puts in your head
[05:51] <smspillaz> makes you not want to use it
[05:52] <RAOF> Which is odd, because it's the _obvious_ implementation pattern for C.
[05:52] <smspillaz> RAOF: I want to invent a language that:
[05:53] <smspillaz> 1) has a very clear distinction between object and value types. Value types have public members, objects always have private members held by indirection
[05:53] <smspillaz> 2) Doesn't allow for global variables or side-effects. All changes must happen throuhg interfaces provided in either the object's constructor or the function signature
[05:54] <smspillaz> basically C++ the right way and no other way
[05:54] <smspillaz> the problem is that the "right way" is a fluid concept
[05:54] <duflu> Funnily enough, pimpl is widely used in C APIs. Except it's not called pimpl, it's just called good API design
[05:54] <RAOF> Exactly my point :)
[05:54] <smspillaz> also it should allow you to implement an interface and delegate that entire interface to a held object
[05:55] <smspillaz> so that composition is not a total pain to write
[05:55] <RAOF> smspillaz: The latter constraint sounds like you're secretly after a functional language :)
[05:55] <duflu> smspillaz: You're asking for Go, right?
[05:55] <smspillaz> duflu: kinda
[05:55] <smspillaz> I don't really like the "you implement an interface implicitly" thing in Go
[05:55] <duflu> smspillaz: Or Lisp for a purely functional language for doing your head in
[05:56]  * RAOF needs to prod #debian-cli to upload F# to experimental
[05:56] <smspillaz> you should be able to say "I am implementing this interface, but I want to delegate my implementation to this object"
[05:58]  * RAOF isn't sure how useful that would really be
[05:59] <smspillaz> RAOF: incredibly useful
[05:59] <duflu> smspillaz: I've been thinking recently that maybe the problem is that an "interface" is too coarse. Maybe you should be able to delegate interface methods
[05:59] <smspillaz> duflu: right, that would be the idea
[06:00] <smspillaz> so if you had a Interface { public: virtual ~Interface () {} virtual void bar () = 0; virtual void baz = 0; };
[06:00] <duflu> smspillaz: Which you can do in C and C++. Just not as part of the primary syntax
[06:01] <smspillaz> duflu: right, you have to use function pointers to do it
[06:01] <RAOF> That sounds to me like syntactic sugar for something that's already pretty sweet.
[06:01] <smspillaz> and then an Object : public Interface { public: virtual void bar (); virtual void baz (); }
[06:01] <smspillaz> And then a MultipleObjectsInConcept : public Interface { private Object o; }
[06:01]  * duflu goes off to try do work instead of finding more bugs in Unity and Mir
[06:02] <smspillaz> It would be nice to have something in the language that said - "Every function that I say I provide in Interface should be routed directly to my member Object"
[06:02] <smspillaz> and then you can override the interface partially for where you needed to customize
[06:02] <smspillaz> rather than having to implement every single method, then call the method from Object
[06:03] <RAOF> smspillaz: But that's like three lines per method in the interface, including whitespace. I'm not sure that it's particularly onerous.
[06:03] <smspillaz> RAOF: its just more typing that doesn't need to happen really
[06:04] <smspillaz> and then every time you add a new method to that interface
[06:04] <smspillaz> you have interface sensitivity, and all the object that were just implementing it by delegating to a member have to go implement that method
[06:04] <duflu> Whoa... Maclisp existed a decade or two before the Mac ;)
[06:05] <smspillaz> RAOF: my ideal language would also support templates, but reduce the amont of code generation by making it so that template members had to conform to a statically determined interface, and then for shifting points around, the entire thing was treated as void * in the underlying code
[06:06] <smspillaz> so you could generate the code for std::list once (instead of per-type)
[06:06] <smspillaz> and then if the template needed to call methods on the objects, you generate the code once per interface and not once per derived type
[06:06] <RAOF> So, C# generics then.
[06:06] <smspillaz> yes
[06:06] <duflu> smspillaz: Yes I invented such an STL a few years ago. But then found prior art documented in Dr Dobbs magazine too
[06:06] <smspillaz> I think what I want
[06:06] <smspillaz> is Go#
[06:07] <smspillaz> duflu: ah cool. Link ?
[06:07] <duflu> smspillaz: Not handy
[06:07] <RAOF> I'm going to work through "Statistics for programmers" in F# once everything's landed for that to actually happen. I suspect it might match many of your desires. I'll tell you how it goes. :)
[06:09] <duflu> smspillaz: Though I do have a working re-implementation (not owned by IBM), I'm not willing to share that yet
[06:11] <smspillaz> duflu: this is the point where you quit your job and make lots of money :p
[06:11] <duflu> smspillaz: No that's a different project, which for legal and financial reasons I have not touched in ~2 years
[06:11] <smspillaz> I figured it was something like that
[06:12] <duflu> I know! Let's make an app for the braindead. Those make squillions!
[06:13] <smspillaz> duflu: I'm always disappointed by the market
[06:14] <duflu> Bah, marketing is about understanding people. Not what is arguably right...
[06:14] <smspillaz> the people who come up with solutions to trap and collect plastic in the oceans get less attention than people who make apps
[06:14] <smspillaz> duflu: I watched the interview on 7:30 last night
[06:14] <smspillaz> I loved the bit where he was like "I had this idea ... so I hired a bunch of really smart people"
[06:14] <smspillaz> and the headline is
[06:14] <smspillaz> "PERSON MAKES LOTS OF MONEY"
[06:15] <duflu> Heh, I'm not talking about one particular person. But the repeating theme...
[06:15] <smspillaz> yeah
[06:16] <smspillaz> duflu: I was tempted to go into app development after I left canonical but I couldn't bear the idea of the fact that its a seemingly-luck based get-rich-quick scheme
[06:17] <duflu> Yeah, there's a lot of luck. But you'll always increase your luck with more skill too
[06:17] <smspillaz> hmmm
[06:17] <smspillaz> nux must kick something that the nouveau driver doesn't like
[06:18] <duflu> The GPU. nouveau doesn't like those
[06:18] <smspillaz> I always get a little frightened when I see them rewrite it once every few months
[06:31] <duflu> smspillaz: Any more nouveau complaints, the maintainer just logged on to ubuntu-desktop ;)
[06:32] <smspillaz> I'm sure they've heard enough alread :p
[06:32] <smspillaz> *alrady
[06:32] <smspillaz> *already
[06:32] <smspillaz> me english good
[07:18] <robert_ancell> hikiko, welcome!
[07:18] <hikiko> hi :)
[07:18] <hikiko> hi robert_ancell
[08:00] <robert_ancell> alf_, are you familiar with pkg-config? (in relation to the changes for glmark2)
[08:03] <alf_> robert_ancell: yes, it's already being used, but I don't think that pkg-config could help us in this case, since it's not just the base include path that changed.
[08:16] <alf_> duflu: @composite-on-demand, so if I change status to Approve autolanding will fail?
[08:16] <duflu> alf_: Yeah usually. But try it anyway
[08:16] <alf_> duflu: ok, let's see...
[08:17] <duflu> alf_: Because there are "unapproved" changes
[08:39] <duflu> alf_: Frustratingly it might build the proposal and *then* tell you there are unapproved changes. Taking several hours
[08:41] <robert_ancell> alf_, it was also the mir -> mir_tookit change?
[08:45] <alf_> robert_ancell: right
[08:45] <robert_ancell> alf_, ok, thought so. I just wanted to check the pkg-config changes weren't causing any problems
[08:49] <robert_ancell> duflu, Had the /usr/include/mir-1.0 vs /usr/include/mircommon-1.0 discussion with alan_g - The main issue with the former are it makes it much harder to package (because you have to list each subset of headers per package instead of listing a directory*). Also
[08:50] <robert_ancell> * = though of course clever scripting can get around this it would be nice to avoid
[08:51] <duflu> robert_ancell: Not sure what the great hurdle will be but will assume you're right for now :) At least till I try and propose any changes
[08:51] <robert_ancell> duflu, make sure you debuild to test them
[08:51] <duflu> robert_ancell: I do. In fact, it's other people who don't debuild
[08:52] <duflu> alf_: Merged! (?)
[08:52] <duflu> That's not meant to happen though...
[08:53] <alf_> duflu: perhaps it only blocks when you resubmit a proposal?
[08:55] <duflu> robert_ancell: No one's going to answer your questions posed in bugs unless they have a bug comment subscription ;)
[08:55] <duflu> So it's prolly just me
[08:56] <robert_ancell> duflu, meh, I don't think there's any real supporters for it anyway - just propose a branch and see if people complain
[08:56] <duflu> robert_ancell: The danger with this one is that tvoss or alan_g might have a reason for keeping it
[08:56] <duflu> Ask them
[08:57] <tvoss> robert_ancell, supporters for what?
[08:57] <duflu> But I agree it would be nice for people to disagree with something in bug discussions before it reaches proposal
[08:57] <robert_ancell> duflu, I just talked to alan_g and he's OK with it.
[08:57] <duflu> tvoss: https://bugs.launchpad.net/bugs/1160741
[08:57] <robert_ancell> tvoss, remove binder support since it's broken and we don't have a requirement for it
[08:57] <ubot5> Launchpad bug 1160741 in Mir ""Binder" logic is redundant, unused and fails to build" [Low,New]
[08:58] <tvoss> robert_ancell, fine with me, but check with Alan, please
[08:58] <robert_ancell> tvoss, already done
[08:58] <robert_ancell> duflu, kill it!
[08:58] <duflu> robert_ancell: In other news, on-demand rendering just landed. You can finish VT switch support
[08:59] <robert_ancell> duflu, yeah, I've already been talking with alf_ about this
[08:59] <duflu> robert_ancell: Yeah I can probably "kill it" before finishing up this evening
[09:04] <alf_> alan_g: Good morning! What do you think about the signalfd idea in reuse-run_mir? It seems it's going to be useful for proper handling of other signals too (e.g., for VT switching).
[09:10] <alan_g> alf_: there's also some boost stuff tvoss used in an earlier version (IIRC that didn't work in the NDK)
[09:11] <tvoss> alan_g, alf_ there is a generic signal handler in process iirc
[09:16] <alf_> alan_g: tvoss: even better then
[09:21] <alan_g> alf_: are you happy with https://code.launchpad.net/~alan-griffiths/mir/improved-MessageProcessorReport/+merge/155746
[09:22] <alf_> alan_g: I missed the update, checking...
[09:29] <alf_> alan_g: ok
[09:29] <alan_g> alf_: ta
[09:37] <tvoss> katie, ping
[09:39] <duflu> alan_g, tvoss: How sure are we that "binder" is not required/used on Android?
[09:39] <alan_g> duflu: it worked with the NDK, but we've dropped support for that
[09:39] <duflu> Righto
[09:40] <alan_g> We have version control if we ever want it vack
[09:40] <alan_g> *back
[09:40]  * alan_g doesn't want to think about libhybris support for binder
[09:41] <alf_> duflu: can you still reproduce lp #1123824?
[09:41] <ubot5> Launchpad bug 1123824 in Mir "The following tests FAILED: 73 - memcheck(integration-tests.BespokeDisplayServerTestFixture.*) (Failed) 75 - memcheck(integration-tests.FakeEventHubSetup.*) (OTHER_FAULT)" [High,New] https://launchpad.net/bugs/1123824
[09:41] <duflu> alf_: Not sure. Twas only reliable on Nexus 7 and I haven't had time or luck with anything on Nexus recently
[09:42] <duflu> Assume incomplete if you like
[09:44] <alf_> duflu: I will try to reproduce locally, and mark as incomplete if I don't manage to
[09:44] <katie> tvoss pong
[09:45] <duflu> alf_: If you're in the mood for fixing failing tests, there are a few bugs relating to failures when built with clang :)
[09:46] <alf_> duflu: I want a change of pace for today... I will focus on bug fixing, so I will probably take a look.
[09:53] <duflu> OK, that's enough
[09:53]  * duflu -> supermarket, Easter
[11:33] <alan_g> alf_:Are you happy with this version? https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196
=== tvoss is now known as tvoss|lunch
[11:39] <alf_> alan_g: Isn't there still the possibility of a deadlock? For example, if stop() is called from the signal handler (from the same thread as run()) while run() isn't yet waiting on the condition variable.
[11:40]  * alan_g checks
[11:42] <alan_g> alf_: AFAICS exit will be true when run tests it.
[11:43] <alan_g> alf_: sorry just understood what you meant
=== alf_ is now known as alf|lunch
[11:54] <tvoss|lunch> mpt, katie, nothing to sync on my side
[11:55] <katie> tvoss|lunch, mpt, nothing from here either
[12:02] <mpt> Rheet!
=== alan_g is now known as alan_g|lunch
=== alf|lunch is now known as alf_
=== alan_g|lunch is now known as alan_g
[14:00] <alan_g> alf_:Are you happy with this version? https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196
[14:00] <racarr> Morning
[14:01] <alf_> alan_g: looking
[14:05] <alan_g> racarr: morning
=== tvoss|lunch is now known as tvoss
[14:22] <alf_> alan_g: I am happier (although there still is a "hidden" thread that dispatches the signals). Let's see how well this way serves us for handling VT changes, and reevaluate then.
[14:22] <racarr> alan_g: Did you see: https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888
[14:22] <alan_g> alf_: you can't avoid a self-race without using two threads
[14:23] <racarr> I have a feeling the continuous part of the part of this merge is DisplayServer::surface_factory and the move of src/shell/surfaces.h to include/...
[14:24] <alan_g> alf_: boost.Asio can also hook into signals - but again there's a "hidden" thread
[14:25] <alan_g> racarr: I don't spend time second guessing WIP
[14:25] <racarr> ok :)
[14:25] <tvoss> kgunn, ping
[14:25]  * alan_g wonders if "continuous" is contentious
[14:26] <racarr> contentious yes
[14:26] <alan_g> racarr: want me to review?
[14:26] <racarr> alan_g: That would be good when you have time. I think it's "Done"
[14:26] <racarr> I just don't really expect it to land on the first iteration
[14:27] <racarr> because of the surface bits, etc...
[14:27] <alf_> alan_g: The point of using signalfd or boost asio + signal_set (if it can manage signals without extra threads) is that everything would happen synchronously inside a thread that is already doing nothing (the main thread, currently mostly waiting on exit_cv). That is, we would move to a limited event loop structure.
[14:28] <kgunn> tvoss: pong
[14:31] <alan_g> alf_: That just seemed like more work (as it affects how DisplayServer::run()/stop() operate).
[14:33] <alan_g> tvoss: will you have time to chat about edge-type this afternoon?
[14:33] <tvoss> alan_g, in ~30 minutes for max 30 minutes
[14:34] <alan_g> tvoss: I hope it won't take that long. ;)
[14:35] <tvoss> alan_g, cool :)
[14:36] <alan_g> alf_: are you happy to approve and revisit later?
[14:36] <alf_> alan_g: yes
[14:36] <alf_> alan_g: although later may be sooner than you think :)
[14:36]  * alan_g thinks "after Easter"
[14:37] <alf_> alan_g: No easter for me yet, so for me maybe even sooner ;)
[14:37] <racarr> I heard from a homeless man that they cancelled easter.
[14:37] <racarr> Not sure where he got his info.
[14:38] <alan_g> alf_: I'm around tomorrow - swapped it for the following Friday
[14:40] <racarr> investigating building input stack in clang so receive-input-in-clients can pass continuous integration
[14:42] <alf_> alan_g: I doubt I will have reached a conclusion by tomorrow. I still need to investigate how VT switching behaves exactly, and what we need to do (pause compositor, give up). There is also the complication that VT switching exists only on GBM, so we need to handle the difference between the platforms elegantly. One idea is to make e.g. SIGUSR1 mean pause()/play() regardless of the platform, and just connect it to VT switching on GBM.
[14:43] <alf_> alan_g: s/give up/give up drm permissions/
[14:44]  * alan_g wishes he were clever enough to understand
[14:47] <alf_> alan_g: a little background: we can tell the kernel to send us a signal when the user changes to/away from our VT. When we lose our VT we need to pause compositing, and also give up our priveleged access to the graphics device (drm) so that others can render (e.g. X11)
[14:47] <alf_> alan_g: and vice versa when we regain VT "focus"
[14:47] <alan_g> alf_: that helps. ;)
[14:48] <alan_g> alf_: I can see why you'd then want to rethink signal handling
=== tvoss is now known as tvoss|otp
[14:50] <racarr> alan_g: alf_: We talked yesterday in meeting (us/aus/nz) about removing MIR_DISABLE_INPUT after fixing clang build
[14:50] <racarr> seem sensible?
[14:51] <alan_g> racarr: my understanding is that we'll still need null input for the system compositing case
[14:51]  * alan_g has been wrong before
[14:52] <alf_> racarr: related question... what will it take to make the input thread not spin?
[14:52] <racarr> where does lightdm get input?
[14:52] <racarr> alf_: Is the input thread spinning again
[14:52] <racarr> which one do you mean?
[14:52] <racarr> sever or client
[14:52] <alf_> racarr: did it ever stop? :)
[14:53] <racarr> Yeah!
[14:53] <racarr> I remember...
[14:53] <racarr> *scratches head*
[14:53] <racarr> sort of
[14:53]  * alf_ rechecks to ensure he hasn't lost any episodes
[14:53] <racarr> I dunno! Ill figure out too
[14:54] <racarr> oh yay memcheck problems in receive-input too
[14:54] <racarr> going to fix those first I guess
[14:55] <alan_g> racarr: just wondering does the run_mir signature in https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196 solve the same problem as the_ready_to_run_handler()?
[14:59] <alf_> racarr: reconfirmed, InputDispatcher thread is spinning on the desktop
[15:00] <racarr> alf_: Ok I will check it out soon
[15:00] <racarr> thanks :)
[15:00] <alf_> racarr: great :)
[15:00] <racarr> alf_: ready_to_run_handler needs to run after the
[15:00] <racarr> hmm
[15:01] <racarr> err alan_g ^
[15:01] <racarr> was going to say, after the server components are started
[15:01] <racarr> but maybe not really
[15:02] <alan_g> I wasn't sure either - that's why I asked
[15:03] <racarr> alan_g: I will figure out, I thought that for sure it had to run after the various components are started
[15:03] <racarr> but I think this is some piece of information I collected from a few months ago and forgot why
[15:03] <racarr> and it might not really be true now that I look...
[15:03] <racarr> shouldn't be true. just te DisplayServer:: needs to be initialized
[15:08] <kdub> good morning folks, working on the android graphics integration tests today (will drive integrating the nexus4 display)
[15:15] <alf_> racarr: do you want me to file a bug for the spinning thread so we can keep track of this better?
[15:18] <alan_g> racarr: I've done a quick pass and highlighted my main concerns. Grab me if they don't make sense.
[15:19] <alan_g> kdub: racarr  - please review https://code.launchpad.net/~alan-griffiths/mir/reuse-run_mir/+merge/155196
[15:19] <kdub> alan_g, ok
[15:20] <alan_g> status: getting bits of cleanup landed, reviewing and thinking about which work item to steal next
[15:26] <racarr> alf_: That would be great!
[15:26] <racarr> alan_g: Want to steal hardware cursor?
[15:26] <racarr> its kind of cool, self contained, I can show you the drm/gbm APIs you need
[15:27] <alan_g> racarr: sure. Let me grab a drink first.
=== alan_g is now known as alan_g|tea
[15:32] <racarr> alan_g|tea: Ok sounds good :)
[15:35] <alf_> racarr: lp #1161456
[15:35] <ubot5> Launchpad bug 1161456 in Mir "InputDispatcher thread is spinning" [Undecided,New] https://launchpad.net/bugs/1161456
=== alan_g|tea is now known as alan_g
[15:43] <racarr> alf_: Thanks :)
[15:43] <racarr> hmm
[15:44] <racarr> the input manager from the testing server configuration in test_client_input.cpp
[15:44] <racarr> is leaking...
[15:44] <alan_g> racarr: what's best? Hangout? email with links and chat?
[15:45] <racarr> alan_g: For cursor? Either way it's pretty simple. probably easiest is just jumping on a hangout quickly and I can quickly take you through what is there/what needs to happen
[15:46] <alan_g> racarr: let's do that then
[15:46] <racarr> ok starting a hangout
[16:06] <racarr> literally everything is leaking in this test
[16:06] <racarr> somehow exit must not be clean
[16:09] <alan_g> racarr: does it use the test framework?
[16:09] <alan_g> racarr: does it use the mir test framework?
[16:09] <alan_g> Because the server and client processes do not exit cleanly
[16:14] <racarr> alan_g: Yes. It does...but why don't the other tests report leaks then?
[16:16] <alan_g> racarr: the parent test process should be clean, it is the server and client process that exit abruptly
[16:17] <racarr> alan_g: Parent is clean yeah. server detects the input manager and all its dependencies (i.e. the whole android input stack)
[16:17] <racarr>  as definitely lost
[16:17] <racarr> but this doesn't happen for any other tests
[16:34] <alf_> racarr: I am not sure if/how it is related, but I currently trying to debug why the server doesn't shut down properly after a client has connected (and disconnected). The use count of our mg::Display shared_ptr<> is larger than expected at the end and thus our display it's not destroyed properly.
[16:35] <alf_> racarr: I am still investigating why we lose (or rather don't lose) shared_ptr references
[16:40] <racarr> alf_: Ah...strange
[16:40] <racarr> no ideas from top of my head
[16:42] <alf_> racarr: just mentioned it in case it's somehow related to your issues and might help you with debugging
[16:42] <alf_> racarr: debugging = figuring out what's going on
[16:44] <racarr> thanks
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
[16:53] <alan_g> alf_: that sounds like a circular dependency. :(
[17:00] <alf_> alan_g: Yes. An interesting clue that it only happens after at least one client has connected (and possibly disconnected, doesn't matter), never before.
[17:07] <cecilpierce> /part
[17:16] <alf_> alan_g: racarr: kdub: enjoy your holidays, talk to you next week (well, except Alan)!
[17:17] <kdub> you too alf_ !
[17:22] <racarr> Bye alf
[17:22] <racarr> enjoy :)
[17:23] <alan_g> alf_: see you tomorrow!
[17:23] <alf_> alan_g: :)
=== alan_g is now known as alan_g|wine
[18:29] <racarr> "Why is "MirEventDelegate const *event_handler" a separate parameter and not a member of MirSurfaceParameters?" - Alan on receive-input-in-clients
[18:29] <racarr> anyone have any opinions?
[18:29] <racarr> My thought is that MirSurfaceParameters are surface creation parameters, whereas the event delegate is more something attached to a created surface
[18:29] <racarr> ...but thats really only kind of in terms of the server/client interaction
[19:05] <racarr> not convinced that fsync works correctly under valgrind
[20:45] <sturmflut> I finally got glmark2 running on Mir and took a short video: http://www.youtube.com/watch?v=Kjb8a8ISKWY
[20:45] <sturmflut> Could be useful for marketing purposes