[01:44] hey RAOF, not sure if you saw my mail earlier... will I be able to give xmir a spin tomorrow my time? [01:45] olli: Yeah, just processing email. [01:45] You should be able to, yes. [01:45] RAOF, great [01:45] no hurry, I will be afk for a while [01:45] You definitely will be able to with an xorg.conf change, maybe without (on Intel) [01:45] as long as it gets to me before you leave for the day [01:46] sounds good [01:46] as long as it's documented [01:46] cya RAOF and everybody else [01:47] olli: bye ... ? [01:48] Ah, my ISP decided they would start trying to diagnose connection problems at 9am. I'm out of whack now [01:55] RAOF: SwapbuffersWait=true gets ignored in the PPA's intel driver. It still stays off :( [01:55] Although if it was doing proper flipping then I would not be seeing tearing. Looks like it's blitting for buffer swapping... ?! [01:56] Maybe that assumption is wrong... [02:00] duflu: And, just to check, this is happening with a regular X session, not running under the system compositor? [02:00] AFK :P [02:10] Some days the whole world tries to contact you simultaneously... [02:11] RAOF: Yes regular X with no mir running [02:11] duflu: There'll be a new build of xf86-video-intel shortly; try that. [02:11] RAOF: Kay, thanks [04:59] Gargh. [05:00] Faster, laptop. [05:13] Aha. [05:13] Mesa! [05:20] ? === Stskeepz is now known as Stskeeps [05:46] duflu: Mesa is why everything is broken for me. === mmrazik is now known as mmrazik|afk [06:42] Woot! [06:42] And now we're back to where we started. [06:42] With a ridiculous orange hardware cursor on top of the XMir session :) [06:50] fatally orange [06:55] Umm, that's out of date. We switched to a black and white one some days ago [06:56] Which reminds me, I meant to propose a smaller one [06:56] RAOF, ping [06:57] tvoss: Pong [06:58] RAOF, good morning :) you happy with being the primary technical contact for Khronos? [06:59] Is that news I see? [06:59] tvoss: Yeah. I've sent that email off. [06:59] In this public forum? [06:59] duflu, yup, not a secret I guess :) [06:59] RAOF, cool [06:59] Khronos membership is public anyway, right? [07:00] RAOF, yup [07:00] Woo, we shall paint Khronos a "ridiculous orange" [07:00] duflu, :) [07:01] alf_, ping [07:01] tvoss: pong [07:02] alf_, good morning :) for the snapshot question: how difficult is it to do a texture to texture copy from a surface/buffer to a texture handle supplied by Unity/shell? [07:04] tvoss: texture handle created in the EGL context of the shell (inprocess client)? [07:05] alf_, yup [07:08] tvoss: We don't have access to textures from different (non-shared) contexts. An option we were considering yesterday was to add eglCreateImageKHR support for the mir EGL platform, so we could create egl images for the native buffer handles (from our surface buffers) in the inprocess client context. [07:08] tvoss: so we don't actually share EGL resources (because we can't) but share the underlying native buffer [07:09] alf_, can you give me a ballpark estimate of the work? [07:09] alf_, remind me why we can't share the eglcontext? [07:11] tvoss: however, there are complications here, since we can't just give native buffers to the shell without synchronization with our internal swapping [07:12] alf_, fair enough [07:12] tvoss: @sharing eglcontext, because egl objects are namespaced under the egldisplay they are created with [07:12] alf_, ack [07:12] Saviq, ping [07:14] tvoss: @estimation, testing etc 1.5 weeks, + couple of days for spike first to ensure what we are trying to do will actually work [07:14] tvoss: (e.g. a feasibility check) [07:15] alf_, okay, please keep looking at it for the time being. There are two use-cases here: (1.) The shell needs to be able to transform an app's surfaces (moving, scaling, shearing), (2.) the shell needs to be able to acquire a snapshot of a surface right before an app is stopped/killed [07:16] Hmm, isn't a "snapshot" a much simpler case? We're going to need a non-GL interface for that to eventually support screenshotting too [07:17] tvoss: use case (1) should be done inside a compositing strategy (using the display server's EGL context), so no problem there in terms of sharing buffers. [07:17] Yeah. Is there any particular reason why the snapshots shouldn't be exposed as a blob of bytes? [07:18] tvoss: (2) What does it want to get back? Pixels, like now or a texture? [07:18] alf_, right now, we are using pixels that are uploaded to a texture (saviq, please correct me if I'm wrong) [07:19] Eventually we'll need pixels. But some shell features require more efficient textures... like a switcher [07:19] duflu, exactly, and turning a texture to pixels is always possible [07:19] Although it's interesting to point out that Compiz does the live-previews thing without any "snapshotting" [07:19] duflu, that's use-case (1.) though, where the app is running and the surface exists [07:20] duflu, we still need "previews"/"snapshots" of the last state for killed/stopped apps (implication of the lifecycle model) [07:20] The other option of course is that the surface still exists with the most-recent content. [07:20] Well, not just transform, but hook drawing functions and redraw a surface in multiple locations (like a workspace switcher) [07:21] duflu, agreed, that's what I call "transformation" *handwaving* [07:21] tvoss: for killed apps pixels are the only way forward, because otherwise we would need to keep buffers alive... [07:21] :) [07:21] alf_: Why can't we keep buffers alive? [07:21] Yeah you need "pixels" for killed/suspended apps. And also screenshot utils [07:21] duflu, alf_ okay, pixels sounds like a good idea then ... [07:22] Because it's unreasonable (I think) to say a screen shot util needs to be a GL app [07:22] duflu: Oh, certainly. But that's orthogonal. [07:22] Is there any particular reason to scrape the pixels out of the buffer, then keep a copy of those pixels, rather than just keeping the buffer around? [07:22] Yeah. Just wondering if we need both approaches or only one [07:23] alf_, for the snapshotting/synchronization: I would think that the shell interacts with a surface object for the snapshotting, too ... [07:23] RAOF: We do it already ;) ... https://bugs.launchpad.net/mir/+bug/1188451 [07:23] Launchpad bug 1188451 in Mir "Mir server leaks surfaces from dead clients" [High,Confirmed] [07:23] I don't think we'll be saving any appreciable amount of scarce resources by destroying the buffer but keeping the contents. [07:23] duflu: Heh. [07:23] duflu, mark it a feature then :) [07:24] Hmm, it's a feature when we /want/ to leak [07:25] RAOF: I was thinking that it may be too complicated, but I guess in the case we are destroying the surface on the compositor side, it's easy to reason about. [07:25] RAOF: However, giving out the buffer while the DS still owns it, is a world of sync hell. [07:26] Not destroying the surface for an app that's tombstoned would fix that, though. [07:26] Bonus marks if we can get the resurrected app to use the same surface, so it starts with valid content. [07:26] It's only in sync after it's tombstoned :) [07:26] Hence not useful for other screenshotting apps [07:27] duflu: No, I mean that if the surface still exists then the shell can just composite it as normal; it doesn't need a separate snapshotting process. [07:27] Hmm, Nexus4 is giving me stuttering. But only when I wasn't looking. Now I'm looking for the bug it's fine [07:28] RAOF, yeah, like removing all buffers except for the most current one from the surface [07:28] Ah there it is [07:28] *Having* a separate snapshotting process is useful for screenshot apps (however we want to do that), but that might not be the best way to give the shell what they need. [07:30] tvoss: RAOF: duflu: Saviq: Have time for a hangout? [07:30] I'll be bathing Zoë soon. [07:30] RAOF, will you be back after the bath? [07:31] alf_, in a couple of minutes, or later... [07:31] Just delegated bathing to Sam. [07:31] I may pop in and out once or twice, but I'm good to go. [07:31] * tvoss searches for the headset [07:32] good to go [07:32] Oh, and we don't have a thomi this week, do we? [07:33] RAOF, nope [07:33] tvoss: RAOF: duflu: https://plus.google.com/hangouts/_/d306e4af1fc3351c7a344cb62ef288f737707419?hl=en [07:35] alf_: Having output device problems again. It refuses to use the headset and goes thru the PC speaker only :P [07:36] duflu: In a couple of minutes. Or, in fact, now. :) [07:37] Argh and the mic doesn't work either [07:37] I need to log a bug [07:38] This happens too often [07:40] * duflu searches for another mic [07:42] Sorry, I'm out. Need to get a plain old-style mic, and/or a bug fix :( === mmrazik|afk is now known as mmrazik === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [08:23] tvoss, alf_, I believe at the moment the snapshot _includes_ the strut (the top panel), that's why we need the sourceX and sourceY - to _ignore_ the part that's uninteresting [08:23] Saviq, ack [08:24] tvoss, alf_, so if that changes (we get only the surface), we'll need to adapt qtubuntu accordingly [08:24] Saviq: tvoss: Yes, in mir we will just get the surface contents [08:42] alan_g: in light of clang handling "=default" differently from g++ in terms of exceptions, does the recommendation to use =default still stand, or should we prefer "noexcept {}" for destructors? [08:43] alf_: do we see an important difference? [08:46] AFAIK "= default" works fine on interfaces, and we typically have an explicit destructor for implementations. (The exception being google mocks where we have to add "~T() noexcept {}") [08:46] alan_g: I don't think in my case... just wondering for the sake of general correctness [08:50] alf_: correct me if I'm wrong, but isn't the difference in behaviour only evident if you explicitly say "=default" in an implementation? Which is pointless. [08:52] hello [08:52] I need help with some package problems [08:52] alan_g: yes, you are right, I had misinterpreted the problem as applying to all "=default"s, thanks! [08:52] regarding this bug: https://bugs.launchpad.net/unity-system-compositor/+bug/1177722 [08:52] Launchpad bug 1177722 in Unity System Compositor "mir ppa : unity-system-compositor should be built against latest mir libraries" [High,Fix released] [08:57] I have managed to somehow install the lightdm with unity-system-compositor today [08:58] but after I clicked upgrade in my ubuntu window with proposed updates - it uninstalled it to go for the latest build of libmirserver [09:06] xrc: I hear your pain. But I'm not sure what state packaging is in just now. (I know there were changes recently - if RAOF is still about he might know.) [09:07] alan_g, should I try asking him directly? [09:08] xrc: It's his evening - if he didn't see the mention he's not about. [09:12] alan_g, oh, I see. The problem is that I kind of got it installed for a second [09:13] alan_g, only to find it slip through my fingers a moment later... Oh well, waiting I should be then. [09:14] xrc: we are trying to get things sorted (and they mostly work with a bit of patience) but it is still a work in progress [09:23] alan_g, keep up the good work ) sorry if I'm a little bit aggressive on this, just that I'm very excited about MIR ) === alan_g is now known as alan_g|tea === greyback is now known as greyback|shops === alan_g|tea is now known as alan_g === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik === mzanetti is now known as mzanetti|lunch === mzanetti|lunch is now known as mzanetti === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [15:04] alf_: thanks for catching my flawed logic. === alan_g is now known as alan_g|tea [15:06] alan_g: yw, do you think that providing the mentioned guarantee to comm->pause() is feasible with reasonable effort/complexity? === alan_g|tea is now known as alan_g [15:14] * kdub can't think of something other than SwapperDirector [15:14] alf_: we can't allow requests to block and guarantee that they've completed [15:14] Morning! halfway [15:15] greyback: Can we delay sync 20 minutes? [15:15] alan_g: that's true :( [15:15] Afternoon!! [15:16] alf_: we have to allow requests that can't be serviced now to block [15:17] * alan_g thinks that's a possible TODO in display [15:19] alan_g: I think this is much more complicated than we had previously... I am not convinced that the complexity is worth it (meaning that we should explore other ways, too) [15:22] alf_: Perhaps, but I do think that "paused" is actually a meaningful state. [15:23] making frontend keep track of retries is just pushing all the complexity there. [15:24] * alan_g thinks that if we decide to put "pause" logic in another place it grows into a utility class. [15:28] alan_g: I guess I am arguing it's simpler not to support internal retries. That is, do what have been doing until now: when we pause: 1. we ensure that all pending requests are handled 2. we block new requests. It's simple and leaves the server in a clean state. [15:32] alf_: If it isn't simplistic that works for me. Why did we decide that we'd allow blocking in the swapper yesterday? [15:32] racarr: meeting? [15:34] alan_g: because we hadn't thought through all the issues of doing so... and to avoid sending an error response to the client [15:35] we'd have to wait for some free buffers before the pause takes effect then [15:35] which is probably ok, but the response to pause might take some time then [15:35] kdub: that's what has been happening until recently [15:36] It is simple enough to wait for all current requests to finish in communicator::pause() [15:36] yeah [15:36] The problem was that communicator::stop() actually aborts blocked requests [15:37] right, as long as we're not breaking the order that the buffers are going out to the clients, or returning an error code to the clients its ok [15:37] i too forget how that precondition led to the conclusion of yesterday's meeting :) [15:38] alan_g: no, the problem is that, after the swapper-swapper changes, we are throwing an exception from the swapper which leads to an error response [15:39] alf_: No, that was just a quieter failure [15:39] alan_g: the exception is a result of unblocking the client thread (but that didn't used to be the case, unblocking the client thread had no ill effects) [15:39] but we do that because we force_client_completion() [15:40] if we're just waiting for the request to be serviced, then we won't have the exception/error msg [15:40] kdub: but that used to return a (random) buffer [15:40] s/random/handy/ [15:41] alf kdub - hangout? [15:41] alf_: ^ [15:41] alan_g: sure [15:41] greyback: 10 minutes? [15:43] kdub: ? [15:43] sure! [15:43] https://plus.google.com/hangouts/_/afc1479538f15eda73de20aca26fc67be70699b5?hl=en-GB [15:43] https://code.launchpad.net/~alan-griffiths/mir/fix-1189443/+merge/168639 [15:50] ricmm: Can we do our sync whenever greyback comes back? [15:50] i.e. hopefully soon. sorry perfect storm of minor inconveniences on my part lol [15:52] racarr: hey [15:52] we are in a hangout [15:52] Oh. Sorry [15:52] link? [16:02] kdub: SwapperVicePresidentOfInternalOperations :D [16:17] Ok now im really awake [16:20] alan_g: Want to hear about an interesting requirement on frontend/shell (well depending on how you interpret it)? [16:20] racarr_: Want to tell? [16:20] Yes! aha [16:21] So there is the application lifecycle stuff, where the shell can suspend an application that isn't focused [16:21] and then it may just be paused, it may be killed and reloaded later [16:21] (and restore its state from an archive it created) [16:21] etc [16:21] I believe you, go on. [16:21] but the whole time it is a "running application", appears in the running application sources, etc [16:21] which implies that, a Session should stay around after [16:21] WTF?! [16:21] it's socket connection closes [16:22] (well, it could be at other levels too) [16:22] the metaphor isn't that the application is killed it's that [16:22] it is paused, and may come back with a different [16:22] PID [16:22] haha [16:23] metaphors are well and good, but "running" is "running" [16:24] mm. [16:25] I'm unsure if we should punt it entirely to the shell (i.e. they keep track of applications they suspend and mix this in with the mir data source) [16:25] or we have some API where like, the shell can [16:25] steal the session from a session mediator [16:25] and give it back to a new one later [16:25] "mir data source"? [16:25] well, I mean, say from a session listener, they are building a list of session objects, that they somehow map to [16:25] entries in the running app lens, the launcher, etc. [16:26] we can say for applications, in paused lifecycle, you just have to keep track of yourself, and mix them in with the list we give you where you want them, etc (and presumably at this point they are no longer mir::*::Session, but just some data the shell is keeping around) [16:26] racarr_: you're talking implementation when I'd question the sanity of what the feature [16:26] s/what// [16:26] alan_g: It's not so much crazier than [16:27] swap partitions [16:27] racarr_: it is so [16:28] alan_g: To be clear, when I say the application serializes it's state [16:28] I don't mean it dumps it's memory [16:28] racarr_: I didn't read it that way [16:28] ok aha [16:28] anyway, Id unno, I think it makes sense on a phone, if I have a list of "running applications" [16:29] I don't really mind and probably prefer that some are occasionally killed [16:29] but its hidden from me by magic [16:29] when I have low memory [16:29] but to use your analogy - it is like a "swap partition" that loads at a random memory location and leaves the application code to do address fixup [16:32] What should be happening is that the connection remains open and that the resurrected application talks on it. [16:33] mir doesn't need to care. [16:33] s/does/should/ [16:33] Is it possible? [16:34] Well, if no-one tells mir the client has gone it won't know. [16:34] The problem is saving and restoring the client state. [16:34] (Including sockets, file handles, ...) [16:36] racarr_: actually, that doesn't work - the client will have resources (like buffers) that we'd want to release. [16:39] alan_g: I think it's fine to consider [16:39] the surfaces closed. [16:39] racarr_: I think this needs taking through - what resources are needed while the client is suspended? what resources can be reclaimed? What information is persisted in Mir? [16:39] well, no, the surfaces close [16:39] if the surfaces close, then the shell can't preview etc [16:40] well, I think for paused applications it's a snapshot [16:40] made at pause time [16:41] racarr_: so Mir doesn't need to know it is the same application because it doesn't retain any resources? [16:41] alan_g, exactly ... [16:41] alan_g, at least not for step one [16:41] alan_g: No. I mean this was part of my question [16:42] should mir keep track, or do we punt it entirely to the shell [16:42] I think, conceptually somehow, even if there are no resources left (besides, the application metadata) [16:42] racarr_, I think we should collapse the state of non-running sessions [16:42] it seems like Mir (in it's role as the ApplicationManager) [16:42] should still know... [16:43] so there is one source of information "what are the application which are 'running'" (in the user sense) [16:43] tvoss: ? [16:43] one level less abstract ;) [16:43] racarr_, collapsing the state as in open fd's / buffers etc. We can keep track of non-running, recent apps, but we should start over with collapsing active state [16:43] racarr_: the shell takes a snapshot and tells the application to suspend. The application closes the connection and exits. Later the shell tells the application to resume and a new process makes a connection to Mir [16:45] alan_g: Yes, the question is in the mean time, the shell [16:45] wants to display the list of 'running' sessions. somehow [16:45] is it still just a mapping from the SessionManager (i.e. through some hypothetical for_each method or the SessionListener) [16:45] or does it need to track the "suspended" applications itself [16:46] tvoss: Yes. I think closing the buffers is clear (I hadn't really thought about the fds, but just assumed we would close them) [16:46] I am mostly thinking about the API we provide to the shell [16:46] over what actually happens to the resources [16:47] racarr_, fair point, I have an email drafted and will call in a meeting tomorrow my late afternoon [16:47] ok [16:47] Mir handles real applications with real sessions. If the shell wants to report something else... [16:47] the thing that got me thinking about this, is with the [16:47] HUD being out of process and relying on Session IDs [16:47] you gain an extra step there [16:47] unless somehow the session "stays alive" to mir [16:48] How does that make a difference? [16:49] I mean, the HUD has all this precomputed data assosciated with one session ID, then when the session comes back with a new ID [16:49] even though from the perspective of HUD it's supposed to be the same application [16:49] it needs to like, reset or assosciate them somehow [16:49] which, seems incorrect :) [16:49] but I dunno [16:49] racarr_: how does Mir being told about the association help HUD? [16:50] Sesion ID's can stay the asame (just as one example) [16:51] alan_g: Well, the architecture for the HUD is [16:51] HUD is using Mir's internal IDs?! [16:51] Uh. Basically. but maybe that is a little flexible [16:51] the architecture is the applications push their session ID and their menus to the HUD server on startup [16:51] and then receives messages from Mir (well the shell really, over a private API) [16:52] racarr_, I don't think that we have settled on a final solution there :) [16:52] like, "session 4 focused" [16:52] no, iteration 1 [16:52] :) [16:52] anyway that message could just as easily be in terms of [16:52] racarr_: so it gets a message from shell saying "here's a new id for old id" [16:52] alan_g: Yes. [16:52] easier than trying to reuse an id [16:52] That is the extra step that made me think [16:52] that the concepts were wrong [16:55] Either Mir needs to be able to understand suspended sessions and be told by the shell that a new session is a suspended one resuming. Or the HUD needs to understand ID changes. [16:55] Mm. [16:55] I'm sure understanding ID changes is fine [16:56] it's just not the ideal code path [16:58] "not the ideal code path" == "it is harder to make a small change to HUD than a large change to Mir"? [16:59] I wonder if it is such a hard/large change [16:59] I mean what happens if you just close things down, and the shell keeps a reference to the session... [17:00] I dunno [17:00] at this point I don't think there is a strong enough reason for it anymore aha [17:00] just trying to think through the ideas :) [17:03] Associating a new ID with existing data ought to be simpler than managing lifetime. === mmrazik is now known as mmrazik|afk === alan_g is now known as alan_g|life [17:06] alan_g|life: Cya! [17:06] thanks for feedback [17:06] Hope it helps. ;) [17:08] oi, we will keep it simple. [17:19] alan_g|life, something briefly on screen :) [17:20] wow, lots of /sb [17:22] kdub: Nothing much, I had an awful idea and Alan hates me now [17:22] you know, tuesday [17:22] :p [17:23] racarr_: stop projecting [17:23] alan_g|life: I'm just teasing :) [17:24] So am I [17:29] alan_g|life: It's hard to tell, Americans are subconciously programmed to conider all british people very serious [17:29] * alan_g|life [evil laugh] [17:33] Um. So. [17:33] Need to check my brain quickly... [17:33] kdub: SurfaceStack iterates, from rbegin to rend to emit the surfaces to the compositor [17:33] but houldn't it be the other way around and we just don't notice because [17:33] of isngle visibility? [17:34] 'single visibility'? [17:34] kdub: i.e. when we focus surfaces we hide all the others [17:35] so it's unclear that rendering is going backwards ;) [17:35] i guess that depends on how we define the Z ordering [17:35] mm [17:35] I guess create_surface can insert at the bottom and that's [17:35] if we insert the top surface at the end, then its ok [17:35] right [17:35] mm. [17:36] I feel like it's kind of counterintuitive [17:36] with the name stack === mmrazik|afk is now known as mmrazik === olli_ is now known as olli === mmrazik is now known as mmrazik|afk [20:03] we should just have a macro to generate unique include guards on all the headers [20:04] /end c++ boilerplate grumble [20:28] kdub: (fset 'create-mir-class (lambda (&optional arg) "Keyboard macro." (interactive "p") (kmacro-exec-ring-item (quote ([ [20:28] <> [20:28] ;) === racarr_ is now known as racarr [20:29] heh [20:34] qmake [20:34] is not the easiest make :( [20:51] racarr better than Android.mk :P [21:41] RAOF, ping [22:12] Does someone have time to give a pass on depthify stack (hasn't really changed since merging trunk) [22:12] hoping to use it asap (tomorrow?) [22:53] robert_ancell, can you pls make sure I get my ppa q answered? [22:53] olli, yep, have pinged RAOF about it [23:06] racarr, i'll take another look [23:07] kdub_: Thanks :)