#ubuntu-mir 2013-05-27
<RAOF> thomi: Yup?
<thomi> RAOF: hey, maybe you can help me - I think the mir client library is leaking file handles when running multiple connections from different threads. I *think* it's leaking /dev/dri/card0, but I'm not sure where that's opened in the ode to do any debugging
<RAOF> thomi: That's entirely plausible.
<thomi> I'm just trying to get some more evidence to support my theory that I've got the correct FD
<RAOF> You could do that with strace -e file, right?
<thomi> ahh, good idea, I've been taking lsof snapshots over time
<RAOF> Yeah. Dump the strace output to a file, parse it with something, and track the open fd.
<thomi> RAOF: so on th client side, I don't see any open() calls while the client is spitting out errors, which makes me think that perhaps the client is just reporting a server-side error.
<thomi> RAOF:  but running strace on mir_demo_server doesn't seem to show me anything interesting either
<thomi> the error I get is one of either:
<thomi> Could not connect to server, error is: connect: Too many open files
<thomi> or:
<thomi> Could not connect to server, error is: eventfd_select_interrupter: Too many open files
<RAOF> That does sound a lot like a fd leak, doesn,t it.
<thomi> yeah
<thomi> if I slow down the client app, it takes longer to appear, so it's soemthing that happens within a connect & disconnect
<thomi> is valgrind something that might help in situations like this?
<RAOF> It *can* trace fd leaks, yes.
<RAOF> Wow. Compiz on llvmpipe is much better in mesa master.
<RAOF> I didn't notice that I don't have HW accel.
<thomi> heh
<thomi> will try valgrind, but I suspect I'm missing something
<thomi> it seems like strace is missing some open calls, since lsof shows more files open thatn strace shows open() calls for
<RAOF> If it doesn't happen when slowing down the client then maybe it's *not* a leak.
<RAOF> Maybe you're just trying to open too many files? :)
<thomi> RAOF: no, it does happen, it just takes longer
<RAOF> Ah, fair enough.
<thomi> RAOF: so my point was that it's linked to the speed at which I run the stress test
<RAOF> I was trying to see if glxinfo open()s /dev/dri/card0, but llvmpipe has foiled that brilliant plan.
<thomi> haha
<thomi> hmmm. when I run mir_demo_server under valgrind, everything works, probably because it's so bloody slow :-/
<RAOF> :)
<thomi> ugh, I hate trying to track down these sorts of issues
<smspillaz> RAOF: compiz and unity or just compiz?
<RAOF> smspillaz: Compiz and Unity.
<smspillaz> hm, neat
<RAOF> thomi: OOH!
<thomi> RAOF: ?
<RAOF> thomi: I think I know where your fd leak is.
<thomi> oh good
<thomi> easily fixable?
<RAOF> I need to check the stress-test code.
<RAOF> But - do you close() the platform fd?
<thomi> all it does is a connect & then release
<RAOF> Right. So you get the platform package, which contains a drm fd, and then don't close it.
<thomi> hmmmm...
<thomi> seems like a mistake lots of people are going to make. Can we not make it RAII?
<alf_> RAOF: thomi: Could be, although in that case I would argue that it should be closed on release
<thomi> alf_: +1
<RAOF> alf_: Maybe?
<thomi> the thing is: I didn't do anything to get the platform package
<thomi> all I do is a connect
<RAOF> Correct. You get it automatically on connect.
<thomi> right, so if you're going to allocate it automatically, I think you should also deallocate it automatically
<thomi> otherwise, how do I know that I need to deallocate it?
<RAOF> Well, you don't, unless you're deliberately writing stress-tests :)
<alf_> RAOF: what's your concern about deallocating automatically?
<RAOF> alf_: Silently closing file descriptors out from under clients smells a bit to me.
<RAOF> But since we already do it for the prime fds in buffers, I guess it's got the virtue of consistency.
<tvoss> RAOF, alf_ why not make it a policy and default to atexit, while clients have a way to say: please close it asap
<alf_> RAOF: If it turns out to be an issue, we could also give copies of the fds to the user when asking for the platform package, and tell them that they need to close it themselves there, and we can still close our own fds internally
<thomi> RAOF: surely it should be closed when I release the connection anyway?
<RAOF> thomi: Why? You might want it, and it's not in any way bound up to the connection.
<RAOF> alf_: I think I prefer that, and would like to also do that for the buffer package.
<thomi> I mean, if it's created automatically as a side effect of calling connect(), I'd expect it to be released as a side effect of calling release()
<thomi> anyway, at the very least the documentation for the connect() call needs to be updated with the fact that you need to close certain FDs
<RAOF> To client code it doesn't look like it's created automatically; it looks like they get it as a result of get_platform_package().
<alf_> tvoss: we could, although I find that giving copies is more versatile and straightforward
<RAOF> I'd support a policy of only ever handing out dup()'d fds from *get_*_package(), and managing the lifetimes of our internal fds.
<tvoss> alf_, yup :)
<tvoss> RAOF, +1
<RAOF> That will mean that we eat up double the fd space, but it's not like we're consuming a vast range of it now anyway :)
<thomi> RAOF: hang on, I never call get_platform_package()
<RAOF> thomi: Yeah. That *doesn't* create the platform package, merely accesses it. But from the client code's perspective, that's where it's created.
<thomi> right
<RAOF> Which is why dup()ing in that call and handling our own fd lifecycles internally makes sense.
<alf_> thomi: RAOF: perhaps even better, we should hand a release function to the user when they get the platform/buffer packages, so they will just need to call that, don't care about explicitly closing etc
<alf_> tvoss: ^^
<thomi> alf_: that would work for me
<RAOF> alf_: I don't know; client code that deliberately accesses the platform/buffer packages needs to know the platform-specific nature of that package anyway.
<tvoss> alf_, okay, so they receive responsibility and power at the same time
<RAOF> I think that if dup() is sufficiently costless then dup() + automatic internal management is a better approach.
<alf_> RAOF: I am not arguing against dup. I am saying that the client doesn't need to know the details of how to release the platform package. The FD they get may be dup()ed, maybe not, and the same things goes for other resources contained in the platform/buffer packages.
<alf_> RAOF: tvoss: Perhaps an other approach would be, to not dup the FDs, just say that if you need it beyond connection lifetime just make a dup yourself.
<alf_> RAOF: tvoss: This doesn't consume more fd space unless needed by the client.
<tvoss> alf_, I like that idea. RAOF: thoughts?
<tvoss> alf_, it requires the client to express intent quite clearly
<tvoss> and our policy is strict and straightforward
<RAOF> I'm a fan of the API being able to respond consistently, and I think dup() makes that easier.
<alf_> RAOF: what's inconsistend about saying we are giving access to resources but we own them?
<RAOF> Otherwise, for example if a client accesses the platform buffer and close()s the drm fd, subsequent calls to get_platform_package() will appear to succeed but return a garbage platform.
<alf_> RAOF: so it's mostly about not allowing the client to mess up?
<RAOF> Yeah.,
<RAOF> Where it's low-cost, I think it makes sense to have a forgiving API.
<RAOF> (With an implicit assumption that dup() is low-cost)
<mlankhorst> it usually is, it just adds a duplicate to the process' fd list
<RAOF> Yeah, it didn't seem like something that would be high-cost.
<RAOF> And even if we double-up on fds we're only using about 10 or so, which is a negligible fraction of the 1024 limit(ish).
<thomi> ok guys, it's getting late here. Can someone post a msg to the ML with whatever the outcome of this is please? I'll fix up the stress tests in the morning
<hikiko> hmm hi, alan_g is not working today?
<hikiko> alf_, ping? :)
<alf_> hikiko: it's a public holiday for US and UK today
<hikiko> :)
<hikiko> I have a question
<hikiko> why do we use protected destructors in display.h?
<hikiko> is it a design pattern?
<hikiko> I guess we only want to destroy the object at release time
<hikiko> ?
<hikiko> sorry :p i don't guess anything :)
<alf_> hikiko: Protected destructors in display don't allow destroying a derived *Display object when using a pointer to a base class. This basically enforces the use of a shared_ptr for ownership when upcasting, and that's the reason it is done this way. It's not necessary to do that, though. You can just make the virtual destructor public.
<hikiko> :)
<hikiko> thanks alf_ !
<hikiko> alf_, could you please review this: lp:~hikiko/mir/mir.fix-missing-virtual-destructors if you have some time later? +question: shall I push my future branches as lp:~mir-team/...?
<alf_> hikiko: whichever way you prefer is fine
<hikiko> :)
<thomi> morning
<RAOF> Yo!
#ubuntu-mir 2013-05-28
<RAOF> robert_ancell: Good morning. Or afternoon, depending.
<robert_ancell> RAOF, hello
<RAOF> Does lightdm have a tool to parse/modify lightdm.conf?
<robert_ancell> RAOF, /usr/lib/lightdm/lightdm-set-defaults
<RAOF> Sweet, thanks.
<RAOF> Hm. Presumably that could be trivially extended to support changing the session type, right?
<robert_ancell> RAOF, yes
<RAOF> Excellent.
<RAOF> Hurray for awesome upstreams.
<thomi> RAOF: hey - it sounds like maybe no decision was reached last night regarding the client API fd issue?
<thomi> at least, no message to the ML or merges to change anything.
<RAOF> thomi: Oh, I'll prepare a merge nom
<thomi> RAOF: cool - I wasn't sure what the final consensus was
<thomi> RAOF: all I know is that IMO we're currently violating the "make it hard to use incorrectly" tenet of API design.
<RAOF> Indeed.
 * thomi likes being the bumbling idiot to find all the problems your *real* users will find in the future
<thomi> robert_ancell: so, are you back at work, or just lurking?
<thomi> just lurking I guess :)
<thomi> RAOF: in the mean time, do you know off the top of your head what I need to do to close that FD?
<RAOF> thomi: close(platform_package.fd[0]) should do it.
<thomi> RAOF: I'd need to call mir_connection_get_platform(my_connection, &my_platform_package) first, to populate those FDs, right?
<RAOF> Right
<robert_ancell> thomi, back to work
<robert_ancell> (I am)
<thomi> robert_ancell: cool!
<thomi> RAOF: what's the name members used for in MirSurfaceParameters?
<thomi> does it have to be the same as the name passed to mir_connect?
<RAOF> ...
<thomi> and if so, why can't it just be copied from the connection?
<RAOF> I was going to say the application's ID, but that's clearly not right :)
<thomi> the examples just use the same string as the application name
<thomi> (i.e.- __PRETTY_FUNCTION__)
<RAOF> So, there's good reason to name surfaces; for example, the title bar.
<RAOF> I don't know of anything that's using that information right now, though.
<thomi> ok
<thomi> RAOF: I think something useful I could be doing is adding to the doxygen documentation of these types, but I wonder if anyone would object?
<RAOF> Why?
<thomi> dunno - I assumed they were undocumented for a reason
<RAOF> The reason is almost certainly âno one bothered documenting itâ
<thomi> ok, I might start documenting things as I go
<thomi> hmmm, I seem to have broken something, such that now mir_connect_sync hangs forever
<thomi> even after restarting mir_demo_server O.0
<hikiko> alf_, are you busy?
<alf_> hikiko: hi, what's up?
<hikiko> I can't find the EGLNativeWindowType anywhere and I wonder what is it... I guess something like the EGLNativeDisplay, but I wonder why we use it
<hikiko> (client/gbm/gbm_platform.h/cpp)
<alf_> hikiko: EGLNativeWindowType is an EGL type. It is an opaque handle for the native window type.
<alf_> hikiko: we give it to the client so they can use EGL functions to set up the rendering context
<hikiko> which is the context we created in the server?
<alf_> hikiko: no, a new rendering context they can use to draw on a MirSurface
<hikiko> so this is a context created in the client
<hikiko> by the client*
<hikiko> and the NativeWindow is the pc/android window that the client "sees" in his screen?
<hikiko> or something else?
<hikiko> I am trying to understand if I need to create another context using sdl or I can use the egl functions as they are, but I am not sure I understood 100% what's going on in the client platform :S
<alf_> hikiko: yes, window == visible surface (whatever that may mean for each windowing system)
<hikiko> ok, so I forget about all this and I create an sdl window again in the platform part...
<alf_> hikiko: no, when using mirclient, the native window is a MirSurface
<alf_> hikiko: or to be more exact some representation of MirSurfaces that the EGL system can use
<alf_> hikiko: why can't you just compile with the gbm backend for now, until the server part is finished, and then move to the client part?
<hikiko> because
<hikiko> you can't use the gbm as it is
<hikiko> one sec I ll show you
<hikiko> irPlatformType mclg::GBMClientPlatform::platform_type() const
<hikiko> {
<hikiko>     return mir_platform_type_gbm;
<hikiko> }
<hikiko> each client platform
<hikiko> has this function
<hikiko> android returns android, gbm returns gbm, I have to return sdl
<hikiko> mmm
<hikiko> if i use gbm as it is
<alf_> hikiko: It doesn't matter for now, the first step is to get the server-side examples working. Sure, the client side won't work, but we can fix this later.
<hikiko> yes that's what I am trying to do :s ok let me try something.. bbl (+thanks!)
<hikiko> btw alf_ is there any way to exclude gmock... of the build?
<hikiko> I get tones of errors there
<tvoss> hikiko, what kinds of erros?
<hikiko> tvoss, about wrong declarations, syntax errors in templates and I end up with:
<hikiko> fatal error: too many errors emitted, stopping now [-ferror-limit=]
<tvoss> hikiko, then it's highly likely that you have an error somewhere in your header files. GMock compiles just fine in general
 * tvoss notes that almost always one's own code is wrong :)
<hikiko> tvoss, I was getting errors even when I was compiling the trunk
<hikiko> just now they become fatal
<hikiko> so, it's not only my header files
<tvoss> hikiko, compilation works fine in CI and autolanding
<hikiko> ok, then I ll change my compile params...
<hikiko> :D
<tvoss> hikiko, why do you have custom compile params?
<hikiko> well, I use clang because each time I have an error like: forgot to include a header file, I trigger a gcc internal compiler error
<hikiko> it was faster to change the env var and use clang
<hikiko> than compile the next gcc versions
<tvoss> hikiko, which gcc version are you using?
<tvoss> hikiko, saucy has gcc 4.8
<hikiko> gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
<hikiko> I am still using raring tvoss
<hikiko> do you think I have to upgrade?
<tvoss> hikiko, not sure, but gcc 4.7.3 is quite stable for me
<hikiko> well in my case it was crashing all the time with internal compiler error and no clue about the problem it triggered it
<hikiko> so I gave up and replaced it
<alan_g> tvoss: ping
<tvoss> hikiko, at any rate, you should not need to compile a toolchain on your own: see https://launchpad.net/~ubuntu-toolchain-r/+archive/test
<tvoss> alan_g, pong
<alan_g> tvoss:  did you see RAOF's email "Mir in Ubuntu"? IMO it raises some architectural issues...
<tvoss> alan_g, yup, have seen it ... what are those issues?
<alan_g> tvoss: we should have a plan for stabilizing ABI and comms protocol
<tvoss> alan_g, yup, agreed
<alan_g> Because it is starting to impact other components
<alan_g> tvoss: is that something you should be driving? Or who?
<tvoss> alan_g, I would think that the ABI stability is a requirements towards Mir and the team should just pick it up. But I'm happy to trigger the discussion
<RAOF> I don't think comms protocol is particularly important to stabilise at this point - although backwards compatibility in comms protocol might be soon.
<RAOF> But needing to rebuild unity-system-compositor for each Mir commit clearly won't scale to the distro.
<tvoss> RAOF, fully agreed
<alan_g> RAOF: ack (although I think we should prepare the way by adding version info to the protocol - even if we ignore it)
<RAOF> alan_g: +1
<RAOF> We should at least be able to return a sensible "whoops, this won't work" error.
<alan_g> RAOF: We can return an error string containing "whoops, this won't work" - does that count? ;)
<RAOF> alan_g: As long as it can be translated âº
<hikiko> alf_, what happened to the drm authenticator?
<alf_> hikiko: it was removed, but it seems that we will need to reinstate it after all
<hikiko> :S
<hikiko> well without it my branch doesn't compile anymore
<hikiko> I use the authenticator to register my drm device fd
<alf_> hikiko: Why do you need to register a drm device fd?
<hikiko> actually I have to tell the xserver
<hikiko> which is my drm fd
<alan_g> alf_: I'm not sure I've used it since rebuilding my system - is s-jenkins working for you?
<tvoss> alan_g, it's down
<alan_g> tvoss: ta
<alf_> hikiko: Why is this needed for the SDLDisplay?
<hikiko> if you want to create a gbm buffer
<hikiko> you need the drm fd
<hikiko> there's no other way
<hikiko> but if you open a drm fd
<hikiko> you need to authenticate
<hikiko> tell the xserver that you will use this device
<hikiko> otherwise you wont have permissions to do anything
<alf_> hikiko: right, but my question still stands: why do you need to create a gbm buffer for the SDLDisplay (I mean that class in particular, not the sdl backend in general).
<hikiko> because you use the gbm buffers in the ipc mechanism
<hikiko> and you told me that there's no point to create my own type of buffers
<hikiko> last month :s
<hikiko> +the gbm buffer allocator is part of the gbm platform which is used in the display
<hikiko> sorry
<hikiko> you asked for the display ^^
<alf_> hikiko: That's true, you don't need gbm buffers in the SDLDisplay class, you need them in the buffer allocator. My proposal for step 1 is to get SDLDisplay + render_to_fb to work, which doesn't involve the buffer allocator or any IPC/client code. I think that's the easiest way (step by step) to move forward, otherwise there are just too many things to take care of at once.
<alf_> hikiko: then step 2 is getting the buffer allocator + render_surfaces to work, step 3 is IPC/client side rendering.
<alf_> hikiko: that is, for step 1 you just need an SDLPlatform that returns a proper SDLDisplay and stub implementations for everything else
<racarr> Good morning!
<kgunn> racarr mornin'
<kgunn> awfully early
<alan_g> kgunn: racarr afternoon (not very early)
<racarr> Morning all :)
<kgunn> afternoon alan_g
<racarr> alan_g: Can I explain "friend class SessionManager" from rebuild input targets
<racarr> Am having trouble coming up with a better solution
<alan_g> racarr: I guess you have the right. ;) (Although I've not tried for a deep understanding yet.)
<racarr> I just meant I am asking for help :)
<racarr> basically the problem is, now that ms::Surface is the input target
<racarr> how can the shell with an msh::Surface give it keyboard focus (through the InputTargeter)
<racarr> so I added msh::Surface::internal_surface, protected, and let the SessionManager use it -.-
<racarr> it could also be InputTargeter instead of session manager.
<racarr> or the even the InputRegistrar, could be the only one to use internal_surface, and it exposes like handle_for_surface(std::shared_ptr<msh::Surface>...) which the targeter uses
<racarr> but I don't know. none of these (including friending the SessionManager)
<racarr> are particularly compelling
<alan_g> racarr: I've a feeling that the relationship between ms::Surface and msh::Surface is wrong. (And that things being modelled as attributes should be associations) Maybe this is part of the same issue.
<racarr> alan_g: Hmm I think it is part of the same stickiness...what do you mean by attributes vs assosciations though?
<alan_g> racarr: Let me try an example...
<alan_g> A board game piece could have a "black" or "white" color attribute
<alan_g> Or it could associated (e.g. in a set of) with "black pieces" or a with "white pieces"
<racarr> vs some sort of external assosciation?
<racarr> mm
<racarr> I see
<racarr> So you mean ::type/::state
<racarr> give msh::Surface dual roles?
<racarr> because without that it's just a resource managing class
<racarr> (input did too, but now input is moved down)
<alan_g> racarr: that's what I mean. Not sure my "unease" actually points to a solution.
<racarr> alan_g: Hmm.
<racarr> alan_g: Maybe the "solution" is to remove the friend/protected
<racarr> resource managing classes typically expose something like that
<racarr> and then aim at moving the state somewhere else
<alan_g> racarr: certainly adding a friend to access a *protected* member seems odd
<alan_g> racarr: and does internal_surface() need to be virtual?
<racarr> No definitely not
<racarr> it should probably return
<racarr> weak_ptr?
<racarr> as well
<racarr> or throw an exception
<alan_g> racarr: Possibly - or check the lock succeeds
<racarr> alan_g: My current leading theory is remove the protected and friend class, remove the virtual, add an exception + tests for internal_surface
<alan_g> racarr: actually, looking at where internal_surface() is used - could it be replaced by update_input_focus(InputTargetListener&) ?
<racarr> It could.
<racarr> hmm
<racarr> well
<racarr> except then InputTargetListener wants shared_ptr, which is maybe another bug?
<racarr> I'm not sure that isn't more coupled though...im trying to think about how the tests would look
<alan_g> racarr: is it more coupled? Then session manager doesn't need to know how the input target is moved (it doesn't need to get a ms::Surface from one place and pass it to another.
<racarr> but the same way msh::Surface doesn't need to know about an InputTargetListener
<racarr>  / how it receives focus
<racarr> right now it doesnt even need to know if it has focus but eventually it will
<racarr> I can see the appeal of update_input_focus
<alan_g> "tell don't ask" ;)
<racarr> it makes me uneasy though because I dont
<racarr> think of focus as an attribute
<racarr> of the surface.
<racarr> though I guess it' clear with the InputTargetListener...
<alan_g> "attribute" or "association"?
<racarr> its
<racarr> an assosciation
<racarr> focus is assosciated with the surface (in the InputDispatcher as it stands)
<racarr> but the surface isn't told, hey you got focus, hey you lost focus, etc.
<alan_g> but that "surface" is the ms::Surface, not the msh::Surface
<racarr> mm
<racarr> Ugh
<racarr> the reference issues
<racarr> are difficult to solve :p
<racarr> if you want to do it this way then InputTargetListener has to take
<alan_g> a weak_ptr - or a proxy
<alan_g> yep
<racarr> ms::Surface&, so then the window handle repository has to take ms::Surface&
<racarr> and
<racarr> and so the surface stack :p
<racarr> or a weak_ptr perhaps...?
<racarr> thinkthink*
<racarr> it's not that bad either way
<alan_g> racarr: what isn't clear to me is what should happen to input if the focussed surface is zapped. (But I'll leave that as an exercise..."
<alan_g> s/"/)
<racarr> alan_g: Another possible way to solve this is with operator== overload
<racarr> but it's kind of hairy
 * alan_g headdesk
