[00:28] http://www.reddit.com/r/LinuxActionShow/comments/1alqka/regarding_matt_and_the_monkey_suit_its_on_like/ [00:29] probably best to not let this guy down ^ [00:29] :-) [00:41] Used by default in a non-Ubuntu distro is a ballsy call. [01:32] Has anyone compiled qmir before? [01:32] qmake ; make doesn't seem to do it for me [02:09] RAOF: oh cool, you got buffer age working [02:10] smspillaz: Yeah. Next up: actually using it in XMir. [02:10] Actually, before that is probably ‘extend __DRIbuffer to allow me to pass prime fds to dri drivers, damnit’ [02:11] RAOF: I wonder how you got it to work - the DRI drivers don't really make any guaruntees about what buffer you're going to get next [02:11] its all very driver specific [02:11] some drivers with copy-back-to-front on swap, others will swap, others triple buffer [02:12] though I guess that all happens within the xserver bits [02:12] *Mir* knows exactly what buffer it's going to send to the client. [02:12] yeah I figured as much [02:12] Right. Each buffer the client receives has a (client-)unique id; it's reasonably easy to implement age tracking on that ;) [02:12] RAOF: how do you handle the discrepancies between the drivers though ? [02:13] Which discrepancies between drivers? We exclusively pageflip, and handle n-buffering ourselves. [02:14] We don't use any of the X bits; we're not using the DRI2 protocol. [02:15] Nothing ever gets a SwapBuffers request, except egl/platform_mir, which we own. [02:15] RAOF: remind me - do the Xorg bits of dri2 have driver-specific things there ? [02:16] I looked into doing this in X a while ago and remembered there was some driver-specific stuff that would have made it difficult, but it was a while ago [02:16] Yes - the X bit of SwapBuffers calls into the DDXes SwapBuffers function. [02:16] ah okay that makes sense [02:17] I think for X you would indeed need to push this all the way down to the DDX, or _possibly_ hook into the bits generating intel swap events. [02:17] RAOF: it was a total PITA [02:18] This is not an uncommon sentiment when working with X :) [02:18] yeah it was this stuff here http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/intel_dri.c#n838 [02:19] I tried to factor a bunch of that stuff out into the X server at one point. [02:19] Because all 3 of the drivers were doing the _exact_ same thing, and they had exactly the same segfault bug. [02:20] heh [02:20] I think nouveau works a little differently [02:20] intel has the optional triple-buffer thing [02:20] nouveau didn't [02:20] I remember that much [02:21] Yeah. At one point -ati and -nouveau had just copy&pasted the -intel code and run a sed over the names; it's diverged a bit from there :) [02:21] felt like it [02:21] Also I830 [02:21] heh [02:21] Party like its 2002 [02:21] smspillaz: ! [02:21] racarr: hi' [02:21] RAOF: Just left some comments on buffer age... [02:22] no I'm not writing any code for you :p [02:22] Hi :) [02:22] thats what you say now [02:22] seriously, I'm not [02:22] :) [02:22] I know :) [02:24] also, you guys need to fix the privacy settings [02:24] I can't see half the merge proposals [02:30] wip [02:30] racarr: no, as in I click on them and I get a page that says "go away" [02:31] example: https://code.launchpad.net/~robertcarr/mir/prepare-for-inprocess-egl-clients/+merge/153889 [02:31] (you'll need to log out) [02:31] I _think_ it might be the merges or the branches that were set up prior to going public? [02:31] It's not clear how to make them public. [02:32] RAOF: I think the lp settings are that projects are private or public, not branches [02:32] so something is broken somewhere [02:32] Incorrect! lp:~raof/mir/client-side-buffer-age was a private branch. [02:33] And now that it's a public branch the merge proposal is also public. [02:33] Ok. [02:33] RAOF: I don't see the MP [02:33] its not public :)P [02:33] https://code.launchpad.net/~raof/mir/client-side-buffer-age/+merge/151869 [02:33] ? [02:33] RAOF: so I can see if if you give me the link [02:34] but it doesn't turn up in +merges or +activereviews [02:35] That might take a little while to propagate? [02:35] should be instant [02:37] I think it will be fixed once we get all the mps through [02:41] yeah [02:42] racarr: Thanks for the review. [02:47] RAOF: Sorry its kind of scattered [02:47] That's ok. [02:47] I am really tired...have been a little too full stream all around last 3-4 days :) [02:47] I thought I would try and say something though [02:47] and overall it makes sense :) [02:49] What do you think of pulling the age() related bits into ClientBuffer; the implementation shouldn't be different between AndroidClientBuffer and GBMClientBuffer. [02:51] I'm leary of mixing interface and implementation there. [03:02] Woo! Android build builds! [03:05] does having an Android build mean Mir has been tainted with Java? [03:05] tehcloud: No [03:06] tehcloud: Java is only used for apps on android, I believe all the infrastructure stuff is C/++. [03:06] C/C++ even. [03:13] And we're not even using that; we're using the android kernel and GLES drivers. [03:23] I know that, just clarrifying that java is only used at the app/UI level. [03:23] Yeah, I presume you did, but tehcloud probably didn't :) [03:24] yeah, I'm not exactly an expert in this subject matter [03:24] TheMuso: brb, off invention "++" [03:24] its C++ with the C bits removed [03:24] oh wait that's Java, never mind [03:25] *inventing [03:25] lol [03:25] They should have called Java "++" [03:25] that would have ended up in so much hilarious confusion [03:26] in an ideal world there would be no Java [03:26] Java has its place, just like all languages. [03:26] I don't use it myself. [03:26] But can understand, accept and respect its usefulness. [03:26] that's why you think that way ;) [03:26] try using it at work [03:27] Java would be useful if we didn't have AWT [03:33] Man, the ubuntu touch images don't even have rsync in them! [03:37] RAOF: "tsyncninja" A touch based file synchronization utility based on the popular fruit slicing mini game [03:38] Hm. “make style_check” isn't really very useful, is it ☺ [03:38] ~/Canonical/Mir/mir/build ⮀ make style_check 2>&1 | wc -l [03:38] 1031 [03:38] RAOF: I always grep for the files I modified [03:39] and just fix those [03:39] "always"->"on good days" [03:51] RAOF: I kind of like pulling the age related bits in...(just catching backscroll) [03:51] the mixing implementation and interface is a red flag though [03:51] the other red flag is the [03:51] implementation of the ageing semantics on the mock buffer with the expectations [03:51] in one of the tests [03:51] Yeah, that's rather awkward. [03:51] which says that really there is [03:51] another object [03:52] BufferAgeTracker (complete strawman name) [03:52] and its an integration test [03:52] but...eh [03:52] I am not sure how strongly I feel about it [03:52] racarr: Orange flag at most. If there's no real testing value gained by mocking systems code then I think it's often OK to mix implementation with interface [03:53] Sure, orange flag :) [03:53] Maybe Buffer has a member [03:54] type BufferAge [03:54] ClientBuffer could well have a public uint32_t age, yes. [03:54] On the other hand... being able to test code natively is preferable to mocking. And if you can do that, then you don't need to separate interface from implementation [03:54] RAOF: No I mean a [03:54] BufferAge age, and then the methods increment_age, mark_as_submitted, age() [03:54] etc [03:54] move to BufferAge definition [03:54] and out of the platform code [03:55] Possibly. I *think* the Buffer might actually want to do something on mark_as_submitted(), though. [03:55] duflu: Here the interface is seperated because it actually has multiple implementations [03:56] * duflu stops generalizing about code he hasn't seen yet [03:56] RAOF: does it have to do with the age [03:56] duflu: Hehe. my number 1 hobby! [03:56] racarr: No, not to do with age. [03:56] RAOF: Then I would imagine [03:56] Generally speaking... we should use Go. [03:56] buffer.submit() does that thing and [03:56] also calls buffer_age.mark_as_submitted() [03:57] racarr: The *age* interface doesn't actually have multiple implementations, though. [03:58] RAOF: In what tense? Right now it does i.e. increment_age is implemented in the test, the android buffer and the gbm buffer [03:58] so the idea is to just move the implementation to a single shared BufferAge type [03:58] racarr: In the sense that it's ever sensible to have different behaviour there. [03:58] mm [03:58] so I mean it's a concrete type [03:58] its just to avoid mixing implementation in to the ClientBuffer API [03:59] I guess there is still some :) [03:59] Alternatively, ClientBuffer abstract, AgeableBuffer concrete, {GBM,Android}ClientBuffer inherits from both? [04:00] RAOF: Mm [04:01] RAOF: Anyway...I don't feel strongly enough about any of these to feel like [04:01] blocking on it...but maybe if you think one is a particularly good idea or europe has a good idea :) [06:08] Hm, it seems that our coding style has a significant exception in the tests. [06:17] * duflu would prefer to call it a coding /fashion/ [06:19] Coding /ambiance/ [06:32] uRAOping [06:32] RAOF, ping [06:32] Yo! [06:36] tvoss: What's up? [06:37] RAOF, good morning :) looking at your buffer age branch, did you run it with XMir, yet? [06:37] tvoss: No, haven't yet done the xmir bit. [06:37] RAOF, ah, was just curious. I remember you mentioning that the buffer age stuff might help [06:38] XMir is currently in a bit of flux, too; it's half way through being adjusted to lp:~raof/mir/use-dma-buf [06:41] RAOF, ah cool :) [06:41] * tvoss is going to review racarr's branch now [06:45] It should help with XMir performance though, yeah. [06:45] * RAOF has performance-parity third on his TODO list, under finish-buffer-age and use-dma-buf [06:45] That's going to be _all manner of fun_ [06:48] RAOF, \o/ === alan_g is now known as alan_g|afk [08:55] Hurray... mir just overflowed it's first page of bugs in Launchpad (75 per page) :/ [08:55] *its [08:57] A fair number of those are "fix committed", though. [08:58] Yeah, first comment still holds. But I wonder when the "0.0.2" release should be tagged and we move on to more meaningful milestone numbers... [08:59] Oh great. 0.0.2 is already marked as released, but also still active [08:59] That needs fixing [09:00] tvoss: What should our next milestone be? 0.0.3? 0.1.0? [09:01] Assuming 0.0.3. We can change it later... [09:02] Are those milestones at all meaningful? [09:03] RAOF: No. I just realized.... [09:04] RAOF: We need to fix up our branch-to-series relationships before milestones make sense [09:04] I'll bug Robert about it when he's online tomorrow [09:09] duflu, yeah, talk to Robert or kgunn please [09:09] tvoss: Writing detailed email... [09:10] duflu, thank you === alan_g|afk is now known as alan_g [09:14] Good morning. (It is snowing!) [09:16] alan_g: Morning. Not sure whether to be jealous. [09:17] duflu: don't be - it'll just make everything wet and cold [09:19] duflu: we need to reach consensus about include (directory) names as Europe and Australia seem to think differently. Have you seen the thread on mir-devel? [09:19] alan_g: Keep forgetting to subscribe to that. Too many other mediums of Mir discussion. Will do so now [09:21] duflu: A choice of mediums isn't bad. [09:22] Well, only if one is more effective than another and it's not being used [09:26] alan_g: I'd be interested to hear your thoughts on the great "where to put buffer aging implementation"fest of '13 racarr & I had in backscroll, too. [09:27] * alan_g wonders where to find it [09:30] alan_g: Ah, you don't have backscroll? Let me pastebin [09:32] alan_g: http://paste2.org/p/3228842 [09:32] RAOF: Looking... [09:36] alan_g: As part of "breaking the dependency on Android input", doesn't that mean that desktop builds should not enter any *android* directories? [09:36] RAOF: ...need to remind myself what the code looks like... [09:36] "[alan-griffiths] Input refactoring (don't depend on Android): DONE" [09:38] duflu: It was porting the input stack to use std/boost instead of android equivalents. [09:38] alan_g: But still desktop builds enter a couple of *android* dirs? [09:38] duflu: yes [09:39] That's a bit confusing. [09:39] Hmm [09:41] duflu: we've adopted more android code than just the input stack [09:42] alan_g: Even the android input stack still seems to be required for desktop input. Is that right? [09:42] duflu: we've forked the android input stack for use on all platforms [09:43] duflu: and reduced its dependency on other android stuff to a bare minimum [09:43] Ah, OK. So there will be no escaping the 3rd party code generating all those errors/warnings that clang dislikes [09:44] duflu: not without work [09:44] Heh [09:48] * RAOF heads bedwards [10:36] * duflu heads kitchen-wards [10:57] katie, ping [10:57] tvoss pong [10:59] katie, hey, got anything to sync up? [11:00] tvoss, a couple of things, yes.. shall we jump on a hangout? [11:01] katie, sure, let me grab coffee :) === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik === yofel_ is now known as yofel [14:23] alf_: ping [14:36] alan_g: pong [14:36] alf_: do you want to do any more on render-surfaces-use-display-server or shall I set it to approved? [14:37] alan_g: I am ok for now, I prefer to do any additional enhancements in another MP [14:43] * alf_ prepares himself mentally for a review of lp:~robertcarr/mir/send-input-to-clients [14:48] * alan_g has just finished the mornings reviews. alf_, send-input-to-clients isn't the worst on the brain. [14:48] *morning's [14:49] alan_g: I haven't checked in detail, I just saw the +1066 diff :) === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [15:42] hey all, status, still up north at the gpu conference, will be back to a normal day tomorrow [15:47] kdub: hope you're having fun! [15:51] alan_g, thanks! picking up on some useful info, a lot of emphasis on gpu compute though [15:52] kdub: that doesn't surprise me. I know a lot of folks that believe that is what GPUs are for. [15:52] (That's what comes of working with investment banks.) === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g === mmrazik is now known as mmrazik|otp [16:07] Morning [16:10] status: changed render-surfaces to use DisplayServer, reviewing, investigating test failure in VM CI and VM autolanding. [16:21] alan_g: for comments on send-input-to-clients [16:22] are you thinking just [16:22] msh::Surface implements mi::InputTarget or some such [16:22] or something else... [16:22] I thought about that but then it escaped my mind XD [16:23] racarr: that sounds sensible [16:28] Ok :) [16:30] alan_g: racarr: @send-input-to-clients, in the same spirit as Alan's comment, I think that FocusSelector belongs in shell::, not in input:: [16:33] alf_: true [16:37] alf_: Yeah sounds right [16:40] alan_g: Lots of reinterpret_casts removed in r515 for prepare-for-inprocess-egl [16:40] racarr: excellent! [16:46] alan_g: alf_: Do you guys need review on anything this morning before I sink in to [16:46] send-input-to-clients [16:47] racarr: no - there were too many reviews for me to write any code [16:48] *whistles innocently* [16:49] kdub, ping [16:50] racarr: no pending MPs for me, thanks! [16:53] Next feature branch for me btw is, clients-receive-input. [16:53] which is going to look like. MirSurface, takes a MirEventDelegate containing bool handle_event(...,MirEvent,...) [16:54] constructs an InputReceiverThread from it. InputReceiverThread uses epoll to wake when there is data on the FD and uses the InputReceiver to consume [16:54] pending events and hand them out to the callback [16:54] if anyone has any [16:54] thoughts/alternatives/etc === mmrazik|otp is now known as mmrazik === kgunn is now known as kgunnAFK [17:37] alan_g: I am struck trying to decide on the name of the [17:37] interface msh::Surface exposes to the InputManager [17:37] there also has to be one for msh::Session [17:37] input::Surface is just more trouble XD [17:38] racarr: you had mi::InputTarget earlier. Changed your mind? [17:38] oh [17:38] alan_g: Well only because there are two [17:38] and SessionTarget reads weird [17:39] but really the session interface is not used as an input target (it doesn't have an FD) it's just for info [17:39] so mi::ApplicationInfo [17:39] mi::Target [17:39] set_input_focus_to(ApplicationInfo, target) [17:39] it feels redundant to write mi::InputTarget, etc. [17:40] Does "Application" belong there? Or is it a more general "Session"? [17:40] alan_g: It's hard to say [17:40] we create a [17:40] A little redundancy can help clarity [17:40] droidinput::InputApplicationHandle [17:40] from it [17:42] Yeah, but android input stack wasn't quite our use case [17:42] mm [17:42] I think its probably closer to a session [17:43] racarr: we can rename things in the input stack to bring it into line [17:43] set_input_focus_to(mi::SessionTarget, mi::SurfaceTarget)? [17:43] mm [17:43] racarr: but lets do that later [17:43] yes aybe a good task for next week if we can land the basics of input this week [17:43] then clean up, (espescially down in droidinput) [17:43] next week once it is under end to end test [17:44] and ITERATE! [17:45] alan_g: Just realizing also...I guess msh::SingleVisibilityFocusMechanism needs to work in terms [17:45] racarr: yes, and we can lose MIR_INPUT_USE_ANDROID_TYPES after that too [17:46] of msh::Session [17:46] and not mf::Surface :) [17:46] so it can see the SessionTarget type [17:46] racarr: ack [17:49] ugh but there is no msh::Session anymore [17:50] just application session [17:50] which if you use that get back to the point where you cant mock session for the focus mechanism. [17:50] racarr: there is, it is in the src directory [17:50] racarr: sorry, you're right [17:50] alan_g: session not surface I got it [17:50] backwards too [17:51] racarr: we're missing more than one interface around this area [17:51] mm [17:52] trying to find a way to proceed for this branch without tearing apart shell again aha [17:53] I dont like using the ApplicationSession interface for the FocusMechanism set_focus_arg because then it becomes cumbersome to mock [17:54] (need constructor args, etc...its weird) [17:54] but also don't like defining [17:54] hmm [17:54] at first I didn't like it...msh::ApplicationSession implements msh::Session implements mf::Session [17:54] but maybe that's really how it is. [17:54] default_surface for example [17:54] is part of [17:55] msh::Session [17:55] but not mf::Session [17:56] racarr: yes, but that *ought* to be part of an interface, not just in an implementation === mmrazik is now known as mmrazik|otp [18:00] alan_g: Yes msh::Session is the interface [18:00] msh::ApplicationSession is the implementation [18:00] default_surface is introduced at msh::Session [18:01] racarr: I'm sure you'll sort it all out while I take my wife out for a meal. [18:01] ;) [18:05] alan_g: Have a good evening :) [18:05] ill sort it out [18:05] I have this suspiscion that (not for this branch) === alan_g is now known as alan_g|life [18:05] but maybe really mf::Surface and mf::Sessio don't exist [18:05] and SessionStore::create_session and create_surface_for [18:05] return [18:05] SessionIPCPackage and SurfaceIPCPackage [18:05] except then how do you advance the buffer ;) [18:06] for now msh::Session I believe === mmrazik|otp is now known as mmrazik [18:08] racarr: they exist, but they're not quite correct yet === mmrazik is now known as mmrazik|eod === mmrazik|eod is now known as mmrazik [19:05] This is a difficult refactoring [19:06] because... [19:06] hmm well if you introduce msh::Session inbetween mf::Session and ApplicationSession [19:07] the SessionManager wants to deal with things in terms of msh::Session (to say pass to the focus mechanism) [19:07] but has to take mf::Session as input and as output [19:32] mer... [19:33] feel stuck on a good solution. espescially one that doesn't double the diff size of this branch so breaking for lunch [19:33] thai should be coming any minute now... === kgunnAFK is now known as kgunn [20:20] if mf::SessionStore::open/close session used the same style as mf::Session open/close/get with ID. [20:20] then the internals (session container, focus mechanism including bridge to input) can work in terms of msh::Session (inherits mf::Session) which can implement [20:21] InputTarget... [20:21] the problem is app_container->remove_session/create_session has to take the same type (or a mapping must be maintained) as session_store open/close [20:26] nvm that is just weird. because the SessionMediator only accesses one instance of session [20:26] per instance [20:39] the only thing I can come up with, is [20:39] eeeeerrrr...no nvm [20:39] *facepalm* [21:16] hello??? [21:16] robert_ancell: i swear i thot you changed this...i'm going bp crazy https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone [21:16] can you make it mir-team drafter ^ [21:16] CodyS: hello [21:17] kdub, yeah, I'm sure I changed that too.. [21:17] ok thanks...i wasn't sure if i was lagging too bad... [21:17] robert_ancell: arrgggg....cached webpage [21:17] no, I just updated it then [21:17] nevermind (sheepishly) [21:18] oh [21:30] robert_ancell: got another one https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-inter-app-data-transfer [21:30] kgunn, done [22:09] racarr, for in-process-egl mp, i'm a bit hazy as to what eglNativeDisplayContainer is an interface to [22:10] also hooray for android build ci! [22:19] racarr, I'm reading alan_g|life's ML post about the use of mir_toolkit for server processes - when you use Qt in process does it need a special interface to compile against? i.e. an interface that is different to the server and the client interfaces [23:00] robert_ancell: I dont thinks o but some of the interfaces are shared between the server and client [23:00] I havent fully processed that ML discussion yet === kgunn is now known as kgunnAFK