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