<racarr> hmm, if the focused surface is zapped, then the InputDispatcher
<racarr> will fail to promote the focused window handle
<alan_g> http://arstechnica.com/information-technology/2013/05/why-arent-user-defined-operators-more-common/
<racarr> and clear its focus
<racarr> I know :p this seems like a pretty clear overload though
<alan_g> racarr: that enough help for now?
<racarr> Yes thanks. :)
<racarr> coffee shop be back for meeting!
<kdub> hello again folks, status, working on a swapping algorithm switcher
<racarr> status: Updating rebuild-input-targeting. Then going to work on some lttng tracing for inpu
<racarr> t
<alan_g> racarr: you've a couple of other MPs in need of attention
<racarr> alan_g: I will reject disable-sequences until later
<racarr> alan_g: I can update depthify-stack but there is no point to land it without rebuild-input-targeting as input wont work in stacked scenarios
<racarr> so have been waiting
<alan_g> racarr: ok
<racarr> oh wow...
<racarr> alan_g: In that whole discusion before...I was wondering, how does msh::Surface then go on and pass itself to the InputTargeter from take_input_focus
<racarr> now looking at the code...it needs to pass ms::Surface and it's all very obvious :p
<racarr> I think I got crosswired because I am used to thinking that InputTarget=shell::Surface
<alan_g> racarr: how very confusing
<racarr> the msh::Surface/mf::Surface<->ms::Surface is so frustrating
<racarr> maybe I will try and find a "once and for all" solution this week...I think its worth some thought
<alan_g> racarr: good luck! (I keep being distracted by more urgent work.)
<racarr> :)
<alf_> status: BufferSwapperSpin and client::RpcReport MPs, with the next step being an lttng RpcReport implementation (and perhaps related client side improvements)
<racarr> How come bypass comp?
<alan_g> racarr: it is a maze of twisty little objects - I know what I want to happen, but untangling the bits I want to change is frustratingly slow.
<racarr> mm :)
<kdub> alan_g, anything I could help with?
<alan_g> kdub: not right now, but once I get this first spike running I'll be grabbing you. (Hopefully tomorrow)
<racarr> alan_g: Pushed updates to rebuild-input-targeting
<racarr> let me know if I can help fit things together on review, etc...feel bad about dumping such a large branch but couldn't find any sensible way to split it up
<alan_g> racarr: ack
<racarr> I Guess I will write some doxygen too
<racarr> alf_: I am looking at adding LTTNG for some interesting input statistics (just a few to start, such as received event from kernel, dispatched event, etc...)
<racarr> alf_: Just want to make sure I have the idea right...
<racarr> make a new report interface. Then provide lttng/logger implementations?
<racarr> or are there other ways to use it
<alf_> racarr: that's the recommended way, look at message_processor_report* in server/lttng/ as a template of how to do it
<alf_> racarr: let me know if you have any questions
<racarr> alf_: I think it makes sense. Thanks :)
<alf_> racarr: yw
<racarr> what I am wrestling with in my head...is...I guess I want a less explicit interface but
<racarr> it's probably wrong?
<racarr> the thing is. the way I imagine wanting to use tracing (espescially in parts like input) is to have...lots of trace points!
<racarr> But if they are done through a report rather than explicitly they have a real cost
<racarr> both runtime, and interface bloat
<alf_> racarr: runtime=cost when using a null report?
<alan_g> racarr: you were at the London sprint. We discussed the difference between reporting and tracing there
<racarr> what you get through the report, is explicitness, and a contract.
<racarr> alan_g: Mm
<racarr> alf_: Well, it's still a virtual method invocation right. It's a hugely low cost I guess.
<alan_g> racarr: is this the same discussion revisited?
<racarr> mostly about interface bloat.
<racarr> alan_g: sort of..
<alf_> alan_g: racarr: hangout?
<racarr> It's just there are some type of events...like say
<racarr> "Couldn't load input device configuration file so falling back to generic"
<racarr> that I am not sure are ever interesting as part of a report
<racarr> and are so large
<racarr> err, the space of possible events
<racarr> but you would love to see them in a trace
<racarr> *shrug*
<racarr> alf_: We can. I don't want to distract everyone too much though
<racarr> because I haven't spent much time thinking about this yet
<alf_> racarr: ok
<racarr> I think maybe I am getting ahead of myself anyway
<racarr> as my initial goal was just to add tracing for a few interesting
<racarr> occurences
<racarr> not everything XD
<racarr> lol at comments in android input stack
<racarr> We hold a wake lock at all times except during epoll_wait().  This works due to some                                                                                                                                                                                              // subtle choreography
<racarr> "Subtle choreography"
<alan_g> racarr: alf_ - do we want to hangout now? Or after racarr has spent a day implementing something?
<alf_> alan_g: racarr: let's leave it for after
<racarr> I agree. I just got ahead of myself. The current interfaces are fine for all I want to do now.
<racarr> in the past. I've found really detailed tracing as a more useful way to debug
<racarr> multithreaded/multiprocess systems
<racarr> and might want to enable that one day?
<racarr> but. ONE STEP AT A TIME *hits self on head with one step at a time stick*
<alf_> kdub: how about BufferSwapperSync, BufferSwapperAsync ?
<alan_g> racarr: ok, but it is good to share ideas about the overall shape of things too. ;)
<alf_> kdub: hmm, Async doesn't really tell the whole story
<kdub> alf_, yeah, "synced to what?" was my first thought
<racarr> alan_g: The one thing I do have open for this first step is
<racarr> the existing "InputReport" stuff to redirect the android logging
<racarr> is conflicting in name because I can't provide an LTTNG backing for that really
<racarr> at least, the command line option is conflicting ;)
<alan_g> racarr: you'd like to rename it "LegacyInputReport"? Fine by me - I just stopped it spewing over the console
<racarr> Ok
<racarr> yes. Much appreciated :)
<alan_g> racarr: one day we can get rid of the legacy. ;)
<kdub> alf_, maybe FrameDroppingSwapper and VsyncSwapper?
<kdub> sort of tough to convey all the nuances of a buffer swapper in class name ;-)
<racarr> so how do I use lttng -.-
<racarr> hmm neither my new lttng or the old lttng following alfs instructions
<racarr> works for me
<racarr> Lunccccch!
<greyback|away> racarr: small patch for lp:~robertcarr/platform-api/mir branch so it builds against latest mir: http://pastebin.ubuntu.com/5711198/
<greyback|away> after merging trunk ofc
<racarr> annd back
<racarr> greyback|away: Ah! thanks will merge
<kdub> swapperswappers are tricky
<racarr> :(
<thomi> morning folks
<robert_ancell> thomi, hello
<robert_ancell> thomi, hey, any update on autorebuilding lightdm against libmirserver?
<thomi> robert_ancell: should be working now
<robert_ancell> \o/
<robert_ancell> thomi, also, we need to enable lightdm building on saucy
<thomi> might be done already, let me check
<robert_ancell> thomi, https://launchpad.net/~mir-team/+archive/staging/+packages shows lightdm being rebuilt 2 May - so it doesn't appear to be working?
<thomi> robert_ancell: ok, saucy is already enabled. I have a call with francis in 4 minutes, so I'll ask him about it then
<robert_ancell> ok, ta
<thomi> robert_ancell: also, I have a 50 line c++ program that reliably hangs the mir server :(
<thomi> about to file a bug...
<robert_ancell> :(
<thomi> I'm really glad we're doing these stress tests, we seem to be fixing a lot of problems
<thomi> well, when I say "we"... I'm not fixing anything :P
<kgunn> thomi: hey...somebody's gotta break it before you can fix it
<thomi> I'm the annoying guy who comes along and pokes holes in your nice shiny new code :)
<kgunn> i'm grateful...good stuff!
<robotfuel> I get the following error message when trying to run mir_demo_server on the phone: http://pastebin.ubuntu.com/5711560/ has anyone else run across this?
<greyback|away> robotfuel: I find a reboot can help that. I sometimes get it after a package update
<greyback|away> robotfuel: oh actually, are you running on your desktop?
<robotfuel> greyback|away: no the ubuntu-touch image on a galaxy nexus
<thomi> robert_ancell: got a moment for a quick hangout with francis to discuss the lightdm issue?
<greyback|away> robotfuel: ah, I see. You need to run it via "adb shell" - not as the root user
<robert_ancell> thomi, sure
<robotfuel> greyback|away: I am running it in the ubuntu_chroot
<robotfuel> via adb shell
<robert_ancell> thomi, what is the issue?
<thomi> robert_ancell: just the lightdm being rebuilt after every mir
<robert_ancell> ack
<thomi> robert_ancell: actually, don't worry
<robert_ancell> even better :)
<thomi> I'll manage, and pull you in if needed
<greyback|away> robotfuel: ok good. Did you stop surfaceflinger?
<greyback|away> robotfuel: you can do this while not in the chroot, by running simply "stop"
<robotfuel> greyback|away: yes I ran stop && ubuntu_chroot shell
<greyback|away> robotfuel: in that case, I'm running low on ideas. What device have you?
<greyback|away> oh oyu said, galaxy nexus
<robotfuel> greyback|away: yes a gnex
<thomi> robert_ancell: you want lp:~mir-team/lightdm/unity rebuilt, right? not lp:lightdm
<robert_ancell> thomi, correct
<greyback|away> robotfuel: give me a minute, I'll try it on mine
<robotfuel> I have jenkins running a glmark job on the desktop, but it should be more interesting on a phone, because fps isn't tied to the refresh rate of the monitor
<thomi> robert_ancell: ok, we had enabled the autorebuild for unity-system-compositor, but not for lightdm, that's being done now
<kgunn> robotfuel: on a phone you're still going to be tied to vsync
<kgunn> unless you do something to unhinge it
<robert_ancell> thomi, so U-S-C shows it is 19 days old
<robert_ancell> thomi, oh duh. I was getting mixed up. I think technically we don't need to rebuild lightdm on libmirserver changes, but it is a nice to have anyway
<thomi> robert_ancell: ok, well.. that's going in now anyway :-/
<robert_ancell> we do need lightdm on saucy though
<thomi> everything should be being built on saucy already
<robert_ancell> thomi, it might actually need to be rebuilt when u-s-c changes in the future, but I'll bug you then if it's a problem
 * robert_ancell takes a week off and forgets everything
<fginther> yo
<thomi> robert_ancell: so after the rebuild the packages should be pushed to ppa:mir-team/staging, ight?
<robert_ancell> thomi, yes
<thomi> fginther: can we do that easily?
<robert_ancell> thomi, how do you version them?
<fginther> robert_ancell, we can do that..
<robert_ancell> fginther, so it just overwrites the existing one?
<fginther> the packages can be versioned with a monotonically increasing version number
<fginther> yes, it will overwrite the last one
<robert_ancell> fginther, will a user upgrade from version X to X (i.e. if the binary has changed)?
<thomi> presumably the version number will be X -> X+1 or X.1
<robert_ancell> I was hoping we could have 0.0.1brz25.3 for the third rebuild of bzr version 25
<greyback> robotfuel: ok I got it working here. I made sure everything was up to date. Then reboot, adb root, adb shell, stop, ubuntu_chroot, mir_demo_server&, mir_demo_client_accelerated
<fginther> robert_ancell, if the user does a dist-upgrade, they will get the lastest, but if a user does a install of just mir, it will not pull in the lightdm-mir
<robotfuel> greyback: thanks, I didn't try the client part
<greyback> robotfuel: if the server returns that error message you got, then the client will fail. Server needs to be running
<greyback> before client can show anything
<thomi> robert_ancell: latest mir bug I've found is posted at: https://bugs.launchpad.net/mir/+bug/1185183
<ubot5> Launchpad bug 1185183 in Mir "mir_demo_server hangs" [Undecided,New]
<kdub> i can try on my phone... see what happens
<robotfuel> I am using image 132, maybe that image has an issue.
<greyback> robotfuel: perhaps, that I cannot say. apt-get dist-upgrade all up to date?
<fginther> robert_ancell, it is very difficult to get the version numbers to 'reset', so what happens is, you'll see a version ending in '0' when the package is built due to a source change, othewise, the version will end in X, where X is always greater then the last X
<robert_ancell> fginther, ok
<robotfuel> greyback:  distupgrade fixed the issue, thanks!
<racarr> earrrly in. early out!
<greyback> robotfuel: glad to hear it.
<kgunn> cya racarr
<thomi> robert_ancell: got a second?
<robert_ancell> thomi, sure
<thomi> robert_ancell: so the bug I reported above is blocking the stress tests moving much further. I wonder who I should bug about this? Or should I just leave it with you and work on something else today?
<robert_ancell> thomi, I'll have a look at it
<thomi> robert_ancell: thanks
<robert_ancell> thomi, always exactly after 500 times?
<thomi> robert_ancell: 501 actually, yeah
<robert_ancell> weird
<thomi> yeah. I wondered if the sevrer was leaking 2 file handle per connection
<thomi> just a guess
<robert_ancell> thomi, why does it close the fd?
<thomi> robert_ancell: otherwise the client leaks them. see mail to ML
<robert_ancell> ok, that's just a workaround
<thomi> RAOF was going to fix that in the client API
<thomi> yeah
#ubuntu-mir 2013-05-29
<robert_ancell> thomi, RAOF, it appears the hang is due to a bunch of dmabuf fds being left open - seen that before?
<thomi> sounds similar to the last problem I had, buton the server side?
<robert_ancell> thomi, yeah
<RAOF> Oh, this is server side? We test that they get closed client-side.
<robert_ancell> RAOF, yeah, see bug 1185183
<ubot5> bug 1185183 in Mir "mir_demo_server hangs" [High,Triaged] https://launchpad.net/bugs/1185183
<robert_ancell> RAOF, where does the dmabuf stuff live in the codebase? Grep is not showing it - is it called something else?
<RAOF> robert_ancell: Yeah, grepping for "prime" should show it.
<robert_ancell> RAOF, ta
<robert_ancell> RAOF, which test are you referring to that checks the file descriptors for the client?
<robert_ancell> oh, appears to be tests/unit-tests/client/gbm/test_gbm_client_buffer.cpp
<RAOF> robert_ancell: Correct. (Sorry for the delay, saucy might not be entirely stable today)
<robert_ancell> I'm on saucy... could be impending doom for me?
<RAOF> Maybe if you've got two monitors.
<RAOF> (My system seems to like hangingish (possibly) when I've got two monitors enabled)
<thomi> hmmm, I'm on saucy with two monitors (sometimes three), and I haven't noticed anything today...
<robert_ancell> RAOF, btw, do we have to revert the drm magic change?
<RAOF> Yes
<robert_ancell> :(
<robert_ancell> no way around it?
<RAOF> Not without fairly invasive patches.
<RAOF> ie: we *could* add a MIR-DRI protocol to X that hands out drm fds, implement the mesa side, and have apps use that.
<RAOF> This seems like an awful lot of work when we could just have the drm magic API.
<alf__> alan_g: any thoughts on/objections to moving rpc related code in client to client/rpc and mir::client::rpc namespace?
<alan_g> alf__: the client code has grown enough to need splitting into separate concerns.
<alf__> alan_g: Agreed
<alf__> hikiko: @mir.fix-missing-virtual-destructors, the branch failed CI... (the unwritten rule is that you won't get any reviews until your branch passes CI)
<alf__> hikiko: just a heads up :)
<hikiko> :s
<alan_g> alf__: lttng problems? https://code.launchpad.net/~robertcarr/mir/input-lttng/+merge/166123/comments/368258
<hikiko> I compiled it
<hikiko> :s
<hikiko> I just put back the destr. and removed the headers you told me nothing else
<hikiko> let me check again
 * alan_g thinks http://www.codinghorror.com/blog/2007/03/the-works-on-my-machine-certification-program.html
<hikiko> alf__, what is the error you get?
<hikiko> i recompiled and got no failure
<alf__> alan_g: @lttng, no, that's normal, if you use the lttng library with a program that uses forks etc you also need to LD_PRELOAD=liblttng-ust-fork.so. I don't think that's the problem racarr is having though, I think he just needs to ld_preload the mir tracepoint provider.
<alf__> hikiko: check the failure logs from the MP
<alan_g> alf__: thanks - I misremembered the incantation. (and HACKING didn't help)
<alf__> mmrazik: Can we upgrade our VM CI builds to use raring? They are failing because they pull an old lttng-ust version with headers that have compilation problems with C++.
<mmrazik> mhm... still building on quantal?
<mmrazik> alf__: I'm on it
<alf__> mmrazik: great, thanks
<alf__> mmrazik: (probably VM autolanding, too)
<mmrazik> alf__: done. I triggered a test build to see
<alf__> mmrazik: thanks
<kgunn> reboot  to saucy (i hope)
<racarr> Morning
<alan_g> Afternoon
<racarr> comments on input-lttng :) thanks for pointing out LD_PRELOAD alf/alan
<racarr> neat stuff
<racarr> alan_g: What do you mean by "These don't gain by being inline" in reference eto d'tors in rebuild-input-targeting
<racarr> do they gain by being in implementation file?
<alf__> racarr: Yes, pretty cool. Soon (by EOW) we should have client side tracepoints, too, so we will be able to get some very interesting measurements for both input and rpc.
<alan_g> racarr: with an inline function the compiler needs to be ready to instantiate it in any TU that compiles the header. With it out of line it knows it only has to instantiate it in one TU.
<racarr> alf__: Excellent!
<alan_g> So, unless there is a reason to have functions inline, we put them out of line.
<racarr> alan_g: Hmm. ok
<alan_g> racarr: I just mean there's no reason for them to be inline.
<racarr> mm
<racarr> alan_g: Pushed some updates on rebuild-input-targeting
<racarr> share your fear about maybe we are breaking things now ;)
<racarr> this one is pretty simple...and we have some acceptance tests...but uh...I dunno
<racarr> I want lots more input acceptance tests
<racarr> test_client_input.cpp is a little precarious now so I think once this branch lands I am going to spend some time
<racarr> making a new InputTestFixture or something
<racarr> and hopefully getting lots of input scenarios under test
<alan_g> racarr: that should improve our confidence
<kdub> good morning, status, going to take another cleanup pass at the buffer swapper switcher algorithm, then mp. after that, maybe some performance measurements and writing an ipc message to signal performance hints to the server (like swapinterval 1/0, composition bypass)
<alf__> status: refactoring client code to accommodate lttng reporting (and improve the client code in general)
<kdub> alf__, yay :)
<alf__> all: Enjoy the rest of your day!
<mzanetti> alf__: you too
<mzanetti> :)
<alf__> :)
<racarr> Trying to find something for myself to do that doesn't conflict with my existing branches ><
<racarr> I guess the blueprints say I am going to do client focus notifications before June so I can do that...it only conflicts a little
<racarr> is focus a surface attribute?
<racarr> seems correct on the client side but incorrect on the server side
<alan_g> racarr: are you starting the "attribute" vs "association" discussion again?
<racarr> alan_g: Not exactly.
<racarr> alan_g: In this case I am wondering, in a more literal sense whether to model focus as a MirSurfaceAttribute
<racarr> but I guess it is that discussion
<racarr> in the current architecture to there is no clear way to deliver the "focus lost" events to the correct surface.
<racarr> So I am exploring refactorings, and it comes down to...(I think so far) to either
<racarr> Focus becomes some sort of surface attribute (a MirSurfaceAttribute, some sort of token that is moved around, something)
<racarr> or start tracking surface focus in what is now the session manager, which I would try and split in to like
<racarr> SessionManager->SessionStore, FocusArbitrator(Assosciator?)
<racarr> I mean, two objects, not some sort of inheritance there
<racarr> I'm also hung up on MirSurfaceEvent being part of MirEvent :p
<alan_g> How are you hung up?
<racarr> Trying to decide, how I want to model the event...and it doesn't really fit (unless it becomes a surface attribute)
<racarr> the way I wanted to do it was
<racarr> the old MirEventDelegate
<racarr> in addition to handle_event like it has now
<racarr> err like it had before it was removed
<racarr> would have grown methods like focus_received, focus_lost
<racarr> attribute_changed, etc.
<racarr> rather than an increasingly intricate MirEvent structure
<alan_g> racarr: it is *soft*ware - you can change it if it doesn't fit current needs
<racarr> Hehe. I know.
<racarr> I am just trying to figure out the boundary between my needs, and
<racarr> my attachment to certain aesthetics
<racarr> well strictly in this situation, I don't have any needs, the requirements do :p
<racarr> i.e. while I think it's clearer in my head through these focus_received/focus_lost delegates...that might just be because ive explored that model more
<alan_g> racarr: there are 20min to EOD - you can drag me into a discussion or let me review your MPs. Your choice.
<racarr> alan_g: Please ignore me
<racarr> XD
<racarr> thanks for reviewing :)
<racarr> sorry to be kind of scattered, just having trouble focusing (...*cymbal crash*) today.
<alan_g> racarr: np - you can review my trivial tidy-up MPs when your focus gets lost.
<racarr> Ill check them out
<racarr> Got some failing acceptance tests for client side focus notification. Lunch time!
<racarr> Back
<racarr> Hmm ok half got client focus notifications working, finished the tests...the implementation difficulty
<racarr> is calling surface->configure before the SessionMediator::create_surface has returned
<racarr> is a magnificent failure
<racarr> i.e. an event is sent to the client for a surface which it has not yet been informed has been created
<racarr> so I think I will need to create an EventSink which
<racarr> can buffer event streams or some such
<racarr> hold event streams until ready?
<kdub_> racarr, sounds kinda like
<kdub_> our surface creation mechanism needs some rework then
<kdub_> not sure how complicated that is ^_^
<kdub_> i get lost in the weeds of mf::Surface, msh::Surface and ms::Surface sometimes too
<racarr> Mm... *thinking cap*
 * kdub_ keeps finding ways to improve the SwapperSwitcher
