ollihey RAOF, not sure if you saw my mail earlier... will I be able to give xmir a spin tomorrow my time?01:44
RAOFolli: Yeah, just processing email.01:45
RAOFYou should be able to, yes.01:45
olliRAOF, great01:45
ollino hurry, I will be afk for a while01:45
RAOFYou definitely will be able to with an xorg.conf change, maybe without (on Intel)01:45
ollias long as it gets to me before you leave for the day01:45
ollisounds good01:46
ollias long as it's documented01:46
ollicya RAOF and everybody else01:46
dufluolli: bye ... ?01:47
dufluAh, my ISP decided they would start trying to diagnose connection problems at 9am. I'm out of whack now01:48
dufluRAOF: SwapbuffersWait=true gets ignored in the PPA's intel driver. It still stays off :(01:55
dufluAlthough if it was doing proper flipping then I would not be seeing tearing. Looks like it's blitting for buffer swapping... ?!01:55
dufluMaybe that assumption is wrong...01:56
RAOFduflu: And, just to check, this is happening with a regular X session, not running under the system compositor?02:00
dufluAFK :P02:00
dufluSome days the whole world tries to contact you simultaneously...02:10
dufluRAOF: Yes regular X with no mir running02:11
RAOFduflu: There'll be a new build of xf86-video-intel shortly; try that.02:11
dufluRAOF: Kay, thanks02:11
RAOFFaster, laptop.05:00
=== Stskeepz is now known as Stskeeps
RAOFduflu: Mesa is why everything is broken for me.05:46
=== mmrazik is now known as mmrazik|afk
RAOFAnd now we're back to where we started.06:42
RAOFWith a ridiculous orange hardware cursor on top of the XMir session :)06:42
mlankhorstfatally orange06:50
dufluUmm, that's out of date. We switched to a black and white one some days ago06:55
dufluWhich reminds me, I meant to propose a smaller one06:56
tvossRAOF, ping06:56
RAOFtvoss: Pong06:57
tvossRAOF, good morning :) you happy with being the primary technical contact for Khronos?06:58
dufluIs that news I see?06:59
RAOFtvoss: Yeah. I've sent that email off.06:59
dufluIn this public forum?06:59
tvossduflu, yup, not a secret I guess :)06:59
tvossRAOF, cool06:59
RAOFKhronos membership is public anyway, right?06:59
tvossRAOF, yup07:00
dufluWoo, we shall paint Khronos a "ridiculous orange"07:00
tvossduflu, :)07:00
tvossalf_, ping07:01
alf_tvoss: pong07:01
tvossalf_, 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:02
alf_tvoss: texture handle created in the EGL context of the shell (inprocess client)?07:04
tvossalf_, yup07:05
alf_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
alf_tvoss: so we don't actually share EGL resources (because we can't) but share the underlying native buffer07:08
tvossalf_, can you give me a ballpark estimate of the work?07:09
tvossalf_, remind me why we can't share the eglcontext?07:09
alf_tvoss: however, there are complications here, since we can't just give native buffers to the shell without synchronization with our internal swapping07:11
tvossalf_, fair enough07:12
alf_tvoss: @sharing eglcontext, because egl objects are namespaced under the egldisplay they are created with07:12
tvossalf_, ack07:12
tvossSaviq, ping07:12
alf_tvoss: @estimation, testing etc 1.5 weeks, + couple of days for spike first to ensure what we are trying to do will actually work07:14
alf_tvoss: (e.g. a feasibility check)07:14
tvossalf_, 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/killed07:15
dufluHmm, isn't a "snapshot" a much simpler case? We're going to need a non-GL interface for that to eventually support screenshotting too07:16
alf_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
RAOFYeah. Is there any particular reason why the snapshots shouldn't be exposed as a blob of bytes?07:17
alf_tvoss: (2) What does it want to get back? Pixels, like now or a texture?07:18
tvossalf_, right now, we are using pixels that are uploaded to a texture (saviq, please correct me if I'm wrong)07:18
dufluEventually we'll need pixels. But some shell features require more efficient textures... like a switcher07:19
tvossduflu, exactly, and turning a texture to pixels is always possible07:19
dufluAlthough it's interesting to point out that Compiz does the live-previews thing without any "snapshotting"07:19
tvossduflu, that's use-case (1.) though, where the app is running and the surface exists07:19
tvossduflu, we still need "previews"/"snapshots" of the last state for killed/stopped apps (implication of the lifecycle model)07:20
RAOFThe other option of course is that the surface still exists with the most-recent content.07:20
dufluWell, not just transform, but hook drawing functions and redraw a surface in multiple locations (like a workspace switcher)07:20
tvossduflu, agreed, that's what I call "transformation" *handwaving*07:21
alf_tvoss: for killed apps pixels are the only way forward, because otherwise we would need to keep buffers alive...07:21
RAOFalf_: Why can't we keep buffers alive?07:21
dufluYeah you need "pixels" for killed/suspended apps. And also screenshot utils07:21
tvossduflu, alf_ okay, pixels sounds like a good idea then ...07:21
dufluBecause it's unreasonable (I think) to say a screen shot util needs to be a GL app07:22
RAOFduflu: Oh, certainly. But that's orthogonal.07:22
RAOFIs 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
dufluYeah. Just wondering if we need both approaches or only one07:22
tvossalf_, for the snapshotting/synchronization: I would think that the shell interacts with a surface object for the snapshotting, too ...07:23
dufluRAOF: We do it already ;) ... https://bugs.launchpad.net/mir/+bug/118845107:23
ubot5Launchpad bug 1188451 in Mir "Mir server leaks surfaces from dead clients" [High,Confirmed]07:23
RAOFI don't think we'll be saving any appreciable amount of scarce resources by destroying the buffer but keeping the contents.07:23
RAOFduflu: Heh.07:23
tvossduflu, mark it a feature then :)07:23
dufluHmm, it's a feature when we /want/ to leak07:24
alf_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
alf_RAOF: However, giving out the buffer while the DS still owns it, is a world of sync hell.07:25
RAOFNot destroying the surface for an app that's tombstoned would fix that, though.07:26
RAOFBonus marks if we can get the resurrected app to use the same surface, so it starts with valid content.07:26
dufluIt's only in sync after it's tombstoned :)07:26
dufluHence not useful for other screenshotting apps07:26
RAOFduflu: 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
dufluHmm, Nexus4 is giving me stuttering. But only when I wasn't looking. Now I'm looking for the bug it's fine07:27
tvossRAOF, yeah, like removing all buffers except for the most current one from the surface07:28
dufluAh there it is07:28
RAOF*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:28
alf_tvoss: RAOF: duflu: Saviq: Have time for a hangout?07:30
RAOFI'll be bathing Zoƫ soon.07:30
tvossRAOF, will you be back after the bath?07:30
duflualf_, in a couple of minutes, or later...07:31
RAOFJust delegated bathing to Sam.07:31
RAOFI may pop in and out once or twice, but I'm good to go.07:31
* tvoss searches for the headset07:31
tvossgood to go07:32
RAOFOh, and we don't have a thomi this week, do we?07:32
tvossRAOF, nope07:33
alf_tvoss: RAOF: duflu: https://plus.google.com/hangouts/_/d306e4af1fc3351c7a344cb62ef288f737707419?hl=en07:33
duflualf_: Having output device problems again. It refuses to use the headset and goes thru the PC speaker only :P07:35
RAOFduflu: In a couple of minutes. Or, in fact, now. :)07:36
dufluArgh and the mic doesn't work either07:37
dufluI need to log a bug07:37
dufluThis happens too often07:38
* duflu searches for another mic07:40
dufluSorry, I'm out. Need to get a plain old-style mic, and/or a bug fix :(07:42
=== 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
Saviqtvoss, 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 uninteresting08:23
tvossSaviq, ack08:23
Saviqtvoss, alf_, so if that changes (we get only the surface), we'll need to adapt qtubuntu accordingly08:24
alf_Saviq: tvoss: Yes, in mir we will just get the surface contents08:24
alf_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:42
alan_galf_: do we see an important difference?08:43
alan_gAFAIK "= 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
alf_alan_g: I don't think in my case... just wondering for the sake of general correctness08:46
alan_galf_: 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:50
xrcI need help with some package problems08:52
alf_alan_g: yes, you are right, I had misinterpreted the problem as applying to all "=default"s, thanks!08:52
xrcregarding this bug: https://bugs.launchpad.net/unity-system-compositor/+bug/117772208:52
ubot5Launchpad bug 1177722 in Unity System Compositor "mir ppa : unity-system-compositor should be built against latest mir libraries" [High,Fix released]08:52
xrcI have managed to somehow install the lightdm with unity-system-compositor today08:57
xrcbut after I clicked upgrade in my ubuntu window with proposed updates - it uninstalled it to go for the latest build of libmirserver08:58
alan_gxrc: 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:06
xrcalan_g, should I try asking him directly?09:07
alan_gxrc: It's his evening - if he didn't see the mention he's not about.09:08
xrcalan_g, oh, I see. The problem is that I kind of got it installed for a second09:12
xrcalan_g, only to find it slip through my fingers a moment later... Oh well, waiting I should be then.09:13
alan_gxrc: we are trying to get things sorted (and they mostly work with a bit of patience) but it is still a work in progress09:14
xrcalan_g, keep up the good work ) sorry if I'm a little bit aggressive on this, just that I'm very excited about MIR )09:23
=== 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
alan_galf_: thanks for catching my flawed logic.15:04
=== alan_g is now known as alan_g|tea
alf_alan_g: yw, do you think that providing the mentioned guarantee to comm->pause() is feasible with reasonable effort/complexity?15:06
=== alan_g|tea is now known as alan_g
* kdub can't think of something other than SwapperDirector15:14
alan_galf_: we can't allow requests to block and guarantee that they've completed15:14
racarrMorning! halfway15:14
racarrgreyback: Can we delay sync 20 minutes?15:15
alf_alan_g: that's true :(15:15
alan_galf_: we have to allow requests that can't be serviced now to block15:16
* alan_g thinks that's a possible TODO in display15:17
alf_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:19
alan_galf_: Perhaps, but I do think that "paused" is actually a meaningful state.15:22
alan_gmaking frontend  keep track of retries is just pushing all the complexity there.15:23
* alan_g thinks that if we decide to put "pause" logic in another place it grows into a utility class.15:24
alf_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:28
alan_galf_: If it isn't simplistic that works for me. Why did we decide that we'd allow blocking in the swapper yesterday?15:32
greybackracarr: meeting?15:32
alf_alan_g: because we hadn't thought through all the issues of doing so... and to avoid sending an error response to the client15:34
kdubwe'd have to wait for some free buffers before the pause takes effect then15:35
kdubwhich is probably ok, but the response to pause might take some time then15:35
alf_kdub: that's what has been happening until recently15:35
alan_gIt is simple enough to wait for all current requests to finish in communicator::pause()15:36
alan_gThe problem was that communicator::stop() actually aborts blocked requests15:36
kdubright, 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 ok15:37
kdubi too forget how that precondition led to the conclusion of yesterday's meeting :)15:37
alf_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 response15:38
alan_galf_: No, that was just a quieter failure15:39
alf_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
kdubbut we do that because we force_client_completion()15:39
kdubif we're just waiting for the request to be serviced, then we won't have the exception/error msg15:40
alan_gkdub: but that used to return a (random) buffer15:40
alan_galf kdub - hangout?15:41
alan_galf_: ^15:41
alf_alan_g: sure15:41
racarrgreyback: 10 minutes?15:41
alf_kdub: ?15:43
racarrricmm: Can we do our sync whenever greyback comes back?15:50
racarri.e. hopefully soon. sorry perfect storm of minor inconveniences on my part lol15:50
ricmmracarr: hey15:52
ricmmwe are in a hangout15:52
racarrOh. Sorry15:52
alf_kdub: SwapperVicePresidentOfInternalOperations :D16:02
racarr_Ok now im really awake16:17
racarr_alan_g: Want to hear about an interesting requirement on frontend/shell (well depending on how you interpret it)?16:20
alan_gracarr_: Want to tell?16:20
racarr_Yes! aha16:20
racarr_So there is the application lifecycle stuff, where the shell can suspend an application that isn't focused16:21
racarr_and then it may just be paused, it may be killed and reloaded later16:21
racarr_(and restore its state from an archive it created)16:21
alan_gI believe you, go on.16:21
racarr_but the whole time it is a "running application", appears in the running application sources, etc16:21
racarr_which implies that, a Session should stay around after16:21
racarr_it's socket connection closes16:21
racarr_(well, it could be at other levels too)16:22
racarr_the metaphor isn't that the application is killed it's that16:22
racarr_it is paused, and may come back with a different16:22
alan_gmetaphors are well and good, but "running" is "running"16:23
racarr_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
racarr_or we have some API where like, the shell can16:25
racarr_steal the session from a session mediator16:25
racarr_and give it back to a new one later16:25
alan_g"mir data source"?16:25
racarr_well, I mean, say from a session listener, they are building a list of session objects, that they somehow map to16:25
racarr_entries in the running app lens, the launcher, etc.16:25
racarr_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
alan_gracarr_: you're talking implementation when I'd question the sanity of what the feature16:26
racarr_alan_g: It's not so much crazier than16:26
racarr_swap partitions16:27
alan_gracarr_: it is so16:27
racarr_alan_g: To be clear, when I say the application serializes it's state16:28
racarr_I don't mean it dumps it's memory16:28
alan_gracarr_: I didn't read it that way16:28
racarr_ok aha16:28
racarr_anyway, Id unno, I think it makes sense on a phone, if I have a list of "running applications"16:28
racarr_I don't really mind and probably prefer that some are occasionally killed16:29
racarr_but its hidden from me by magic16:29
racarr_when I have low memory16:29
alan_gbut 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 fixup16:29
alan_gWhat should be happening is that the connection remains open and that the resurrected application talks on it.16:32
alan_gmir doesn't need to care.16:33
racarr_Is it possible?16:33
alan_gWell, if no-one tells mir the client has gone it won't know.16:34
alan_gThe problem is saving and restoring the client state.16:34
alan_g(Including sockets, file handles, ...)16:34
alan_gracarr_: actually, that doesn't work - the client will have resources (like buffers) that we'd want to release.16:36
racarr_alan_g: I think it's fine to consider16:39
racarr_the surfaces closed.16:39
alan_gracarr_: 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
racarr_well, no, the surfaces close16:39
alan_gif the surfaces close, then the shell can't preview etc16:39
racarr_well, I think for paused applications it's a snapshot16:40
racarr_made at pause time16:40
alan_gracarr_: so Mir doesn't need to know it is the same application because it doesn't retain any resources?16:41
tvossalan_g, exactly ...16:41
tvossalan_g, at least not for step one16:41
racarr_alan_g: No. I mean this was part of my question16:41
racarr_should mir keep track, or do we punt it entirely to the shell16:42
racarr_I think, conceptually somehow, even if there are no resources left (besides, the application metadata)16:42
tvossracarr_, I think we should collapse the state of non-running sessions16:42
racarr_it seems like Mir (in it's role as the ApplicationManager)16:42
racarr_should still know...16:42
racarr_so there is one source of information "what are the application which are 'running'" (in the user sense)16:43
racarr_tvoss: ?16:43
racarr_one level less abstract ;)16:43
tvossracarr_, 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 state16:43
alan_gracarr_: 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 Mir16:43
racarr_alan_g: Yes, the question is in the mean time, the shell16:45
racarr_wants to display the list of 'running' sessions. somehow16:45
racarr_is it still just a mapping from the SessionManager (i.e. through some hypothetical for_each method or the SessionListener)16:45
racarr_or does it need to track the "suspended" applications itself16:45
racarr_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
racarr_I am mostly thinking about the API we provide to the shell16:46
racarr_over what actually happens to the resources16:46
tvossracarr_, fair point, I have an email drafted and will call in a meeting tomorrow my late afternoon16:47
alan_gMir handles real applications with real sessions. If the shell wants to report something else...16:47
racarr_the thing that got me thinking about this, is with the16:47
racarr_HUD being out of process and relying on Session IDs16:47
racarr_you gain an extra step there16:47
racarr_unless somehow the session "stays alive" to mir16:47
alan_gHow does that make a difference?16:48
racarr_I mean, the HUD has all this precomputed data assosciated with one session ID, then when the session comes back with a new ID16:49
racarr_even though from the perspective of HUD it's supposed to be the same application16:49
racarr_it needs to like, reset or assosciate them somehow16:49
racarr_which, seems incorrect :)16:49
racarr_but I dunno16:49
alan_gracarr_: how does Mir being told about the association help HUD?16:49
racarr_Sesion ID's can stay the asame (just as one example)16:50
racarr_alan_g: Well, the architecture for the HUD is16:51
alan_gHUD is using Mir's internal IDs?!16:51
racarr_Uh. Basically. but maybe that is a little flexible16:51
racarr_the architecture is the applications push their session ID and their menus to the HUD server on startup16:51
racarr_and then receives messages from Mir (well the shell really, over a private API)16:51
tvossracarr_, I don't think that we have settled on a final solution there :)16:52
racarr_like, "session 4 focused"16:52
racarr_no, iteration 116:52
racarr_anyway that message could just as easily be in terms of16:52
alan_gracarr_: so it gets a message from shell saying "here's a new id for old id"16:52
racarr_alan_g: Yes.16:52
alan_geasier than trying to reuse an id16:52
racarr_That is the extra step that made me think16:52
racarr_that the concepts were wrong16:52
alan_gEither 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
racarr_I'm sure understanding ID changes is fine16:55
racarr_it's just not the ideal code path16:56
alan_g"not the ideal code path" == "it is harder to make a small change to HUD than a large change to Mir"?16:58
racarr_I wonder if it is such a hard/large change16:59
racarr_I mean what happens if you just close things down, and the shell keeps a reference to the session...16:59
racarr_I dunno17:00
racarr_at this point I don't think there is a strong enough reason for it anymore aha17:00
racarr_just trying to think through the ideas :)17:00
alan_gAssociating a new ID with existing data ought to be simpler than managing lifetime.17:03
=== mmrazik is now known as mmrazik|afk
=== alan_g is now known as alan_g|life
racarr_alan_g|life: Cya!17:06
racarr_thanks for feedback17:06
alan_g|lifeHope it helps. ;)17:06
racarr_oi, we will keep it simple.17:08
kdubalan_g|life, something briefly on screen :)17:19
kdubwow, lots of /sb17:20
racarr_kdub: Nothing much, I had an awful idea and Alan hates me now17:22
racarr_you know, tuesday17:22
alan_g|liferacarr_: stop projecting17:23
racarr_alan_g|life: I'm just teasing :)17:23
alan_g|lifeSo am I17:24
racarr_alan_g|life: It's hard to tell, Americans are subconciously programmed to conider all british people very serious17:29
* alan_g|life [evil laugh]17:29
racarr_Um. So.17:33
racarr_Need to check my brain quickly...17:33
racarr_kdub: SurfaceStack iterates, from rbegin to rend to emit the surfaces to the compositor17:33
racarr_but houldn't it be the other way around and we just don't notice because17:33
racarr_of isngle visibility?17:33
kdub'single visibility'?17:34
racarr_kdub: i.e. when we focus surfaces we hide all the others17:34
racarr_so it's unclear that rendering is going backwards ;)17:35
kdubi guess that depends on how we define the Z ordering17:35
racarr_I guess create_surface can insert at the bottom and that's17:35
kdubif we insert the top surface at the end, then its ok17:35
racarr_I feel like it's kind of counterintuitive17:36
racarr_with the name stack17:36
=== mmrazik|afk is now known as mmrazik
=== olli_ is now known as olli
=== mmrazik is now known as mmrazik|afk
kdubwe should just have a macro to generate unique include guards on all the headers20:03
kdub /end c++ boilerplate grumble20:04
racarr_kdub: (fset 'create-mir-class (lambda (&optional arg) "Keyboard macro." (interactive "p") (kmacro-exec-ring-item (quote ([20:28
=== racarr_ is now known as racarr
kdub heh20:29
racarris not the easiest make :(20:34
kdubracarr better than Android.mk :P20:51
olliRAOF, ping21:41
racarrDoes someone have time to give a pass on depthify stack (hasn't really changed since merging trunk)22:12
racarrhoping to use it asap (tomorrow?)22:12
ollirobert_ancell, can you pls make sure I get my ppa q answered?22:53
robert_ancellolli, yep, have pinged RAOF about it22:53
kdub_racarr, i'll take another look23:06
racarrkdub_: Thanks :)23:07

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!