<racarr> hmm
<racarr> it's pretty easy to wrap the EventSink in SessionMediator
<racarr> with something that delays until the surface has been created
<racarr> but then that lives there...forever -.-
<racarr> and you can futz with the interfaces some so it can rewire itself out or something but it just seems wrong.
<racarr> I guess first there is a bit of a design decision
<racarr> if a surface is created and focused when created
<racarr> do you receive a focused event?
<racarr> My initial thought was yes but it may be possible to simplify if no
<racarr> ...I guess
<racarr> if a branch + a virtual function call is really an overhead in surface attribute changing IPC notification
<racarr> someone can come back and find a different solution :p
<racarr> "CloggedEventSink" I'm pretty happy about that
<robert_ancell> thomi, tests working now?
<thomi> robert_ancell: will check
<thomi> just finishing my morning firefighting rounds
<kgunn> kdub_: ping
<kdub_> pong
<racarr> If anyone has time would appreciate another review on at least the InputDispatcher.cpp part of https://code.launchpad.net/~robertcarr/mir/rebuild-input-targeting
<thomi> robert_ancell: got a second?
<robert_ancell> yep
<thomi> robert_ancell: the single threaded stress test now works, but something in either allocating or deallocating surfaces is not thread safe, and causes the server to bork
<robert_ancell> thomi, bug/test-case?
<thomi> just filing it now :)
<robert_ancell> I'll have a look at it
<thomi> robert_ancell: the short version is to grab lp:~thomir/+junk/mir-stress ; build; run ./mir-stress -t 2 -n 10
<thomi> robert_ancell: bug filed: https://bugs.launchpad.net/mir/+bug/1185589
<ubot5> Launchpad bug 1185589 in Mir "Mir server crahes when allocating & freeing surfaces from multiple threads" [Undecided,New]
<robert_ancell> thomi, hmm, I just get the test prog blocking forever and no problems in the server - are you using Mir trunk or the latest package from the PPA?
<racarr> thomi: It's worth ruling out with --enable-input=false
<thomi> robert_ancell: latest from ppa
<thomi> racarr: that's on the server, right?
<robert_ancell> thomi, saucy or raring?
<thomi> saucy
<robert_ancell> racarr, have you noticed some input tests failing when you run ./native-compile.sh a second time? It appears there might be some data files left over from a previous run, but I can't seem to find them
<thomi> racarr: still happens with --enable-input=false
<thomi> robert_ancell: will try and get some stacktrace goodness for you
<thomi> oh - mir_demo_server helpfully prints a stacktrace when it crashes
<thomi> looks like it's a double-free
<thomi> in mir::frontend::SessionMediator::create_surface
<thomi> (that's me un-mangling the symbols in my head, so it might be a little off)
<racarr> robert_ancell: No I haven't... which tests? There are no files used afaik
<racarr> There are some weird things going on right now though. I see a weird intermittent build failure that I sometimes have to make clean for (something to do with DRM auth magic)
<racarr> and acceptance tests spew "ERROR: Event parsed"
<racarr> because somehow the client rpc report got switched to log by default or something
<robert_ancell> racarr, I'll get a log now
<robert_ancell> racarr, http://paste.ubuntu.com/5714864/
<robert_ancell> racarr, I'm *fairly* sure if I clean and rebuild it will work fine. This is lp:mir trunk
<racarr> robert_ancell: Interesting
<racarr> I will look in to it soon
<racarr> no immediate ideas
<robert_ancell> racarr, ok, ta
<racarr> all the ERROR: Event parsed stuff is unrelated
<racarr> and has to do with surface states
<racarr> Almost finished with client focus notification...
<racarr> working on testing the event stream blocking/unblocking in session mediator.
<thomi> robert_ancell: crashes with lp:mir as well. For some reason gdb isn't playing ncely though
<racarr> blah happy I made my acceptance test pass only to discover I am causing intermittent failures in BespokeDisplayServerTestFixture.server_can_shut_down_when_clients_are_blocked
<racarr> hmm
 * kdub_ is singing in my head "this is the branch that never ends"
<racarr> aha someone was sneaky in mfd::SocketSession ::send
<racarr> whole_message is surprisingly not a locally scopped variable
<racarr> and its a RACE
<thomi> robert_ancell: I finally managed to get a sensible stack trace for you: https://launchpadlibrarian.net/141048607/gdb.txt
<thomi> Is that illuminating at all?
<thomi> actually, that one looks like it might be in the input handling stuff.. racarr ^^
<thomi> and yet it crashes if I disable input as well, I wonder if the stack is the same
<thomi> racarr: I think I must have mis-typed earlier, it seems it doesn't crash when I disable the input system
<racarr> thomi: Oh that's good I was hoping it was my fault.
<thomi> errr... ok
<thomi> seems kind of masochistic, but OK
<racarr> thomi: Ok that's either
<racarr> well
<racarr> it's either corruption somewhere else
<racarr> or...fd exhaustion?
<racarr> because this is about
<racarr> socketpair failing
<thomi> it is?
<thomi> I didn't look up the failing assertion yet
<racarr> thomi: Check out 3rd_party/android-input/android/frameworks/base/services/input/InputTransport.cpp
<racarr> ok so it's not socketpair failing.
<racarr> its the fcntl O_NONBLOCK
<racarr> failing
<racarr> Ok
<racarr> I think I know what it is
<thomi> oh?
#ubuntu-mir 2013-05-30
<racarr> well
<racarr> fcntl(O_NONBLOCK...blabla
<racarr> cant fail immediately after socketpair suceeds
<racarr> so this must be from the second InputChannel constructor...due to an architectural bug now we
<racarr> end up creating two input channels
<racarr> at different times
<racarr> so there is a race between the first one closing and the second one being created
<kdub_> tricky
<racarr> that...could happen *thinks*
<racarr> Yes could happen!
<racarr> It is either fixed in rebuild-input-targeting
<racarr> *thinks*
<thomi> sounds likely, given that this is multi-threaded test
<racarr> ok it's very possible
<racarr> it's fixed in rebuild-input-targeting
<thomi> it's easy enough to reproduce, anyway
<racarr> if not it will definitely be fixed in this follow up branch I was planning on doing to get rid of the duplicate InputChannels
<thomi> racarr: that an unmerged branch?
<racarr> yes
<racarr> so I can fix it tomorrow
<thomi> ok
<thomi> In the mean time, I'll just disable input, and move on to rendering stuff
<racarr> you mean finding the next bug ;)
<racarr> I just found a race in surface states that can end up hosing the socket session XD
<thomi> yeah :)
<racarr> Ok client-focus-notifications is mostly finished I just need to rework some of the SessionMediator test fixtures.
<racarr> I'm also thinking a lot about input acceptance tests...
<racarr> it's frustratingly difficult to express really simple scenarios like
<racarr> one client opens, another client opens, once the second client has opened we send some input, then the second client closes and we send some more input to see that the first client gets it
<racarr> becomes a strange excercise in interprocess expectation synchronization every time
<racarr> so I am trying to come up with...a better fixture, because there are a good dozen (easily) meaningful input acceptance tests that we could put in place
<racarr> This focus notification test fixture comes closer to it but not quite
<racarr> However. This day is already an hour too long and I want to go rock climbing before I get evening sleepy
<racarr> so bye for now, will try and come back to finish off and submit client-focus-notifications :)
<RAOF> Today the part of Chris will be played by a sleep-deprived misanthrope.
<robert_ancell> RAOF, did you do that work on lightdm set defaults? I can do it now if you want
<RAOF> robert_ancell: I have not done that yet, thanks.
<robert_ancell> RAOF, there, it will cost you a review :) https://code.launchpad.net/~robert-ancell/lightdm/set-defaults-seat-type/+merge/166420
<RAOF> robert_ancell: That's probably a one-approve-to-merge review, right?
<robert_ancell> pretty much
<robert_ancell> normally with lightdm it's a zero-approve-to-merge :)
<RAOF> Hah. I can't approve it anyway :)
<robert_ancell> thomi, hmm, what's the CI complaining about here? https://jenkins.qa.ubuntu.com/job/lightdm-raring-amd64-ci/29/console
<robert_ancell> Looks like it might be trying to merge in the packaging twice?
 * thomi looks
<thomi> that does look borked. just checking the job config
<thomi> robert_ancell: problem was a config error in the cupstream tool. Have manually edited jenkins config, and re-run that CI job again. Will propose the fix for the config, so Francis can merge it & re-deploy jenkins jobs tomorrow
<robert_ancell> thomi, ok, thanks!
<thomi> no worries
<thomi> robert_ancell: also, lightdm & unity-system-compositor are now being dput'd to the ppa after every mir build
<robert_ancell> yay!
<robert_ancell> thomi, hmm, autolanding now failing? https://code.launchpad.net/~robert-ancell/lightdm/set-defaults-seat-type/+merge/166420
<thomi> robert_ancell: interesting failure :-/
<robert_ancell> RAOF, does this look correct? https://code.launchpad.net/~robert-ancell/mir/revert-drm-auth-magic-removal/+merge/166432
<RAOF> robert_ancell: Yes.
<robert_ancell> RAOF, I don't get the --trees arg to bzr init-repo - do you use it?
<RAOF> robert_ancell: You mean --no-trees? No, I don't.
<robert_ancell> RAOF, according to http://wiki.bazaar.canonical.com/SharedRepositoryTutorial --no-trees is the default I think
<RAOF> But that's because I want a working tree for my branches. If I were just serving branches out over ssh I'd want --no-trees.
<robert_ancell> working tree = directory with files in it to edit/build?
<RAOF> Right.
<robert_ancell> hmm, looks like --trees is the default when trying all cases
<RAOF> --no-trees is very similar to git's branches, except they're non-hidden directories rather than files in a hidden directory.
<RAOF> Yeah, --trees is totally the default.
<robert_ancell> oh, --no-trees means "all branches in one directory"?
<RAOF> No, it means âjust the branch metadata in the directoryâ
<RAOF> You can turn this into âall branches (effectively) in one working treeâ by use of lightweight checkouts and swiching.
<thomi> robert_ancell: that lightdm issue seems to be fixed. In the end it was related to the MBS rebuild changes we made
<RAOF> TIL that âauto fn(int foo) -> int { return foo; }â is a valid C++11 function definition.
<RAOF> For all the functional programming immigrants, I guess :)
<tvoss> RAOF, +1 :)
<alan_g> alf__: can you check https://code.launchpad.net/~robertcarr/mir/rebuild-input-targeting/+merge/165712 - the more eyes the better for this one
<alan_g> hikiko: ping
<hikiko> alan_g, :)
<hikiko> hi
<hikiko> I just merged your branch
<hikiko> I thought approving is enough for jenkins to merge it :/ sorry :)
<alan_g> hikiko: Only to trunk - your branch is your own. ;)
<alf__> alan_g: @rebuild-input-targeting, sure, @customisable-DefaultFramebufferFactory, I think jenkins is having network problems, and is scheduled to shut down, so autolanding will probably fail again :/
<alan_g> alf__: ack (otp)
<racarr> Morning
<alf__> racarr: hi!
<alf__> racarr: heads up: jenkins is offline
<alf__> racarr: actually it is online now but network is problematic
<racarr> :(
<kgunn> racarr: mornin'
<kgunn> racarr: i noticed the the platform-api bulk changes got merged
<alan_g> Afternoon
<kdub_> status,  dreaming up ways to break my swapper switcher... might put it in  pre-review now just to get some air on the MP
<racarr> kgunn: Cool ill update my branch today
<racarr> ugh
<racarr> 3 days of climbing in a row -> painful typing
<kgunn> rocks?
<racarr> https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/166440 exist
<racarr> kgunn: Fake rocks. I found a climbing gym like 3 blocks away
<kgunn> cool
<racarr> It's pretty fun as a form of excercise, they make little "puzzles"
<racarr> where you can only climb using holds of certain colors, etc, and have to get from one point to another
<racarr> and some of it is just strength/flexibility
<racarr> but the puzzles also have solutions...like "Oh I have to use this funny reach with my right hand to get this hold from underneath then its easy!"
<racarr> *babble*
<racarr> Fun stuff
<kgunn> racarr: i like stuff like that
<racarr> :)
<alf__> racarr: rock climbing is great, I used to do a lot outside on real rock when I was younger. Advice: don't over-do it, especially in the beginning. Muscles can get into shape much faster than tendons etc, so you start feeling stronger and want more, but it's easy to get strain injuries (e.g. tendonitis).
<racarr> alf__: Ah. That's good advice
<racarr> Thanks :)
<racarr> katie: I am ok for our meeting today but could be 1-2 minute late if the line at the coffee shop is long
<racarr> brb
<racarr> back
<katie> racarr, ok
<katie> racarr, i was a bit late too!
<alan_g> kdub_: ping
<kdub_> alan_g, pong
<racarr> Met with katie. Worked through some of the details for the tiled surface state (various maximized states). Talked about how minimized isn't really a state (i.e. a minimized window still shows in the maximized state it was in in the alt tab preview), it's just hidden
<racarr> Realized that the snapping constraints (i.e. anchoring) for the tiled state already apply to all windows
<racarr> so really the tiled state just means it had a previous floating size that it will be restored to when untiled
<racarr> We also talked about calling Surface States
<racarr> Surface Modes to be more explicit
<racarr> because it's unclear, why (for example)
<racarr> focus isn't a surface state
<racarr> i.e. if you asked someone who hadn't read the design documents, talk about the state of this surface
<racarr> Sorry internet failure!
<racarr> end of sentence: "Talk about the state of this surface" the first things that come to mind are like
<racarr> oh it's open, it's on top, it has keyboard focus, it has this size
<racarr> not necessarily, "Vertically maximized"
<racarr> what's going on with https://bugs.launchpad.net/mir/+bug/1183327
<ubot5> Launchpad bug 1183327 in Mir "Stress tests cause server to crash" [Medium,Fix committed]
<racarr> I thought we determined last night it was in the input channel stuf then as I was going to sleep got some email about
<racarr> a bug being assigned to me
<racarr> and now I can't find it
<racarr> https://bugs.launchpad.net/mir/+bug/1185589 :)
<ubot5> Launchpad bug 1185589 in Mir "Mir server crahes when allocating & freeing surfaces from multiple threads" [High,Triaged]
<greyback> racarr: agreed that minimized is more a flag on a surface. We want to maintain the surface geometry while minimized so it restores correctly
<racarr> greyback: Mm.
<greyback> racarr: could minimized be considered a special tiled state (i.e. docked to nothing)?
<racarr> greyback: That's what I was just thinking :)
<racarr> it has most in common with the tiled states, i.e. it snaps back
<greyback> yep
<racarr> but I think. actually with minimized it might be easier to just model it
<racarr> seperately
<racarr> i.e. rather than maintain/restore the geometry
<racarr> the surface never goes anywhere (there is no meaningful minimized geometry change imo...)
<racarr> so we just say it
<racarr> 's hidden
<greyback> that is probably easier
<racarr> Something I have started to think about lately
<racarr> with surface types/roles and surface states/modes
<racarr> is that tight coupling shows up the same way it does in code
<racarr> in "design languages"
<racarr> well, not exactly the same way XD
<racarr> but I think in general, rather than try and do the programmer thing (i.e. look for grand abstractions over the various design patterns)
<racarr> there is value to modelling the concepts seperately and more explicitly, even when they can be grouped
<racarr> because then we end up with more "interchangeable concepts" XD
<racarr> which is part of the difficulty, in trying to make the same words about surface management
<racarr> apply to the phone/tablet/desktop
<greyback> True that.
<greyback> well having not done a display manager/window manager before, I'm not sure what's the best approach. I guess start simple :)
<racarr> don't worry having done a window manager before im pretty sure all it did was fill me with lots of really strong opinions that have nothing to do with reality :p
<greyback> :D
<racarr> Merging rebuild-input-targeting
<racarr> Took down my computer with the stress test lol
<racarr> Oh I see
<racarr> input_registrar->input_surface_opened needs to be inside
<racarr> the lock_guard in ms::SurfaceStack::create_surface
<racarr> but i wanted to merge the input_registrar and the input_factory anyway so might take the time to fix it that way
<racarr> the race is the surface is destroyed  inbetween the call to surfaces.push_back(surface) and the input registration
<racarr> causing the input registration to fail on the closed fd
<racarr> shouldn't locking higher up solve this?
<racarr> this means that mf::SessionMediator::destroy_surface is being called from another thread before
<racarr> mf::SessionMediator::create_surface ever returns.
<racarr> It seems like we should lock the SessionMediator right, to guarantee
<racarr> in order processing of messages
<racarr> does that even guarantee that
<racarr> no lol
<racarr> Inbetween reading the event and calling the appropriate method on the SessionMediator
<racarr> another thread could read another message (true? y/n...I believe y)
<racarr> locking the session mediator, and handling messages out of order again
<racarr> locking the session mediator seems kind of reasonable though
<racarr> or is all this impossible
<racarr> because how does the client cause destroy_surface to be called until it has replied to
<racarr> until it has received a response to*
<racarr> create_surface
<racarr> hmm hmm hmm
<racarr> Could the IDs be getting mixed up somehow
<racarr> oh man
<racarr> I can use an lttng trace
<racarr> to see what is happening
<racarr> :O
<racarr> trying to use lttv but its not working :(
<racarr> all the messages look in a sensible order
<racarr> going to "fix" thi scenario even though I cant understand how it would happen and see if another bug exhibits
<racarr> It does by locking up my system :)
<racarr> perhaps a race in the communicator with assosciating the mediator...
<racarr> Almost sure this is two races...or like a race and a memory error...or...
<racarr> I ruled out everything I could think of that wasnt memory corruption
<racarr> then I tried to run mir demo server (without even the stress tests) nder electric-fence
<racarr> and it hung my entire system
<racarr> so i had to reboot and then i tried again
<racarr> with the same results XD
<racarr> ok whatever is going on. it seems to maybe not actually have to do with the race in this dual input hcannel creation
<racarr> but that's still a weird issue that can be solved by deleting code (After redoing some interfaces)
<racarr> so going to spend some time on that, and then see how this stress test issue remanifests
<racarr> lunch
<racarr> back :)
<racarr> I am not friends with this bug
<racarr> actually right now I am not friends with the difficulty of debugging and frequency of system restarts required
<racarr> the bug is kinda neat
<racarr> Interesting
<racarr> I moved it to an exception from the InputRegistrar
<racarr> requesting window handle for an unregistered surface
<racarr> I can't make gdb work without hanging my system -.-
<kgunn> robert_ancell: so i was reading this
<kgunn> http://blog.mecheye.net/2012/06/the-linux-graphics-stack/#rendering-stack
<kgunn> which was stellar btw...
<kgunn> but he said "With the new dumb ioctls in place, it is recommended to use those and not libkms."
<kgunn> are the "dumb ioctls" still considred kms ?
<robert_ancell> not sure
<robert_ancell> kgunn, asking in #phablet, they do expect to use the whole lightdm/unity-system-compositor/unity-greeter/unity stack for the phone - does that match your expectations?
<thomi> morning all
<robert_ancell> racarr, ping
<racarr> robert_ancell: Pong!
<robert_ancell> racarr, hangout?
 * kgunn reading the #phablet scrollback
<kgunn> robert_ancell: yes...matches my expectation
<robert_ancell> kgunn, no, I just wasn't sure that was what they'd decided on
<robert_ancell> thomi, do you know why mesa is -jenkins71 for raring and -jenkins1 for saucy in https://launchpad.net/~mir-team/+archive/staging/+packages?
 * thomi looks
<robert_ancell> It causes apt to downgrade the packages from raring->saucy, which I *think* is fine
<thomi> robert_ancell: yeah, it's because each series is controlled by a separate jenkins job, and it's the jenkins job build number that's used in the package version number
<thomi> robert_ancell: It was uploaded on the same date though, so I'm 99% sure it's the same package contents
<robert_ancell> any way to manually bump the number up so they match?
<thomi> I may be able to finesse the numbers in the jenkins job, let me take a look
<robert_ancell> also, any chance of getting jenkins to build xorg like it is for mesa?
<thomi> robert_ancell: ok, I've patched the build script, so it will shortly upload a new -jenkins71 package for saucy. However, it's kind of fragile. As soon as the build for one series passes and the other series fail the versions will get out of sync again
<thomi> but at least people upgrading from raring->saucy won't get their mesa downgraded anymore
<thomi> robert_ancell: how is xorg currently built?
<thomi> robert_ancell: it looks like RAOF manually dputs it?
<robert_ancell> thomi, yes, I think so
<robert_ancell> thomi, will the same out-of-sync problem happen for the other jobs?
<thomi> robert_ancell: no, these jobs are special since we're not using the autolanding infrastructure, since the source is external
<thomi> i.e.- github
<robert_ancell> yeah
<thomi> if launchpad still mirrored git repos :)
<robert_ancell> oh, it stopped doing that?
<racarr> thomi: Can you trigger the crash with the stress test
<racarr> and input on
<racarr> even if you don't
<racarr> move the cursor at all
<racarr> I think I might have fixed part of it?
<thomi> racarr: in mir trunk?
<racarr> Sure
<racarr> now if I don't thrash the cursor its all fine
<racarr> if I thrash the cursor
<racarr> im not actually sure that its not a deadlock
<racarr> instead of a crash
<racarr> because im never able to interact with my system again without rebooting
<racarr> XD
<thomi> racarr: I never touch teh cursor
<racarr> hmm
<thomi> racarr: in fact, moving the cursor on my laptop doesn't move the arror in mir_demo_server... is it supposed to?
<racarr> well I think that part of it I found then, and there is another part...when you thrash the cursor over thrashing clients
<racarr> thomi: If you have permissions on /dev/input*
<racarr> input/*
<thomi> racarr: I see.
<thomi> racarr: the server no longer crashes, but it still has problems. It seems to get in a state where some call the client is making blocks forever, and the client prints out:
<thomi> ERROR: Invocation failed: id: 0 method_name: connect error: Broken pipe
<thomi> ERROR: Header receipt failed:  error: End of file
<thomi> right before hanging
<racarr> that's possible
<racarr> im a few fixes ahead of trunk atm in my branch
<racarr> "fixes"
<racarr> I do n't know which of the three "races" I fixed
<thomi> racarr: heh, ok
<racarr> stopped the problem yet XD
<thomi> racarr: if you put your branch somewhere publci I can run the tests for you.. in about 10 minutes time
<racarr> oh
<racarr> I think I found the deadlock
<racarr> a deadlock
<racarr> ...is thi going to come down to moving one line :(
<racarr> well and adding another one somewhere else
<racarr> we should install a kill handler
<racarr> all the way down in the input stack so as long as the InputReader thread is running
<racarr> even if the SurfaceStack is deadlocked
<racarr> you can kill mir
<racarr> hmm no hard to solve the lock
<robert_ancell> racarr, well, the kill handler should be in the shell
<racarr> robert_ancell: but I mean it should be installed lower than EventFilter
<racarr> which is the only mechanism we provide now
<robert_ancell> why not do it in the event filter?
<racarr> because the EventFilter is run from the dispatcher thread
<racarr> and interacts with all the other threads
<robert_ancell> then don't deadlock that one :)
<racarr> well, ideally right.
<racarr> ;)
<kdub_> we need a cleanup tuesday again
<racarr> kdub_: Yes!
<kdub_> racarr, i went to add a function to the surface, and found that i want to cleanup these interfaces a bit while i'm here :)
<racarr> do it :) it needsss it
<racarr> Hey!
<racarr> I really fixed it that time
<racarr> Either that or I am having an extraordinary run of race condition luck
<racarr> that would be cruel
<racarr> the final dead lock was between the input registrar the dispatcher and the surface stack
<racarr> I think it's resolved but it changed what was a really simple (albeit not working) locking pattern
<racarr> in to...a locking dance
<racarr> which is never a nice thing to maintain
<racarr> so I need to think about it more
#ubuntu-mir 2013-05-31
<racarr> I have to go through the process now of extracting all these different little changes now
<racarr> and figuring what fixes what and what goes in what branch
<racarr> and it' brutal because I know im going to lock up my whole system 10 times in the process
<racarr> XD
<RAOF> Well, that was an odd door-knock.
<RAOF> âAre there any Catholics in the house?â
<robert_ancell> RAOF, did then then break out some turntables and have some sort of Catholic rave?
<RAOF> Wika wika waaaaaow!
<racarr> lol
<RAOF> robert_ancell: There's currently no infrastructure for lightdm to determine what type of session to run based on the result of a canary binary, is there?
<RAOF> Because it would be pretty easy to write a canary binary for âcan unity-system-compositor possibly workâ
<thomi> ok, dumb question: It seems the demo_server will render all surfaces at 0,0 right? Is it the responsibility of the shell to determine where things get rendered ?
<RAOF> thomi: Yes.
<RAOF> Well, it's the responsibility of the shell to do all the window managementy bits, of which âwhere should this window beâ is obviously one.
<thomi> I see. So what will the demo server do when multiple surfaces are rendered? I assume the last one to render will be the one shown?
<thomi> i.e.- it'll overwrite, not do any kind of alpha blending?
<RAOF> racarr?
<RAOF> My last understanding of the status was that exactly one surface would be non-hidden, so... :)
<racarr> Yes at the moment
<thomi> oh
<thomi> that doesn't seem very friendly :)
<robert_ancell> RAOF, no
<RAOF> robert_ancell: Is it something you think would be reasonable to have?
<robert_ancell> RAOF, it doesn't really fit with the design, so I'm thinking it will be easiest to just make the "unity" seat type revert to VT switching if it wants to (it's not a lot of code, just need to copy the logic from src/seat-xlocal.c to src/seat-unity.c)
<robert_ancell> And long term we can drop the fallback from seat-unity.c probably
<robert_ancell> RAOF, do you know what sort of code we need to make the decision? If it's not too complex we can put it into seat-unity.c directly
<RAOF> robert_ancell: We need to iterate over the drm devices that udev iterates for us, then call drmModeIsSupported() on each. It's not a lot of code.
<robert_ancell> RAOF, also, I was wondering if we should just put the check into the system compositor, and the unity seat falls back to VT switching if the system compositor doesn't exist or starts (e.g. due to not having supported drivers)
<RAOF> That sounds reasonable.
<robert_ancell> RAOF, I'm making it support the VT fallback case now
<RAOF> Cool.
<secret_ninja> cool, there are ppl. here.. awesome.. preparing to install mir now.
<RAOF> I'll check that unity-system-compositor does the right thing.
<secret_ninja> does it work on nividia fx 5200?
<RAOF> Should do, as long as you're using nouveau.
<secret_ninja> so, i gotta switch back to noveau.
<secret_ninja> that's not a prob., just lose my s-video output.. :(
<secret_ninja> im quite interested in getting involved in development of mir..
<robert_ancell> secret_ninja, awesome! :)
<robert_ancell> brb
<mycoguyco> secret ninja is hung up. im him. so, i gotta downgrade to nouveau..
<mycoguyco> quiet in here
<RAOF> Yeah, you need nouveau. We don'tÂ¹ run on the proprietary drivers.
<RAOF> Â¹: But are working to make that happen.
<thomi> RAOF: is there a higher level API to render to a surface than what's done in the unaccelerated demo? I mean, without using gl ;)
<secret_ninja> ok. i just lose svideo out..
<RAOF> thomi: GL *is* the higher-level rendering API :)
<secret_ninja> im interested in development.
<secret_ninja> this project sounds very interesting.
<thomi> RAOF: yeah... I guess I should just use that
<RAOF> thomi: Although you could probably also use Cairo and render using that.
<secret_ninja> will it compile with llvm?
<secret_ninja> was *vaguely* intersted in playing with llvm also.
<secret_ninja> pretty quiet in here
<RAOF> secret_ninja: It will complie with clang, but might not run.
<RAOF> secret_ninja: If you wanted a good project to start with, ferreting out why the unittests fail when built with clang would be nice :)
<secret_ninja> aight. might be byting off more than i should all at once, but why not..
<RAOF> Fixing unit tests does at least give a very obvious means of checking progress ;)
<secret_ninja> i haven't yet played with llvm yet. much more fam. with gcc, but wanting to play with llvm..
<secret_ninja> dont have high expectations.. :)
<RAOF> You should have. clang produces error messages about an order of magnitude better than g++
<secret_ninja> really? heh, i liked g++ errors..
<secret_ninja> more /etc/X11/Xsession.options
<secret_ninja> wrong window
<RAOF> :)
<robert_ancell> RAOF, https://code.launchpad.net/~robert-ancell/lightdm/unity-vt-fallback/+merge/166631
<racarr> Back for a while!
<RAOF> You midnight owl, you!
<racarr> 8:55!
<racarr> thomi: So not moving the cursor I can't reproduce any problems with trunk
<thomi> racarr: ok, let me re-pull and re-build
<racarr> thomi: That may be a complete lie
<racarr> it may just be very intermittent
<racarr> yeah ok ive still got a crash
<thomi> racarr: it happens pretty frequently here... as in, within 10 seconds
<racarr> now I can start applying fixes
<thomi> cool
<thomi> you're using mir-stress ?
<racarr> yeah
<racarr> atm I am eating indian food but at a later point I will be using mir-stress again
<thomi> oh man, I'm jealous
<thomi> although... it is "Fish and Chip Friday", so that's something to look forward to I guess
<racarr> :)
<racarr> I was obsessed with fish and chips when we lived in england when I was young
<racarr> obsessed XD
<thomi> New Zealand fish and chips are a little different
<thomi> there's none of that malt vinegar shenanigans, for a start
<racarr> I'm only in it for the batter.
<racarr> the thing that still worries me about all this is I understand
<racarr> the deadlock that shows up after I "Fix" the crash
<racarr> but I can't find any possible set of circumstances where the race for this crash to happen
<racarr> would happen
<secret_ninja> woohoo.. compiling llvm and clang
<secret_ninja> d/l'ing mir.
<racarr> secret_ninja: Don't party too hard
<racarr> ;)
<secret_ninja> blarg, gonna sleep through the compile and d/l.
<racarr> Cya.
<secret_ninja> iim only getting 15k/sec on the d/l and it is 700 megs
<secret_ninja> 14 hrs left.
<secret_ninja> reminds me when i pirated digital unix for an alpha i had at home back in the 90's.
<secret_ninja> i was on isdn
<secret_ninja> took all wknd
<secret_ninja> quick llvm question...should i do an optimize or profiled build?
<RAOF> secret_ninja: Doesn't really matter.
<secret_ninja> wasn sure if profiling did anything arch specific
<secret_ninja> i just did optimized. damn, i specified arch x86_64 ( ive got amd 64 bit). won't be able to compile to other archs.. damn, i gotta start thinking more.
<secret_ninja> or, will i?  guess ill find out.
<RAOF> I'm not quite sure why you'd want to build for other archs at this point.
<RAOF> You *can*, with a chroot or a cross-compiler or similar.
<RAOF> But that's not really interesting unless you want to deploy on a phone or somesuch
<secret_ninja> ok, that's what i was thinking when i installed, that i would just be compiling for this arch.. but, if i get into coding again, im gonna wanna check my code compiles for all archs.
<secret_ninja> even though i can't test resulting binary code
<secret_ninja> still compiling, still d/l'ing mir.. gonna be all night on the c/l.. dunno how long compile will take.
<RAOF> On a reasonable system Mir shouldn't take more than 10 minutes or so to build.
<RAOF> Generally speaking you don't need to care about having your code compile on different architectures. That's the compiler's job :)
<secret_ninja> lame shit.. didn't rename clang-3.2.src to clang and it didn't compile it by default..
<secret_ninja> recompiling.
<secret_ninja> mir at 25%.. woot, woot.
<RAOF> Any particular reason why you didn't just install clang from the repositories?
<RAOF> Maybe you're not running Ubuntu?
<secret_ninja> i like to compile from source
<secret_ninja> Linux citadel 3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:14 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
<secret_ninja> leftover habit from openBSD days.
<RAOF> Heh.
<secret_ninja> been running linux since 94.
<secret_ninja> and, i gotta say, 13.04 is the best one ive seen yet.
<secret_ninja> this way, i know that the llvm and the clang are the correlating versions.
<secret_ninja> no /lib probs, etc
<secret_ninja> he's gonna need a temp ban.
<secret_ninja> it's still compiling..
<secret_ninja> morphis is away..
<secret_ninja> no ops in here?
<secret_ninja> mir is 33%
 * RAOF wonders who has ops here
<xrc> good day
<xrc> I was playing around with mir - got it from the ppa:mir-team/staging
<xrc> it didn't install the unity-system-compozitor untill a couple of ours ago
<xrc> then I forced it to get the latest mir-server that has been kept back
<xrc> and now after a reboot I am stuck at the ubuntu loading screen
<xrc> no login window
<xrc> I've logged in and used 'startx'
<xrc> and all seems to be fine
<xrc> but I need it to work after the restart
<xrc> I haven't changed the lightdm.cfg to start mir
<xrc> so I'm a bit confused
<xrc> can anyone help me ?
<xrc> I'll be on a couple of hours
<xrc> in case anyone here can help me
<xrc> thanks in advance!
<alan_g>  xrc I don't know what's happened on your system - FWIW mine runs fine without lightdm.cfg changes. But "forced it to get the latest mir-server" sounds like something I don't do. Could you expand on that?
<xrc> alan_g, well, I was following this bug: https://bugs.launchpad.net/unity-system-compositor/+bug/1177722
<ubot5`> Launchpad bug 1177722 in Unity System Compositor "mir ppa : unity-system-compositor should be built against latest mir libraries" [High,Fix released]
<xrc> alan_g, so today when I did a sudo apt-get update followed by sudo apt-get upgrade, all the packages seemed to install just fine
<xrc> alan_g, I even got the unity-system-compositor installed
<xrc> alan_g, then I noticed some packages that were not updated
<xrc> alan_g, and they were libmirserver0 and mir-demos
<xrc> alan_g, gimme a sec, I'll dig up the commands I used from history
<xrc> alan_g, so basically I first did an update, then and upgrade
<xrc> alan_g, it installed the new lightdm and unity-system-compositor and all that were not installed because of the bug above
<alan_g> xrc: that ought to work - you didn't override anything then?
<xrc> alan_g, but it showed that libmirserver0 and mir-demos were held back
<xrc> alan_g, so I forced them via 'sudo apt-get install libmirserver0 mir-demos'
 * alan_g checks - he's not updated for a few days, so probably isn't running what's in the ppa today
<xrc> alan_g, I guess the problem is that when I did force to install the new version - it killed lightdm (uninstall)
<xrc> alan_g, and now lightdm can't be installed cause it tries to get the one from the mir server ppa, and that one won't install because of the broken dependencies issue
<alan_g> xrc: sounds possible. It is a development stack, and does break sometimes
<xrc> alan_g, how can I get the default lightdm from official ubuntu repositories to install?
<alan_g> xrc: Personally, I tend to reinstall to get to a known state. But it ought to be possible to force uninstalls and reinstalls with e.g. deselect (but when that doesn't work straight away it costs more time than a reinstall).
<alan_g> others here might have other ideas
<xrc> alan_g, ok, I got lightdm reinstalled from the official ubuntu repositories
<xrc> alan_g, now it's being held back from upgrade, because of the bug I mentioned before. This was the state of my machine for a few days )
<xrc> alan_g, as a side note - where can I register this nickname so when I'll log in into IRC on #ubuntu-mir it will represent only me?
<alan_g> xrc: http://freenode.net/faq.shtml
<xrc> alan_g, thanks a lot!
<alan_g> xrc: yw
<kgunn> alan_g: alf__ do we actually have blur algorithms in mir ?
<alan_g> kgunn: I'm not aware of any. (yet)
<kgunn> alan_g: go it...that's how i understood it "we may add"
 * alan_g goes it
<kgunn> alan_g: :)) just saw it...
<kgunn> meant "got it"
<alan_g> kgunn: I guessed. Who wants a blur algorithm?
 * alan_g wants the inverse - the "enhance" algorithm used on TV
<kgunn> alan_g: oh your team mates on the unity ui....talking about how qt's blur is expensive
<kgunn> and chatting as if they can just "try mir's" when it lands
<kgunn> :)
<alan_g> I guess that will be after they MP it. ;)
<alf__> kgunn: what do they want to blur?
<kgunn> alf__: well, its more that design wants to blur ;)
<kgunn> alf__: at least 1 use case is the lock screen blur of the app behind it
<kgunn> which may very well be changing/updating visually
<kgunn> i think we'll prob end up doing semi-live blur (but not live as that's pretty expensive)
<alf__> kgunn: sorry, had to reboot and missed your answer, could you repeat please?
<kgunn> alf__: well, its more that design wants to blur ;)
<kgunn> alf__: at least 1 use case is the lock screen blur of the app behind it
<kgunn> which may very well be changing/updating visually
<kgunn> i think we'll prob end up doing semi-live blur (but not live as that's pretty expensive)
<kgunn> we could call on nic-doffay for the algo work
<alf__> kgunn: The shader/algo work is the least of our problems for blur :) It's how and where (in terms of the mir-unity stack) we integrate it that needs discussion. But let's leave that for when the time actually comes.
<kgunn> alf__: sure
<kdub_> alan_g, ping
<alan_g> kdub_: pong
<katie> kgunn, alf__ ,  there are other use cases for the blur: the hud, search results on the dash and media player.... just fyi ;)
<katie> swap use cases to uses
<kgunn> katie: ack
<kdub_> hey all, mp'd the swapper switcher, got partially through the new ipc capability, but got distracted by wanting to clean up some things
<racarr> Morning!
<secret_ninja> g'morning al
<secret_ninja> l
<secret_ninja> im *almost* done d/l'ing mir, during the d/l, i got several gateway timeouts. how can i just get the files that didn't d/l?
<secret_ninja> anybody here?
<kgunn> secret_ninja: ?...you mean prebuilt bins?
<kdub_> its sort of funny how msh::Surface is a proxy class for ms::Surface, and has its own logic too
<secret_ninja> kgunn: im pretty sure source...
<secret_ninja> i can paste the line i used to get it, but i can't figure out what it is...
<secret_ninja> mk-build-deps --install --tool "apt-get -y" --build-dep debian/control
<alan_g> kdub_: I've questioning that for months. ;)
<secret_ninja> unless itis the bzr command.. not sure, guess ill have to wait for the d/l to finish.. was like 1.2 gigs.
<kgunn> secret_ninja: so you're downloading on the phone...yep....just suffer
<kgunn> secret_ninja: its just the build dependencies to build mir
<kdub_> alan_g, i'm tempted to clean up a bit...
<secret_ninja> how can you tell im d/l'ing on the phone?
<kdub_> i'll stop cleaning when the diff gets to be >1000 though :)
<kgunn> brb
<alan_g> kdub_: I've had related discussions with racarr recently, not sure if he's started something. Worth checking.
<racarr> nothing yet :)
<kdub_> ah, ok. the first thing i'll probably hit is that ms::Surface has public member functions that aren't behind an interface
<secret_ninja> kgunn: question was, will i have to reget the whole source tree, or can i somehow just get the files that failed?
<alan_g> kdub_: also, ms::Surface has attributes for things that I think the shell should associate with the surface.
<secret_ninja> Get:152 http://us.archive.ubuntu.com/ubuntu/ raring/main texlive-font-utils all 2012.20120611-2 [1,681 kB]
<kgunn> secret_ninja: not sure how smart the tools are, i honestly don't know of any arg to ask for partial....but i would assume its smart
<secret_ninja> Err http://us.archive.ubuntu.com/ubuntu/ raring/main ttf-marvosym all 0.1+dfsg-2
<secret_ninja>   504  Gateway Time-out [IP: 91.189.91.15 80]
<secret_ninja> crossing fingers.. ;0
<kdub_> alan_g, right, i kinda detect that some shell state has been creeping in
<alan_g> kdub_: yeah, it is pretty unclear why it is there in that form - I'll be happy to see it cleaned up
<kgunn> secret_ninja: gonna have to run in a minute
<kgunn> but where are you trying to build ?
<kgunn> natively (on the phone)
<kgunn> or on your pc
<kgunn> secret_ninja: please keep the conversation in public as it might help others
<secret_ninja> alright. well, im not d/l'ing to my phone, im d/l'ing to my pc, using phone as gateway.
<kgunn> secret_ninja: what do you intend to do ? where do you want to compile ?
<secret_ninja> mostly seeing texlive right now, saw ruby earlier (in the download). it's a 1.2 G d/ll. prolly just going to restart the d/l after it is done and hope the tools are smart enough to just get the parts that failed..
<secret_ninja> im going to compile on my pc..
<kgunn> secret_ninja: ah...i get you now....so last one, emulated or cross compile ?
<kgunn> gotta run
<secret_ninja> am i in the correct place? going to run it on my pc as X replacement
<secret_ninja> nothing to do with phone..
<secret_ninja> aight, have nice day. :)
<racarr> I gess you are downloading the build depedencies? I don't know any magic to speed it up :)
<secret_ninja> not worried bout the time. worried bout several files that failed to d/l due to gateway timeout..
<secret_ninja> d/l over 14 hours old. just woke up and saw several errors re: gateway timeout and d/l failures..
<secret_ninja> only 94% done, but getting there
<racarr> 1 line: https://code.launchpad.net/~robertcarr/mir/fix-default-surface-lock/+merge/166831
<racarr> p.s. if you are scared of deadlock mir_demo_server & sleep 45 && killall -9 mir_demo_server && chvt 7 is a great way to run mir
<secret_ninja> racarr: kgunn asked if i was going to build it natively, or on the pc, but im going to build it natively on the pc.. this is also supposed to run on pc's, right??? not just phones..
<racarr> Yep :)
<secret_ninja> uh-oh.
<racarr> I think he thought you were building for the phone
<racarr> so he was asking if you were cross compiling from PC or building
<racarr> on phone
<secret_ninja>  Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
<racarr> but its all good on desktop too :)
<secret_ninja> yes.
<secret_ninja> my d/l just quit on me with the above error..now i don't know what to do.. it was 94% and im *not* starting all over... anybody know where i put the --fix-missing option?
<racarr> I don't think it will help
<racarr> apt-get wont start all over
<racarr> run apt-get update :)
<racarr> apt-get won't start all over ("probably")
<racarr> but it goes to apt-get I don't know how mk-build-deps calls that
<secret_ninja> phew, smart tools rock.
<secret_ninja> man, i was getting *so* pissy. glad it only has to get 90M this time..
<racarr> haha...I am just updating a test and one of the random test strings
<racarr> is the song I am listening to now...
<racarr> around and around...*facepalm*
<alf__> secret_ninja: Keep in mind that you won't get anything really usable in terms of a desktop environment right now
<racarr> Another small diff https://code.launchpad.net/~robertcarr/mir/improve-input-channels/+merge/166841
<kdub_> racarr, good lead-in on the description :)
<racarr> :)
<racarr> thanks for quick review..
<racarr> trying to split out the ...4! things I found yesterday XD
<alan_g> kdub_: which egl implementation are we using in the android stack? I think I need to look at the code to figure out what's happening.
<kdub_> alan_g, i sort of want to answer 'egl 1.4', but don't know if thats what was being asked :)
<alan_g> kdub_: Probably the result of my thinking being unclear.
<alan_g> kdub_: for some reason, not obvious in mir code eglSwapBuffers() behaves differently with a CB mode server than a default one. But I'm not sure which repo to grab code from to look at.
<kdub_> well, to look at the egl code, its closed :(
<alan_g>  /o\
<racarr> https://code.launchpad.net/~robertcarr/mir/fix-surface-stack-input-locking/+merge/166852 another smallish one
<racarr> Maybe instead of the lock dance (there is another part of it coming up in the registrar)
<kdub_> alan_g, the interface the egl driver uses is in 3rd_party/android-deps/system/window.h
<racarr> we should use r/w locks
<kdub_> i just wrote one!
<racarr> a r/w lock?
<kdub_> racarr, yeah, in ~kdub/mir/swapper-swapper
<kdub_> its a writer biased one
<alan_g> kdub_: found that. OK, maybe tomorrow will bring inspiration.
<racarr> mm interesting
<racarr> what kind of bias do we want in the surface stack...I can almost convince myself either way
<racarr> sounds more likely a reader bias right
<racarr> who cares if we are updating a bunch if we never get to render
 * alan_g remembers it is friday (and he's going to a dance)
<racarr> Though something I learned from all the profiling on toyds
<racarr> is that I have a 100% incorrect track record on guessing the effects of biased r/w locks :p
<racarr> alan_g: Cheers :) enjoy
<kdub_> alan_g, maybe i'll write a mail about how to deal with the blob or something
<kdub_> there are a few inroads to investigate
<alan_g> r/w locks are tricky things
<kdub_> yeah
<racarr> in toyds I had like
<racarr> 10 different ideas for how I was convinced they were going to eliminate
<kdub_> probably why i didn't find a rw lock in the c++11 <mutex> :)
<racarr> all my contention and speed thing way up
<racarr> and they all failed XD
<racarr> kdub_: I think it is coming in C++14
<racarr> pthread has one
<racarr> which I wonder if we should use over mutex/condition variable
<racarr> I guess it's unbiased.
<racarr> which is weird
<alan_g> kdub_: the absence of a rw lock in C++11 was deliberate
<kdub_> yeah, smarter to let people think hard about it for a while!
<kdub_> racarr, i had thought about that...but i said 'early optimization', and used the mutex/cv
<racarr> kdub_: Good choice I think :)
<alf__> kdub_: racarr: I have pushed lp:~afrantzis/mir/client-lttng-wip in case you want to use it for any client/server measurements today. Have a great weekend!
<racarr> alf__: Thanks! very cool cant wait to start getting full system input measurements
<racarr> enjoy your weekend too :)
<alf__> racarr: kdub_: don't forget to use: LD_PRELOAD=libmirclientlttng.so MIR_CLIENT_RPC_REPORT=lttng for the client
<racarr> Sigh
<racarr> this locking bit between the input and surface stack
<racarr> is this huge like
<racarr> hidden coupling
<racarr> that can be commented or clarified
<racarr> but I wish there were a clear way to express it in the API
<racarr> I'm sure there is
<racarr> I wish I could come up with it immediately
<racarr> :p
<kdub_> racarr, i'm thinking in the same arena right now too
<racarr> kdub_: Any ideas?
<racarr> the one I am running in to, is for example this surface stack lock. Where the surface stack can't call out to the input registrar
<racarr> while it's holding its own lock
<racarr> because the input registrar, calls a function on the input dispatcher, which is locked by a lock that is shared with some InputDipatcher code run from another thread
<racarr> that can block on the surface tack
<racarr> But how can that be express in the API...
<kdub_> racarr, i'm currently driving out some coupling with some tests on the ms::Surface
<kdub_> which my hope is that it will chase out those sync issues
<racarr> sometimes you can pass around a mutex to say you must have to hold a lock
<racarr> but what's...the antipattern
<racarr> lol
<kdub_> heh
<racarr> you could pass
<racarr> the mutex
<racarr> and then the consumer has to be able to try_lock/unlock it
<racarr> but that's
<racarr> kind of absurd
<racarr> https://code.launchpad.net/~robertcarr/mir/fix-input-registrar-locking/+merge/166864
<racarr> last one
<racarr> :)
<racarr> running the stress tests and thrashing the mouse around seems to work indefinitely
<secret_ninja> can i switch between X and mir with a reboot?
<racarr> with all these
<racarr> secret_ninja: You can without a reboot :) I'm not sure exactly what you are asking/expecting though
<racarr> you can't run a full user session on mir yet (excluding XMir of course). Or at least not one that you could replace your desktop with
<racarr> so normally we run mir on a vt and x on a vt and you can switch back and forth and everyone is happy :)
<secret_ninja> im *just* wanting to see what it looks like and how it runs. what apps it can use. and maybe help with development.. i dont know the status of the project, but want to play with it.
<secret_ninja> so, inside of Xwin, open an xterm and run mir.. ?
<racarr> I understand :D
<racarr> no from a virtual terminal, but you will want to run some clients too...
<racarr> we can test one of the demo clients just to see if it's working
<racarr> So, right now for VT switching to work you need to run it as root
<secret_ninja> ive worked in the industry for like 20 years as unix admin, was involved with original ide (intergrated drive electronics) hard drives at arcada software and seagate.
<racarr> so in your mir build directory should have /bin/
<secret_ninja> involved with linux since 94.
<racarr> from a VT as root run bin/mir_demo_server
<racarr> secret_ninja: Ehe great. I bet you have had lots of X headaches over the years ;)
<racarr> then from another VT you can run say /bin/mir_eglplasma
<racarr> (also as root, since Mir is root)
<racarr> and switch back to the Mir VT
<racarr> you should see some...flowing ubuntu colored plasma XD
<racarr> I'm just about to run to the coffee shop though so be back in 5.
<secret_ninja> yea, multiple monitors, vid cards, serial terms (oh, the days of amber screens).
<secret_ninja> i gotta run to store also, ill bbl
<racarr> cheer
<racarr> s*
<secret_ninja> :)
<secret_ninja> gonna need lots of help, but also naturally good at puters. simple questions first. in build dir, run "cmake .." and it wants to use gcc. i would like to use clang
<secret_ninja> do i rename gcc and ln clang to gcc?
<racarr> It's possibly fixed in clang trunk
<racarr> but with clang from the packages there is a bug with their shared_ptr implementation
<racarr> that prevents mir from running
<racarr> secret_ninja: ^
<racarr> Sometimes we build with clang for the diagnostics, etc, you can ue
<racarr> cmake .. CMAKE_CXX_COMPILER=/usr/bin/clang++ CMAKE_C_COMPILER=/usr/bin/clang
<racarr> err
<racarr> cmake .. -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_C_COMPILER=/usr/bin/clang
<racarr> I heard you building clang and llvm earlier and thought of warning you but I thought maybe you were just building it for mesa XD
<racarr> if you built clang from trunk, you should try running mir and then report back but quite possibly expect it to crash
<racarr> a first step would be trying the tests with clang
<racarr> you can run ctest
<racarr> and if it fails, inspect individually /bin/unit-tests /bin/integration-tests /bin/acceptance-tests
<racarr> ./bin*
<secret_ninja> aight, wasnt sure if i could set a variable for it or something.. :)  i have clang from repository in /usr/bin/clang and have src for clang, but after i did the make for llvm, i couldn't find clang, that's when i did apt-get for it.
<racarr> ah
<racarr> yeah wont work sorry :(
<secret_ninja> yea, just found that..
<secret_ninja> but, i have src for clang.. any use? i can fallback to gcc though
<secret_ninja> prolly easier
<secret_ninja> are ya'll at the point of fixing simple errors during compilation(i.e. missing field initiatializers errors?) non-critical, compilation continuuing, but should be fixable relatively easy..
<racarr> secret_ninja: It builds in clang
<racarr> secret_ninja: And mir itself builds under clang without warnings (mostly gmock, etc) as part of our continuou integration
<racarr> but won't run :(
<secret_ninja> gave up on clang, went to gcc. it's 45%. but, saw several errors and comparing signed and unsigned integers in some of the routines
<kgunn> secret_ninja: if you are willing...show up on monday about 3pm US CST
<kgunn> we are doing some stress testing
<kgunn> ....and we are going to continue that
<kgunn> we've fixed what we've found so far...but i am sure we'll find more stuff
<secret_ninja> efinite.
<racarr> kgunn: Actually I think there is still a heisenbug ;) basically the surface/input relationship was getting in to an invalid state due to some weird bits about the input channel
<racarr> and the weird bits about the input channel were nice to fix anyway
<racarr> for other (not exhibiting yet) reasons
<racarr> but then
<racarr> this invalid state, could only be triggered by an
<racarr> "impossible"
<racarr> set of calls
<racarr> i.e. something going wrong in frontend
<racarr> so it seems that is likely still happening it just doesn't crash anymore and we have to find another way to make it surface
<racarr> I dunno. I'm thinking about it :)
<racarr> err. to make it surface like a submarine, not surface like a window
<kgunn> racarr: good one....submarine :)
<racarr> kgunn: Submarine is the new minimized
<racarr> just like surface is the new window and mode is the new state
<racarr> last decade: "This window is in the minimized state"
<racarr> this decade: "This surface is in submarine mode"
<racarr> :p
<racarr> kdub_: Is swapper-swapper ready for review?
<racarr> Is it going to hurt my head the description makes it sound like it might hurt my head
<kdub_> yes to both! :)
<racarr> kdub_: Also we should try and grow the architecture in a way that eventually ends up also with a SwitcherSwapper because that's hilarious
<racarr> i.e. we swap between various swapper switchers based on battery mode/plugged in
<racarr> ;)
<racarr> ill start now and go for lunch soon then review in detail after lunch :)
<kgunn> kdub_: on swapper swapper....does the client need to worry about blanking the buffs ?
<kgunn> e.g. if he has data in them that he doesn't want to be unsecure
<kdub_> kgunn, if the client is the one requesting the switch, he's the one who produced the data anyways
<kdub_> and we're not doing composition bypass swapping just yet
<kdub_> so the buffers that are transferred to the new swapper are still the same old ones the client produced
<racarr> Does anyone need me to be around for the next hour and a half or so?
<racarr> Rephrased: Does anyone mind if I take a super long lunch XD
<kgunn> kdub_: got it.....its lunatic fringe anyway....it'd only be a couple of buffers
<kgunn> dang you racarr
<kgunn> no
<kgunn> :)
<racarr> Excellent I'm going to go eat on top of a hill and stare at the water :D
<racarr> Back!
<kgunn> racarr: so did greyback provide any feedback on depthify stack ? (did he actually try to use)
<racarr> kgunn: Not yet afaik
<racarr> the thing is the shell never directly calls SurafceController::create_surface , instead it just creates a QWindow and the magic happens
<racarr> so need to go down and make changes to qtubuntu really but
<racarr> not the best timing :)
<kgunn> racarr: thanks...but i guess you were expecting him to make the qtubuntu changes
<racarr> kgunn: No
<racarr> I just mean there is no point in me doing it now and then doing it a second time after
<racarr> the platform API changes
<racarr> well not much point
<racarr> I thought he might try hacking something together if he had time XD but...where does the time go?
<kgunn> racarr: if i only knew
<racarr> kgunn: You are an excellent weekly reporter
<kgunn> racarr: i excel at data aggregation
<kgunn> sadly not much more :)
#ubuntu-mir 2014-05-27
<alan_g> RAOF: didn't you propose a barrier type recently? Did it land?
<RAOF> alan_g: Please could you define the context of âbarrierâ :)
<alan_g> RAOF: sync - multiple threads waiting for all ready
<RAOF> alan_g: I think it did, let me check.
<alan_g> ted: are you looking at the right example? I see Nick's name on the code.
<ted> alan_g, Heh, I just closed the window so I can't check now.
<alan_g> ted: this is the right version - https://code.launchpad.net/~mir-team/mir/trusted_sessions/+merge/221028
<ted> alan_g, Ah, okay, I definitely wasn't looking at that.
<alan_g> ted: make a note then - that's the one to watch. ;)
#ubuntu-mir 2014-05-28
<RAOF> bschaefer: MIR_CLIENT_INPUT_RECEIVER_REPORT=log is your winning ticket.
<bschaefer> RAOF, thanks!
<tsdgeos> alberto_: is https://code.launchpad.net/~albaguirre/unity8/use-new-display-power-state-interface/+merge/219552 ready for review or work in progress? If it's WIP can you please mark it as such to remove it from the "queue" of stuff that needs to be reviewed?
<alberto_> tsdgeos: it should be ready for review... I don't expect to change the signatures again
<alberto_> tsdgeos: ready for review but not landing
<alberto_> due to the deps
<tsdgeos> alberto_: oki :)
<bschaefer> RAOF, so, no events working on bregmas laptop. I also just found out its on trusty, and pretty far behind mirclient wise
<bschaefer> the mir staging for trusty is 1541, and staging on utopic is 1661, sooo possibly its been fixed in mir?
<bschaefer> no events are getting to SDL2 ----> mir only on unity8
<bschaefer> err
<bschaefer> mir ----> SDL2
<RAOF> May well be fixed in Mir?
<RAOF> Or possibly Unity8, unless he's using a local build.
<bschaefer> yeah, theres a lot of possible fixes that could have landed
<bschaefer> hes a second touch laptop we'll test out
<bschaefer> on 14.10
#ubuntu-mir 2014-05-29
<bschaefer> RAOF, testing two finger on my  touchpad ends up dragging my window around (in mir_demo_server_shell)?
<bschaefer> and it seems to do action_up/action_down?
 * bschaefer will show you the log later
<bschaefer> drags the window if i hold alt down + two finger drag
<RAOF> Bitchn'
#ubuntu-mir 2014-05-30
<duflu> dandrader: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/eglapp.c#L96
#ubuntu-mir 2015-05-25
<rsalveti> /usr/include/ubuntu/application/instance.h:28:44: fatal error: mir_toolkit/mir_client_library.h: No such file or directory
<rsalveti>  #include <mir_toolkit/mir_client_library.h>
<rsalveti> building gst-plugins-bad1.0 against proposed
<rsalveti> would be nice to do a reverse build-dep check before changing stuff
<rsalveti> it build fine with release, which is mir 0.12
<rsalveti> hm, mir is not a direct dependency in gst, maybe something else changed in platform-api that caused this
<rsalveti> In file included from /usr/include/ubuntu/application/ui/window.h:31:0,
<rsalveti> actually this is also broken in vivid, sigh, it's just that it only builds that code on i386 and armhf
<rsalveti> the header file is there, maybe the include path is broken
<rsalveti> hm, can't even rebuild platform-api
<rsalveti> all sorts of issues
<rsalveti> https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1458680
<ubot5> Launchpad bug 1458680 in platform-api (Ubuntu) "platform-api FTBS in wily (2.9.0+15.04.20150326-0ubuntu1)" [Undecided,New]
<rsalveti>      switch (mir_event->type)
<rsalveti> Â«BUILDDIRÂ»/platform-api-2.9.0+15.04.20150326/src/ubuntu/application/common/mircommon/event_helpers_mir.cpp:28:22: error: invalid use of incomplete type 'const MirEvent {aka const union MirEvent}'
<rsalveti>      switch (mir_event->type)
<rsalveti> [1432591771.428143] <WARNING> Loader: Failed to load module: /usr/lib/i386-linux-gnu/mir/server-platform/input-stub.so (error was:/usr/lib/i386-linux-gnu/mir/server-platform/input-stub.so: undefined symbol: _ZN3mir6events10make_eventExx17MirKeyboardActionjij)
<rsalveti> when trying to start unity8 on the emulator (vivid)
<rsalveti> bug 1458689
<ubot5> bug 1458689 in mir (Ubuntu) "[vivid-overlay] input-stub.so fails to load on i386" [Undecided,New] https://launchpad.net/bugs/1458689
<robert_ancell_> RAOF, around?
#ubuntu-mir 2015-05-26
<robert_ancell> So, since mir_surface_set_event_handler has completely changed what's the correct method to ifdef this so code compiles on both versions of Mir?
<robert_ancell> Yeah, so it looks like no-one is updating mir_toolkit/version.h
<robert_ancell> Same goes for MirEvent
<robert_ancell> RAOF, what's the correct way  to handle Mir events in the main thread now?
<robert_ancell> And if the answer is no change, how do I copy events now the structure is opaque?
<alan_g> kdub: @"eglMakeCurrent(egldisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, eglctx)" - I thought (probably wrongly) that eglctx was needed for updateAnimation()
<kdub> looking again
<kdub> alan_g, no, doesn't look like its needed for that
<kdub> it probably doesn't hurt though, because if the context is still current, the lifetime is extended past eglDestroy context, until the context is no longer current
<kdub> but... it doesn't call eglDestroyContext() anyways :)
<tsdgeos> guys
<tsdgeos> what's up with mir_input_event_get_touch_event vs mir_input_event_get_touch_input_event ?
<tsdgeos> which one should we be using?
<tsdgeos> because qtubuntu seems to be using one but the other seems to exist
<tsdgeos> there was a rename recently?
<tsdgeos> kgunn: anyone that can know this stuff? ââââ
<dandrader> tsdgeos, there was a refactoring in the input events, but it all landed a month ago or so
<tsdgeos> dandrader: maybe we have not updated qtubuntu to use those correctly?
<dandrader> tsdgeos, yes, maybe
<tsdgeos> dandrader: i.e. can you build qtubuntu?
<tedg> Seems that the autopkg tests for mir are all passed, does anyone know why Mir is still in wily proposed?
<dandrader> tsdgeos, hmmm, actually qtubuntu should already be using the latest mir input api
<alan_g> kdub: @eglInitialize do we need exactly major.minor == 1.4? Or std::tie(major, minor) >= std::tie(1, 4)?
<kgunn> tsdgeos: yeah...so, just found out
<kgunn> overaly doesn't have a check....
<AlbertA> tsdgeos: yes there was a rename, the first one is the one
<kgunn> but archive does....
<tsdgeos> dandrader: build failed here
<kgunn> so mir stuck
<kgunn> tsdgeos: is this shell rotation on wily  ?
<kgunn> (i was assuming)
<kdub> alan_g, the first one, its somewhat of an api check
<tedg> kgunn, But it seems the checks are passed? No?
<tsdgeos> kgunn: yes, well it's qtubuntu on vivid too
<tsdgeos> it just doesn't build for me
<tsdgeos> http://paste.ubuntu.com/11372143/
<tedg> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir
<dandrader> tsdgeos, you mean vivid+overlay_ppa?
<tsdgeos> thus qtubuntu on shell rotation doesn't build either
<kgunn> tsdgeos: i'm about to add qtubuntu to our silo 30
<tsdgeos> dandrader: yep
<kgunn> for wily
<kgunn> right...so mir landed in vivid+overlay (which it sholdn't have)
<kgunn> and i need to add qtubuntu to mir silo 30 for wily
<kgunn> then go back and rebuild qtubuntu in overlay
<tedg> kgunn, I don't think you can add to the silo after it is published?
<tsdgeos> kgunn: ok
<kgunn> tedg: don't worry...we're on it
<tsdgeos> i'll EOD now since i did an early start this morning due to the jet lag
<kgunn> o/
<tedg> K, just want to be able to test my silo, which built against Mir 0.13.
<alan_g> kdub: cleanup pushed to unity-system-compositor/spinner-rework
<kdub> thanks, looking again
<kdub> alan_g, lgtm
<racarr> hmm
<racarr> err whoops
<racarr> Hi anyway though
<racarr> Apparently theres a real launchpad bug being worked on :(
<racarr> Lunch! be back in a bit...new-input-dispatcher pipeline fixed up...now doing some onomotopoeia required for platform-api changes that should have landed with 0.13 to land
<racarr> P.S. Im still using the silo on my phone and that dash freeze hasnt shown up again
<anpok> hm yes, gst-plugins-bad currently does not use papi, and might be better off when we have the new buffer api to do the buffer handling directly
<anpok> there are just a fair amount of unused includes that pulled in papi in with that code that did not work with current mir
<racarr> so I guess a fix needs to land in gst-plugins-bad to not use the include
<anpok> it might also work by just fixing papi
<racarr> what papi headers does it use
<anpok> it pulls in application/ui/{window,options,display,session}.h
<racarr> Yeah those are all dead
<racarr> it needs to be fixed
<racarr> papi is no longer a mir abstraction
<racarr> ah
<racarr> the qtubuntu changes are the respones required to duflus renames
<racarr> I'll submit a branch after I escape emulator hell
<racarr> if I do :p
<kgunn> camako: do you know what day we landed mir0.13.0 in vivid+ ?
<kgunn> camako: nvmd...i'll cross check
<racarr> rsalveti: https://code.launchpad.net/~mir-team/platform-api/delete-deprecations/+merge/254170 its working now
<rsalveti> that's a lot of removals
<rsalveti> guess just needs ricmm's blessing
<racarr> yeah if we get nervous we can just delete the mir implementation and keep the headers around ...e.g. slightly less delete than the initial proposal
<racarr> but I'd be pretty happy to get rid of it...
<racarr> so much dead code lol
<racarr> mir_input_event_get_<NOUN> mir_keyboard_event_<NOUN>
 * racarr rage
<racarr> anpok: What's going on with gst-plugins-bad did you propose a fix or should I figure out how?
<racarr> https://code.launchpad.net/~mir-team/qtubuntu/track-mir-deprecations/+merge/260214
<racarr> here is the qtubuntu branch
<racarr> needed
<racarr> kgunn: What are the bug# for all this release breakage
<racarr> fixes up for qtubuntu and platform-api...trying to digest gst-plugins-bad nmow
<kgunn> racarr: so no bug# for qtubuntu...mir is just stuck in proposed for wily
<kgunn> there is a bug for platform-api
<kgunn> one sec
<kgunn> racarr: this one
<kgunn>  https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1458680
<ubot5> Launchpad bug 1458680 in platform-api (Ubuntu) "platform-api FTBFS in wily (2.9.0+15.04.20150326-0ubuntu1)" [Undecided,New]
<racarr> kgunn: Oh I see I already found that one this morning
<racarr> sorry lol
<racarr> ok I dont think anything more can be done until
<racarr> 1. PAPI needs signoff from ricmm
<racarr> 2. Qtubuntu update needs review
<racarr> 3. Gst-plugins needs questions answered then port to mirclient (few hours of effort)
<racarr> or delete
<racarr> 4. Rerelease
<camako> damn that's a lot
<kgunn> yeah...whoa
<kgunn> racarr: so this was an abi break yes ?
<kgunn> or no....guess it was a hard api break
<kgunn> cause papi failing
<kgunn> how the heck did this ever land in vivid+ ?
 * kgunn is confused
<racarr> kgunn: As far as I understand
<racarr> things built against an old version of Mir
<racarr> due to some sort of issue
<racarr> and
<racarr> well
<racarr> lol
<racarr> I guess we need a revision to our instructions
<racarr> for the lander because
<camako> kgunn: alan_g had this to say about why things worked :
<racarr> it would have been obvious if there was a step like uh
<camako> "<alan_g> OK the reason we didn't see problems is that we didn't force an uninstall of libmircommon3 so things just continued working"
<racarr> "Think if what you are landing makes sense" lol
<racarr> because we all knew we broke API so the fact that we werent releasing
<racarr> PAPI should have been a huge red flag
<kgunn> right, so we had old libs present to make things happy
<racarr> I'm not sure we how we can encode that in to the release process...
 * kgunn actually wondered at one point why there was no papi in the silo
<camako> we removed the server dependency
<kgunn> just thot alan was being clever
<racarr> :) I never looked.
<racarr> mm
<racarr> yeah
<racarr> we should add a step to the doc where
<racarr> the lander asks everyone if they think their expected branches
<racarr> are in the silo
<racarr> ...lol
<racarr> more process
<racarr> [I unno
 * camako is still confused... PAPI doesn't depend on Mir server any more, so why should there have been a break? 
<racarr> mirclient
<racarr> multiple mirclient API and ABI breaks
<racarr> 1. event.h is now private
<racarr> 2. Event 2.0 symbols got renamed
<racarr> 3. direct access of surface buffers etc is now deprecated and you have to use
<racarr> buffer_stream_*
<racarr> 4.....omg I just saw it
<racarr> oh
<racarr> set_event_handler now
<racarr> takes callback, context intsead of
<racarr> MirEventDelegate
<camako> racarr, so this wasn't correct : "Mirclient ABI unchanged at 8"
<racarr> camako: I don't see how it could be.
<racarr> 1 and 3 Is just an API break
<racarr> are just an API break
<racarr> uh
<racarr> 2...is technically an ABI break in libmircommon right
<racarr> because the symbosl got moved from libmirclient to libmircommon
<racarr> it seems like
<racarr> #4 is just a plain old ABI break though
<racarr> unless someone has done something clever
<racarr> undoubtedly there are numerous API breaks
<camako> racarr, on your still-to-do list above :
<camako> 1- which MP needs signoff from ricmm
<racarr> camako: I sent it in an email as well
<racarr> but https://code.launchpad.net/~mir-team/platform-api/delete-deprecations/+merge/254170
<racarr> ugh
<camako> oh ok thanks
<racarr> omg its so big
<camako> lol
<racarr> Diff against target: 9656 lines (+48/-9073) 59 files modified
<racarr> lol
<racarr> I definitely know what all that code is *smiles and nods*
<rsalveti> kgunn: can we work on a test, for mir, that would try doing a reverse builds for everyone in the reverse-build-dep list?
<rsalveti> kgunn: just thinking on how we could avoid such platform-api breakage on the future
<kgunn> rsalveti: please speak with camako
<rsalveti> camako: ^? :-)
<camako> rsalveti, we have abi-compliance checker to notify us of ABI breaks... I'm scratching my head how this would not have been caught by that
<kgunn> i was just wondering the same
<kgunn> but camako it would only tell you mir abi broke
<kgunn> and you need to "do something"
<kgunn> it was the "somethings"
<rsalveti> afaik the change included removing headers and calls
<kgunn> it wouldn't tell you
<racarr> It was mostly API breaks anyway
<rsalveti> right
<racarr> we could have a "test"...but uh
<racarr> preventing it is really easy lol
<racarr> if Mir API breaks rebuild downstreams
<rsalveti> my question is how could we systematically avoid that in the future
<racarr> in the silo
<racarr> and we failed to do that during release
<rsalveti> right, which is why I want a check/test that would verify that automatically
<kgunn> technically this did get caught in wily
<rsalveti> and block the landing
<rsalveti> did it?
<kgunn> but didn't in our ghetto ass vivid+overlay
<racarr> rsalveti: Yeah autopkgtests
<racarr> catch it right
<racarr> because they do this
<racarr> reverse building
<rsalveti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<rsalveti> mir is a valid candidate in there
<kgunn> rsalveti: one sec
<AlbertA> racarr: libmirclient was still ABI compatible....
<AlbertA> but there is something yet not root caused
<racarr> AlbertA: If nothing else the set_event_handler
<racarr> was an ABI break right?
<racarr> the others were just API breaks
<racarr> afaics
<AlbertA> racarr: there's an ABI compatible version of it though....
<AlbertA> racarr: but of course if a downstream needs rebuilding...
<kgunn> rsalveti: it's still stuck on this check afaik
<kgunn> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<AlbertA> then yes you would hit that
<racarr> AlbertA: Right API break downstream needs rebuilding
<racarr> OH
<kgunn> so it may look ok, but it's still in proposed
<racarr> I have an idea
<rsalveti> kgunn: but there is nothing platform-api related in there
<racarr> we told ourselves we didn't need to rebuild in the silos because we thought it was only an API break
<rsalveti> right, I think something else blocked it
<racarr> but
<racarr> because its not API compatible the
<kgunn> rsalveti: right, qtubuntu
<racarr> autopkg tests that uh
<racarr> build the rdeps for the proposed promotion (this is what happens right?)
<racarr> of course fail
<rsalveti> right, we might need an autopkg test in platform-api that would include such rebuild
<rsalveti> and ideally the same for every mir client we care
<rsalveti> but, this would only work for wily
<kgunn> rsalveti: except aren't we trying to drop that ?
<rsalveti> not for the ghetto silo
<racarr> oh I guess I thought we had that and thats why it was failing in proposed
<rsalveti> kgunn: are we?
<rsalveti> I think we're trying to drop autopilot
<kgunn> rsalveti: sorry..."that"...i thot racarr said we should drop the dependency from papi to mir
<kgunn> qtubuntu will still have one on libmircommon
<racarr> mirclient*
<kgunn> oh...and client
<racarr> but yes when delete-deprecations we
<racarr> can drop the dependency
<rsalveti> right, if we remove the mir dependency entirely, then we don't need to worry with it
<camako> we can have all the tests/checks that we want.. if thy don't get run for the ghetto, then we ain't catching anything
<racarr> I think if we're going to continue down this line we have to focus on
<racarr> figuring out what happened first
<camako> yeah we need to let alan_g do his thing with the release and then put checks/tests in place
<camako> definitely more to be discussed tomorrow
<racarr> I think
<racarr> our ABI checker did its job but
<racarr> because of the
<racarr> rebuilding at the proposed gate
<AlbertA> racarr: camako: yeah there's some subtle ABI break with the libmircommon dep
<racarr> if we break API
<AlbertA> that's not entirely obvious....
<kgunn> right, alan was saying what AlbertA just said ^
<racarr> we can't skip updating things
<racarr> it doesn't seem like the ABI break is the problem though because
<racarr> the packages work when you install them
<kgunn> racarr: i'll repost here what alan shared
<racarr> e.g. as we did in Dallas to test the hotfixes
<racarr> okj
<kgunn> forgive me if this doesn't work
<kgunn> ah crap...lemme pastebin it
<kgunn> racarr: AlbertA.... ok
<kgunn> https://pastebin.canonical.com/132012/
<AlbertA> kgunn: right...
<racarr> Yeah I guess part of the problem is we really did break ABI (though again...things seemed to work)
<racarr> and then the other part is...we broke API and tried to avoid rebuilding downstreams
<racarr> but we cant do this because they get rebuilt
<racarr> in the archive
<robert_ancell> speaking of breaking API and ABI...
<racarr> so breaking API without breaking ABI isn't a real thing for us
<robert_ancell> :P
<kgunn> robert_ancell: glad to see things have progressed so far since you were playing with us :)
<robert_ancell> kgunn, aha I was thinking everything stays the same!
<AlbertA> racarr: right...so need to update release process
<racarr> Yeah
<racarr> lol its not more of the same
<racarr> its a new situation that we've never run in to before
<AlbertA> racarr: breaking API automatically needs rebuilt of all libmiclient rdeps
<racarr> and we hopefully wont run in to again if we can figure out a sensible
<racarr> process
<kgunn> but, a result in trying to be clever
<racarr> AlbertA: Yes. I think thats enough
<robert_ancell> anpok, what does "TA" mean in https://code.launchpad.net/~robert-ancell/mir/buffer-stream-prototype/+merge/260094?
<racarr> kgunn: Yeah you could spin this as a result of trying to be clever lol
<kgunn> i always thot we should bump downstreams always
<racarr> and or save time
<racarr> Probably trying to save time more than being clever ;)
<AlbertA> kgunn: well so far we have avoided breaking API in the client
<AlbertA> until now
<racarr> well and we've never tried to do an
<AlbertA> precisely to avoid rebuilding all rdeps
<kgunn> true
<racarr> API break no ABI break
<racarr> afaik
<kgunn> all true
<racarr> right because weve just
<racarr> avoided API break since like
<racarr> 0.6
<racarr> lol
<kgunn> i know....we should break it more often to get used to it :-P
<racarr> robert_ancell: It means top approve
<robert_ancell> racarr, aha, thanks
<AlbertA> kgunn: well that's what ryan suggested in a way...
<racarr> robert_ancell: :D
<robert_ancell> racarr, kgunn, so the API/ABI break issue I have is the new input functions and XMir. We want to get the new XMir running in vivid to keep kgunn happy for phone work but also want to get it into the wily archive. I've been updating the code to work in wily but there doesn't seem to be any way of ifdefing the code to handle both.
<robert_ancell> Also using ifdefs will be a major PITA since the changes are quite significant.
<robert_ancell> What was you intention (if any) for handling a case like this?
<racarr> ugh...I see
<racarr> robert_ancell: The intention was that the new input functions were already out
<racarr> for a release and
<racarr> the old way was deprecated in 0.12 already so you were supposed to be able to build against 0.12 and 0.13
<racarr> by using hte new API
<robert_ancell> racarr, oh, should I be able to do all this in vivid currently?
<kgunn> robert_ancell: so the deal is...we landed in vivid+overlay
<kgunn> we're trying to sync to wily
<racarr> robert_ancell: I think so
<kgunn> when we discovered this little poop pile
<robert_ancell> kgunn, yeah, so should I not be SRUing to vivid and just relying on a new Mir via an overlay?
<racarr> lol sounds even better
<racarr> maybe
<kgunn> right...and as soon as we fix all this, it'll be in vivid+overlay and wily both
<racarr> alan_g and raof have opinions on SRUing to vivid
<racarr> that I wasnt able to understand
<racarr> but they were discussing it :)
<kgunn> at least mir0.13.0 (and eventually mir0.13.1)
<robert_ancell> It's desirable to SRU to vivid to remove all traces of the old code and thus reduce the confusion from bug reports
<kgunn> mmm
<robert_ancell> kgunn, where is the overlay PPA?
<kgunn> robert_ancell: do you really need it? or ...if you flash an image from a certain channel you'll get it
<kgunn> on the device
<robert_ancell> kgunn, I was just wondering how to get XMir into it
<robert_ancell> With the API/ABI issues etc I'm thinking it will be best to target wily archive and overlay PPA for XMir and then look at vivid SRU as a target of opportunity.
<kgunn> robert_ancell: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay
<kgunn> camako: wait check this ^
<kgunn> see the warning at the top
<camako> ok
<kgunn> does that mean it's truly borked
<kgunn> 13.1 didn't go in
<kgunn> so not borked...nvmd
<camako> kgunn, at the top where?
<racarr>  Mirv 0.13.1+15.04.20150520-0ubuntu1 CI Train Bot Account (2015-05-21)
<racarr> ?
<racarr> err
<kgunn> camako: at the top of the web page
<kgunn> for the overlay ppa
<racarr> I don't get a warning
<racarr> on that page
<racarr> what does it say?
<kgunn> Copying failed of mir (0.13.1+15.04.20150520-0ubuntu1)
<camako> me neither
<racarr> hahaha love that launchpad
<racarr> anyway I see a Mir package in the list so *shrug*
<camako> you mean this : https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages
<racarr> Yeah I see it there
<racarr> hmm
<racarr> weird error
<kgunn> racarr: camako ...yeah, maybe it's just latent...that's wrong, mir 13.1 is there it seems
<camako> yea I see the pkg so ??
<camako> kgunn, so it landed on v+o
<kgunn> yeah
<camako> but didn't sync in wily yet
<kgunn> sorry,i just freaked cause we had so many other issues
<camako> yeah I don't know if we should all freak
<kgunn> racarr: i know you already sent one...but if any other news/info rises on this...can you make sure to hand off to alan in an email ?
<racarr> kgunn: Ok np on both
<RAOF> robert_ancell: I don't know if racarr has answered you, but âmir_event_refâ is what you're after.
<robert_ancell> RAOF, why does it have a big "DO NOT USE THIS" above it?
<racarr> hahahahahahaha
<racarr> robert_ancell: Because it's really mir_event_copy so the performance characteristics
<racarr> are unpredictable
<racarr> um
<racarr> sigh
<robert_ancell>  *
<robert_ancell>  * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<robert_ancell>  * _________________________
<robert_ancell>  *< Don't use mir_event_ref >
<robert_ancell>  *-------------------------
<robert_ancell>  *       \   ^__^
<robert_ancell>  *        \  (oo)\_______
<robert_ancell> *            (__)\       )\/\
<robert_ancell>  *                ||----w |
<robert_ancell>  *                ||     ||
<robert_ancell>  * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<robert_ancell>  * NOTICE: mir_event_ref and mir_event_unref are implemented in terms of copy until
<robert_ancell>  * such point whereas direct MirEvent access as deprecated. This means you must
<robert_ancell>  * use the return value as your new reference
<robert_ancell>  *
<robert_ancell>  */
<robert_ancell> ok
<racarr> Its
<racarr> perfectly safe to use imo but
<racarr> duflu was being hyper pedantic on review imo and refused to let it through
<racarr> so we ended up with this
<robert_ancell> haha!
<racarr> I hate
<racarr> that im always blaming things
<racarr> on other people
<racarr> but thats what happened from my perspective
<racarr> lala
<robert_ancell> RAOF, I had a question regarding DRI2 and Xorg. Since we need DRI2 for XMir it's been copied across from hw/xfree86. I was looking to make it common like dri3 to avoid this but the PCI scanning code seems quite tricky to keep without copying too much of xfree86 across. Do you think it's possible to make it common?
<robert_ancell> I'm guessing an XMir upstream proposal would get shot down for copying dri2.
<RAOF> Hm.
<RAOF> Yes.
<robert_ancell> yes=it's possible or yes=it would get shot down
<racarr> the mir_event_ref thing is an exact example of the kind of thing I was trying to outline in Dallas where we try and push for this false ideal of 100% correctness in reviews
<racarr> leading to a bunch of noise (this comment)
<RAOF> It's... probably? possible to make it common.
<racarr> to prevent a situation which would never happen
<racarr> (someone trying to use mir_event_ref in a performance critical way)
<racarr> Then do we even reach the ideal of correctness...I can spot 4 or 5 errors in that comment alone (contraction in formal writing, failure to capitalize start of sentence, incorrect about at which point mir_event_ref and mir_event_ref will be reimplemented, use of personal pronouns)
<racarr> lol
<racarr> (and to be clear it's my comment...)
<racarr> when this happens we just eventually hit a level of noise (e.g. in this case the Cow, or "StreamDepiction" in surface-buffer-access)
<racarr> where the discussion stops making sense and the
<robert_ancell> Also, I read the text below the cow over and over again and I'm still not 100% sure what it means.
<racarr> revisions end, but not because of improvement but
<racarr> just because of having sufficiently confused the reviewers
<racarr> robert_ancell: lol...
<racarr> robert_ancell: It means use the return value of mir_event_ref
<AlbertA> robert_ancell: it should have read...don't use it as "ref" but as a copy....
<racarr> As your new reference :D
<AlbertA> i.e. don't do mir_event_ref(event)
<robert_ancell> ok
<AlbertA> do event = mir_event_ref(event_orig)
<racarr> which the compiler warns you about anyway :p
<racarr> so really just don't worry
<racarr> and have fun with mir_event_ref
<AlbertA> which BTW was my original contention with mir_event_ref as opposed to mir_event_copy .... :)
<racarr> lol
<racarr> lol im soured for reviews now....EOD I think
#ubuntu-mir 2015-05-27
<Mirv> racarr: I'm not versioned
<racarr> Mirv: lol
<racarr> Mirv: some sort of strange copy paste error with weird symbols
<racarr> I thought you might think it was funny though
<Mirv> :)
<Mirv> this channel gives me highlights anyway since you also have the mirvfb..
<anpok> tldr
<racarr> lol
<racarr> Good morning!
<racarr> alan_g: To answer some of your questions in other channel and in my email
<racarr> I thought that as part of
<racarr> the promotion from proposed to
<racarr> archive
<racarr> the reverse dependencies are built and
<racarr> that is causing these failures
<racarr> which is what halted the promotion?
<racarr> http://packaging.ubuntu.com/html/auto-pkg-test.html
<racarr> Packages which have autopkgtest enabled will have their tests run whenever they get uploaded or any of their dependencies change. The output of automatically run autopkgtest tests can be viewed on the web and is regularly updated.
<racarr> maybe that doesnt involve
<racarr> a rebuild though?
<alan_g> racarr: we're discussing in standup hangout
<alan_g> it really shouldn't involve a rebuild - it should be testing the contents of archive
<dandrader> alan_g,  wily still has mir 0.12.1. do you know what's the ETA for 0.13 there?
<alan_g> dandrader: working on it. I need to get a fix into qtubuntu before it can land
<anpok> finally it udevs behavior makes sense
<anpok> -it
<bschaefer> racarr, hey, was there new changes to mir library?
<bschaefer> 'mir_surface_get_graphics_region' is deprecated?
<bschaefer> as well as swap surfaces?
<racarr> bschaefer: mir_surface_get_buffer_stream, mir_buffer_stream_get_graphics_region ;)
<racarr> surfaces are getting multiple buffer streams
<racarr> for decorations and other strange use cases
<bschaefer> racarr, i see, looks like ill have to start getting things moved over then :)
<bschaefer> Thanks!
<racarr> np
<anpok> kdub: what do you mean by disable the cursor? just hide the cursor more.. no cursor position processing / confinement..?
<bschaefer> racarr, question, how come theres mir_event_type_key, mir_event_type_motion and under mir event input theres mir_input_event_type_key/pointer?
<bschaefer> shouldn't the mir_event_type_key/motion just be mir_event_type_input? (which means you shouldn't need them?)
<racarr> bschaefer: Yeah they will go away in next release
<racarr> it was this whole
<racarr> strategy to change the event without breaking ABI
<racarr> mir_event_get_type will never return key/motion
<bschaefer> racarr, cool just wanted to double check :) (want to include as much as i can in switch statements)
<bschaefer> more for a TODO section wise
<bschaefer> cool
<racarr> Coooolio
<bschaefer> thanks!
#ubuntu-mir 2015-05-28
<duflu> RAOF: Is there an important reason why Wily isos are not yet promoted (passing automated testing) that you know of?
<RAOF> duflu: Not to my knowledge.
<duflu> I mean http://cdimages.ubuntu.com/daily-live/current/
<duflu> Possibly some test(s) failing that humans don't care about too much
<duflu> (most)
<RAOF> Oh. I'm *using* wily on this laptop, and haven't noticed breakage.
<RAOF> If your question is âshould I sudo sed -i s/vivid/wily/g /etc/apt/sources.listâ
<duflu> RAOF: Yeah I have one wily system set up. Just wondering when is the right time to migrate my development machine
<RAOF> A couple of weeks ago :)
<duflu> RAOF: I would have thought when distro declares it "passing" :)
 * duflu always installs fresh
 * RAOF doesn't actually know what gates iso promotion.
 * duflu assumes it's test automation
<RAOF> Yeah, but what tests.
<duflu> Dunno. I would say I don't care but similarly if Mir was failing tests it would appear to work but still not be recommended for use
<duflu> (often appear to work)
<duflu> Time to put a faster drive in the build machine...
<bschaefer> racarr, hey, w/e you see this tomorrow ... mir_pointer_event_buttons isn't defined in the new library? (but its in trunk?)
<bschaefer> how would one get the mir pointer state with out this?
<anpok_> with mir_pointer_event_button_state instead
<anpok_> bschaefer: sometime after the 0.13 branch racarr reworked the button state enum another time and added the '_buttons' accessor, before that you could only query for buttons individually.
<dednick> cimi: have you had any time to look at https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1396058-multi-line-messages/+merge/257050 yet?
<dednick> greyback__: getting an dpkg error installing qtmir. missing libgsettings-qt-dev
<dednick> greyback__: not in build-dep
<dednick> which is kinda weird, since i thought dpkg uses the control file, and so does build-dep?
<greyback__> dednick: I see it in the debian control file
<greyback__> yeah, it does
<greyback__> you're *installing* qtmir, and it relies on this -dev package?
<greyback__> doesn't sounds right to me
<dednick> greyback__: oh, no. using dpkg-buildpackage
<greyback__> ah compiling
<dednick> ya
<dednick> hm. i probably have something different in apt sources vs my source
<greyback__> might be difference between build-dep in vivid & vivid+overlay
<greyback__> as I think that gsettings requirement is in overlay only atm
<dednick> i may not have updated my source repo since i added overlay.
<dednick> nvm
<dednick> i think that's it
<greyback__> would make sense
<alan_g> greyback__: what can I try to test qtubuntu update?
<dednick> alan_g: that the mir surface close event?
<alan_g> dednick: rebuilt to match Mir-0.13.x API/ABI changes
<dednick> alan_g: oh right. nevermind.
<alan_g> dednick: do you know what it can affect
<dednick> alan_g: afraid not.
<dednick> alan_g: i presume you're talking about your ~mir-team/qtubuntu/track-mir-deprecations branch. Which just looks confirming the touch and keyboard input still work. But as to it introducing specific problems i have no idea.
<alan_g> dednick: yeah, I'm working on the assumption that any breakage would be very obvious.
<alan_g> But if there were something specific to look for...
<greyback__> alan_g: sorry, was afk. As input code was changed, I'd make sure to test multi-touch things, so 2 finger zoom gestures in camera & gallery would be a start. I'd do some finger mashing to make sure qt doesn't crash for any reason. And would test unity8 on desktop to ensure keyboard presses work
 * alan_g can't remember the last time he had U8 working on desktop
<alan_g> greyback__: thanks, I can try that
<alan_g> Rats! the thing rebooted
 * alan_g decides testing on manta was a bad idea
<alan_g> mako seems stable
<alan_g> alf_: glad you didn't disappear in the floods
<alf_> alan_g: it seems that I brought the floods back home with me :)
<alan_g> I like it "The fundamental theorem of agile software development: if you think you canât split a development task, you probably didnât try hard enough." @PeterHilton
<alan_g> alf_: could you check the test I had to hack (rationale should be clear from MP comments) https://code.launchpad.net/~alan-griffiths/unity-system-compositor/spinner-rework/+merge/260148
<alf_> alan_g: sure
<bschaefer> racarr, hey, so  mir_pointer_event_buttons seems to be undefined? Not sure how to get the MirPointerButton from a PointerEvent then :(
<bschaefer> i see it defined in lp:mir but not in /usr/include
<anpok> bschaefer: still there?
<anpok> you have to use mir_pointer_event_button_state instead
<bschaefer> anpok, thats a strange function, soo i've to manually check each state?
<bschaefer> anpok, thanks! I missed it since i was looking for a function that returned a MirPointerButton :)
<anpok> yes you have to for now
<anpok> and thats why racarr changed it then
<bschaefer> cool, thanks again!
<taiebot> Hi guys just a heads up on the sdl games that have landed on the store https://uappexplorer.com/app/neverball.lb https://uappexplorer.com/app/neverputt.lb? while they work correctly on vivid on willy mako its not the same  http://uppix.com/f-screenshot20150555676d30001907f7.png taiebot (a tester)
<racarr> that screenshot is pretty cool
<racarr> lol
<racarr> are phone applications supposed to be allowed to be transparent...
<racarr> that seems like a mistake -.-
<taiebot> racarr:looks like a mir bug the app is a quarter of the screen with the top side having two time the app displayed
<taiebot> while the input  are located in the right places if you manage to imagine where the input would be if the app was correctly displayed
<taiebot> http://uppix.com/f-screenshot20150555676ea2001907fa.png
<bschaefer> fun error im getting now :(
<bschaefer> http://paste.ubuntu.com/11418145/
<bschaefer> the code thats uses it: http://paste.ubuntu.com/11418169/
<bschaefer>  hmm looks like region im getting from the surface is invalid hmm
<bschaefer> soo surface is getting created correctly (with software usage)
<bschaefer> as this looks like the error i was having when i tried to get a region using a hardware surace
<bschaefer> surface*
<AlbertA> bschaefer: yeah with mesa you won't be able to map it in the client...
<AlbertA> works in android though :)
<bschaefer> AlbertA, hmm but this should still work on the desktop? As demo multi win still works
<bschaefer> which does the same thing :)
<bschaefer> (software rendering)
<bschaefer> I just find it strange that the region returned from the stream buffer is undefined ie. invalid pixel format and garage width/height
<bschaefer> though my surface is valid
<AlbertA> bschaefer: yes it should work if you specifically request software buffers
<AlbertA> otherwise it's a bug...
<AlbertA> but with hardware buffers, you'll get the perm issue
<AlbertA> on mesa
<bschaefer> AlbertA, o geeez
<bschaefer> i think i know what i did :)
<bschaefer> i created the surface before setting the buffer :)
 * bschaefer slaps him self
<AlbertA> bschaefer: lol ok
<bschaefer> i had the software buffer being set but yeah just after the surface was created using the spec sooo it was using hardware
<AlbertA> I'm curious to see what this would spit out with the mir code base: http://karpathy.github.io/2015/05/21/rnn-effectiveness/
<AlbertA> this is what it spits out when trained with the linux kernel code base: http://cs.stanford.edu/people/karpathy/char-rnn/linux.txt
<racarr> AlbertA: lol...
<racarr> this sort of stuff drives me insane...
<racarr> "What does it mean? What does it mean? What does it...AHHHHHHHHHHHHHHHHH"
<AlbertA> racarr: it even has helpful comments along the way :)
#ubuntu-mir 2015-05-29
<dandrader> Is mir packaging borked or is my system messed up? -> http://paste.ubuntu.com/11431212/
<dandrader> In /usr/lib/x86_64-linux-gnu/mir I've only a client-platform subdir
<anpok_> something is borked
<anpok_> so you do not have mir-graphics-drivers-desktop installed?
<dandrader> anpok_, no
<anpok_> hm no I think thats ok.. the package that adds mir_demo_server / mir_proving_server requires neither the android driver nor the desktop/mesa drivers..
<dandrader> I tried to remove all mir pacakges from my system, but for some reason it would bring along a whole lot of other packages such as xchat, update-manager, totem, etc :/
<dandrader> I fail to see the connection between them
<seb128> dandrader, likely because libgtk has a mir backend so link to libmirclient
<seb128> trying to remove the lib removes gtk
<seb128> which takes the gtk rdepends with it
<dandrader> seb128, sounds right
<seb128> dandrader, why do you need to uninstall libmir? it doesn't force you to have the mir server installed
<seb128> it's just a small lib
<seb128> like you have libwayland and others installed for the same reason
<dandrader> seb128, just to get back to a clean slate and start over. I don't really need to remove it
<seb128> k, I guess keep the lib then
<dandrader> yeah
<seb128> or install --reinstall /vivid|wily
<dandrader> just found it curious that the system already relies on mir packages, even though it doesn't use them
<kdub> alf_, any more thoughts on: https://code.launchpad.net/~kdub/mir/surface-buffer-access/+merge/259049 ?
<alf_> kdub: let me remember what was going on there...
<kdub> alf_, basically, I just want to break ms::Surface : ms::SurfaceBufferAccess, because the streams provide the buffers
<alf_> kdub: so, I guess I am ok with getting rid of the narrower interface at this point, and hopefully we can remove the with_most_recent_buffer() function in the future, when snapshotting is not needed anymore
<kdub> alf_, I think it can even move to the private compositor::BufferStream inferface before the snapshotting is removed
<kdub> once we root out the concept of the default_surface from the session
<anpok_> regarding daniels complaints.. have we discussed using buffer streams as-is for decoration purposes?
<anpok_> but I also do not see any problems to add that later
<kdub> anpok_, in the context of ~kdub/mir/surface-buffer-access? or somewhere else
<anpok_> i was refering to yesterdays stuff.. um add-streams-to-surface
<kdub> ah, so I think we're coming around on that one in general
<kdub> but we have discussed it as a future possibility
<anpok_> ok
<kdub> alf_, I think I'll collapse it then, seems everyone who has weighed in would be okay with that, thanks for the look
<alf_> kdub: np
<kgunn> vogons so for those keeping score on the qtubuntu/libmircommon snafu....silo 19 passed testing, but they just locked vivid
<kgunn> again... :-/
<kdub> :\
<kgunn> so it'll land in wily and then robru said he'd create another silo to stick the pkgs for vivid
<kgunn> already passed qa as well...so should just be ok
<kgunn> just a little outta sync
<bschaefer> racarr, running into an interesting issue. I cant seem to hold a key down with the new mir stuff?
<bschaefer> ie. if i press and hold LEFT arrow, then press RIGHT UP DOWN, then release LEFT
<bschaefer> all i get is LEFT down/up RIGHT down/up UP down/up DOWN down/up
<bschaefer> same if i hold a, or b... it gets the release as soon as i press a new key
<bschaefer> (or it possibly gets the release as soon as a press a key down)
<bschaefer> racarr, the code that handles key events: http://paste.ubuntu.com/11438311/
 * bschaefer gets a timestamp of the events
<racarr> bschaefer: processing
<bschaefer> racarr, its a  bit strange... i dont see a mir demo that really has key events
<bschaefer> like moving an object around per say
<racarr> MIR_CLIENT_INPUT_RECEIVER_REPORT=log or mir_demo_standalone_input_filter
<racarr> uh
<bschaefer> o that works as well
<bschaefer> racarr, where does it log to?
<bschaefer> stdout?
<racarr> stdout yeah
<bschaefer> ok
 * bschaefer looks up code for LEFT/RIGHT
<bschaefer> racarr, mir looks like its doing it right hmm
<bschaefer> racarr, http://paste.ubuntu.com/11438557/
<bschaefer> holding a down while pressing b c d
<racarr> bschaefer: I bet I know whats happening
<racarr> action == mir_keyboard_action_repeat ;)
<racarr> and you arne't handling it
<racarr> so key_state is left as
<racarr> 0
<racarr> which must be
<racarr> SDL_RELEASED
<bschaefer> ooo
<bschaefer> racarr, i didnt have to handle this before :)
<racarr> Tricky :(
<bschaefer> hmm
<racarr> Yeah...
<racarr> well there was
<racarr> repeat_count before
<racarr> you should use switch
<bschaefer> right, which i could ignore
<racarr> for things like this
<racarr> so the compiler will warn you
<bschaefer> i should beable to just skip these events
<bschaefer> IIRC
<racarr> but
<bschaefer> maybe...
<racarr> lol
<racarr> yeah this seems a little like a trap
<racarr> (on our end)
<bschaefer> as i think the client handles the repeat
<bschaefer> ie. KEY IS DOWN KEEP MOVING
<racarr> That's always an option yeah
<bschaefer> and it waits for a release...but i should keep the count...
<bschaefer> maybe... idk if sdl1.2 handles that
 * bschaefer looks had headers
<bschaefer> racarr, yeah sdl1.2 doesnt even have a repeat option for the key event
<bschaefer> racarr, thanks for pointing that out!
<racarr> bschaefer: np :)
<racarr> Happy friday :D
<bschaefer> racarr, ill have to poke you about sdl2 :)
<bschaefer> racarr, and happy friday to you as well
<bschaefer> for sdl2...i might have to keep track of the repeat count...
<bschaefer> or rather...maybe it just asks if its repeating
 * bschaefer will have to worry about that another time
<racarr> Mm. yeah thats what most people seem to do (just bool is_repeat)
<bschaefer> yeah ill have to double check that ... if thats the case that would be sooo much easier
 * bschaefer assumes it is for now
<bschaefer> confirmed fix my issue :), thanks again!
<racarr> Yay :D
 * bschaefer needs to stop playing etracer
<racarr> bschaefer: you mean "testing SDL"
<bschaefer> racarr, yes :)
<bschaefer> hello soo unity8 desktop seems to be crashing in -proposed:
<bschaefer> http://paste.ubuntu.com/11439219/
<anpok> bschaefer: hm i think you should have a graphics-mesa.so.2 instead
<bschaefer> anpok, i see, installing now :)
<bschaefer> it didnt remove so.1 soo hopefully it doesn't pick thatone
 * bschaefer relogs
<bschaefer> anpok, sweet thanks! Now it works
<anpok> still curious why this is not picked by defaut
<bschaefer> yeah that is an interesting point, as i've done many update/upgrades
<bschaefer> since adding -proposed
<bschaefer> racarr, sooo now another fun question... holding a key down works on a server i run my self
<bschaefer> but if i run etracer on unity8 desktop hold right/left
<bschaefer> does not work
<bschaefer> err it works if i make my own server, but does not work when running through untiy8... idk if theres any differences between the layers there though...which i strange
 * bschaefer adds a log
<bschaefer> racarr, this time it does look like mirs fault
<bschaefer> instead of sending repeat, its sending up
<bschaefer> http://paste.ubuntu.com/11441144/
<bschaefer> racarr, maybe...im some how running the wrong version of the lib? (i was somehow running the wrong platform graphics lib...)
<bschaefer> also the server im running my self is built from trunk mir
<bschaefer> on the plus side etracer on unity8 desktop: http://i.imgur.com/TVS8bSr.jpg
<bschaefer> (ignore bad phome camera)
<anpok> bschaefer: and when you take an installed mir server?
<bschaefer> anpok, if i use the one from mir_demos
<bschaefer> it works fine
<bschaefer> which should use the same libraries that unity8 desktop uses
<anpok> hm for unity8 events get fed into qt and dispatched through the scene
<anpok> and then converted back and sent to clients
<bschaefer> anpok, i bet qt isn't handling the new repeat then
<bschaefer> action
<bschaefer> anpok, what package would that be in?
<bschaefer> qtmir?
#ubuntu-mir 2015-05-30
<anpok> yes
<bschaefer> anpok, cool thanks
<bschaefer> ill take a look
<bschaefer> anpok_, yup its qtmir from the looks of it
<bschaefer> anpok_, http://paste.ubuntu.com/11442086/
<bschaefer> src/platforms/mirserver/qteventfeeder.cpp:317
<bschaefer> racarr, ^
<bschaefer> though thats more of a qt/mir thing soo greyback
<bschaefer> ill poke him monday
<bschaefer> though i missread...it returns pressed...not release
#ubuntu-mir 2016-05-31
<alan_g> greyback: you have more idea than I how QtMir hangs together: Any idea why I suddenly need -r 490 in https://code.launchpad.net/~alan-griffiths/qtmir/MirServer-is-an-implementation-detail/+merge/293992 (see earlier comments for background)
<greyback> alan_g: first time I've seen such a thing
<greyback> how bizarre
<alan_g> /sigh I was hoping for "that's because Qt frombulates the link-loader"
<alan_g> I'm not even sure which module to blame. Just that it can be frigged in the one I touched.
<alan_g> greyback: BTW I just landed some WM improvements on MirAL (moving logic out of WMPolicy into BasicWM)
<greyback> alan_g|EOD: noted. Yeah Qt isn't doing anything fancy to the linker
#ubuntu-mir 2016-06-01
<natosha> bschaefer, I am trying to get the X11 Mir platform up and running, I keep getting http://pastebin.com/raw/ak2asHBf Does it seem familiar?
<natosha> The error of course also occurs when trying to set up the TTY KMS Mir platform.
<natosha> (This is with a fresh install of 16.04 with latest updates.)
<natosha> Oh, and using the intel open source driver.
<bschaefer> o good intel is needed!
 * bschaefer looks
<bschaefer> yeah it looks like a dependency didnt get pulled in
 * bschaefer checks which ones you need
<bschaefer> mir-platform-graphics-mesa-x9 mir-platform-input-evdev5 mir-client-platform-mesa5
<bschaefer> natosha, try installing those packages ^
<bschaefer> theres an issue with us hard depending on different platforms depending on the device
<bschaefer> if you want the kms as well
<bschaefer> mir-platform-graphics-mesa-kms9
 * bschaefer updates doc
<bschaefer> o turns out: mir-graphics-drivers-desktop
<bschaefer> should install all the desktop platforms!
<natosha> bschaefer, Hmm, I only see mir-platform-graphics-mesa-x8 in apt
<natosha> However, that seems to work
<bschaefer> natosha, yeah i have a newer one... but mir-graphics-drivers-desktop should get all you need
 * bschaefer has a totally messed up system with to many ppas :)
<natosha> Hmm, Ok, so I have Mir running, and when I run the demo client, it shows some red wavy background in the Mir server window. (Success?)
<bschaefer> natosha, yay yup
<bschaefer> thats the client running on the mir server
<bschaefer> (q to quit)
<natosha> Ok, cool.
<natosha> When I try to run the Unity/SDL2 test app, I don't get anything showing up, so need to figure out how exactly to debug, but at least we have something to start with now.
<bschaefer> right, soo for that depending on the issue stdout/stderr is the main help
<bschaefer> SDL_VIDEODRIVER=mir is required for X11 platform
<natosha> Yeah, have that.
<bschaefer> any output such as "Unable to find xxx platform?"
<bschaefer> err mir platform?
<bschaefer> or is it running as expected but no image?
<natosha> (Got tricked by that when working on Wayland support; totally thought it was working long before it was *actually* working due to that darn, all-too-helpful fall-back-to-X behavior.)
<bschaefer> :)
<bschaefer> yeah
<bschaefer> natosha, i suppose a simpler test would be to install 7kaa (it'll crash when it closes on the SDL2 mir platform)
<bschaefer> and attempt to run that game on the server to show SDL2 is working on mir
<natosha> Nah, the Unity logs indicate that it's not able to correctly create a gfx context.  Seems like our problem.
<bschaefer> yeah, though if it works for wayland it *should* work for mir
<natosha> Though I guess I could also try with the TTY Mir setup as well, just to be sure.
<bschaefer> yeah not a bad idea
<natosha> Yes, this player works on Wayland, though I'm going to install another native instance using Wayland so I can compare behavior on the same hardware.
<bschaefer> as they both use the SDL_egl backend
<natosha> The computer I was using before for testing was using Wayland with the nouveau driver; this one is using the Intel driver, so that could be it as well (though it works fine in normal X11 mode).
<bschaefer> natosha, hmm just to be on the safe side would be nice to get a different SDL app up and running to confrim
<bschaefer> SDL2 issue or unitys
<bschaefer> the version of SDL2 is 2.0.4 right?
<natosha> Unity statically links SDL2
<natosha> It's currently using what was latest upstream a couple weeks ago, which was newer than 2.04
<natosha> *2.0.4
<bschaefer> o thats even better
<natosha> In fact, there was some problem with 2.0.4 specifically that I couldn't use the official release
<natosha> bschaefer, So trying to set up the TTY Mir session gives http://pastebin.com/raw/tMUM63LC
<bschaefer> right you'll need the kms platform hmm
<bschaefer> which you said you couldnt find?
<bschaefer> did installing: mir-graphics-drivers-desktop
<bschaefer> work? Im not sure if thats a new package
<natosha> Oh, missed that.
 * bschaefer finds the platform packaging a mess but there doesnt seem to be a good solution :(
<natosha> The TTY Mir sessoin starts successfully.  And I get the same behavior there.
<bschaefer> natosha, also here is a simple SDL application: http://paste.ubuntu.com/16906817/
<bschaefer> that you can attempt to test on TTY/X11
<bschaefer> to check the SDL2 vs unity issue
<bschaefer> LD_LIBRARY_PATH=/path/to/your/sdl2/ when compiling
<bschaefer> should just be a bright green screen
<bschaefer> the other thing to check... is possibly the SDL2 doesnt have mir built in with it (not sure the when it was built or if you have the required libraries to build SDL2 for Mir support)
 * bschaefer writes down what you'll need to compile SDL2 with Mir support
<natosha> The sample SDL program works, it seems.
<natosha> The SDL library Unity links should have Mir and Wayland support both enabled . . . . I think.
<natosha> In any case, it seems we have a reasonable test setup now.  Will just need to debug.
<natosha> Thanks. :-)
<bschaefer> yup!
<natosha> I'll be back if we have further issues with it.
<bschaefer> natosha, np! I enjoy debugging so if you've any questions just poke me!
 * bschaefer still around for ~3 or so hours
<natosha> It's past midnight, so I'm going to bed :-) But I'll probably get to debugging this in the next few days.
<bschaefer> o dang yeah, have a good night!
#ubuntu-mir 2016-06-02
<alan_g> greyback: I've merged your code dump. Feel like reviewing my latest shuffling around of the WM logic?
 * alan_g still has to get around to setting up CI for lp:miral
<greyback> alan_g: sure
<alan_g> kdub: a while back you had trouble running gnome-terminal under Mir. A thought just occurred to me - were you running it as root? (I might have asked this before)
<kdub> alan_g, probably, i usually do under mesa so that ctrl-c gets sent properly
<kdub> although, I have a hazy memory of trying --arw-file and still having an issue
<alan_g> I just accidentally did that and it doesn't run. (Is fine with the usual "--arw-file --file $XDG_RUNTIME_DIR/mir_socket" for the server and running as non-root.)
#ubuntu-mir 2016-06-03
<alan_g> greyback: I'm hoping that this will make it much easier for you to reuse miral's window management: https://code.launchpad.net/~alan-griffiths/miral/move-WM-logic-into-BasicWindowManager/+merge/296439
<greyback> alan_g: yes that will. I've been working on integrating BasicWindowManager into qtmir
<alan_g> greyback: how's that going? Can I help?
<greyback> alan_g: we'll chat next week
<alan_g> greyback: sure. A good context for some pair programming.
<greyback> alan_g: yep. I'm playing around as much as I can
<greyback> so I'll have a good idea what I need
#ubuntu-mir 2017-05-31
<duflu> alan_g: In case you didn't notice, I rejigged Mir to show 0.27 is the focus of development again.
<duflu> And corresponding changelogs proposed
<duflu> Oh, you did notice one of them
<alan_g> duflu: I saw the MP, not looked further yet. Thanks for that.
<duflu> alan_g: I'm not sure what value there is having any bugs assigned to future milestone 0.28.0 though
<duflu> And 0.27 would be wrong. Maybe remove the whole 0.28 series
<alan_g> duflu: we're /probably/ doing 1.0 right after 0.27
<duflu> Because 0.28.0 shows up as assignable in bugs, which is confusing
<alan_g> Yes, dropping the 0.28 series makes sense
<alan_g> We can always resurrect it
<duflu> Done. https://launchpad.net/mir/+series
