[00:15] vibhav: What's your intended target for python-mir? Just binding the functions in the mirclient API would work, but depending on your target you might want to do something extra. [01:24] RAOF: heh, I'm just thinking about how well the multithreaded callbacks would interact with the GIL [01:25] Easily! You marshal everything into a single thread! [01:25] RAOF: of course. But ideally you'd probably want to do that in a separate library and then bind to that [01:26] since otherwise you'd have crazy locking overhead [01:26] (*based on a vast oversimplication of the GIL) [01:27] RAOF: I remember it was quite surreal when racarr was explaining that to me while we managed to get lost on the bart [01:27] Heh [01:29] RAOF: I actually kinda like the multithreaded callbacks approach, partially because it means Death to the Main Loop [tm]. The only downside is that integrating it with a main loop is a little awkward [01:31] RAOF: Hmm, there's no /Mir/ in any live images yet, right? [01:32] smspillaz: Also, if you're receiving non-input surface events, that's a different thread again :) [01:33] I mean :S [01:33] duflu: yeah, iirc it was one thread for surface events and one thread for input events [01:33] smspillaz: https://bugs.launchpad.net/mir/+bug/1194384 [01:33] Ubuntu bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged] [01:34] duflu: I don't think the threading is a problem, rather - the whole MirEvent is just awkward [01:34] *MirEvent thing [01:34] I much prefer the wayland approach -> every unique event happens in its own callback [01:35] smspillaz: Can you elaborate? [01:35] Because technically all events have their own callbacks [01:35] Or you mean callback type? [01:36] that being said - wayland screws up in one area: keyboard and mouse events are reported to you in surface relative co-ordinates but you can only have one handler per mouse or keyboard [01:36] (afaict) [01:36] duflu: callback type [01:36] I see [01:36] duflu: unions are a kinda sucky way of representing data like this [01:36] see XEvent [01:36] It is nice to be able to take shortcuts and sometimes handle different even types in a single callback [01:37] Not to mention, nice to avoid the user learning many callback prototypes [01:37] and then you end up with a thousand-line long "Event" callback [01:37] which is made worse by the fact that it may be called in multiple threads simultaneously [01:38] and the only real way to fix that would be to dispatch the potentially giant switch statement into separate functions [01:38] ... which might as well be done at the client library level [01:39] see for instance: https://github.com/smspillaz/xbmc/commit/ddab367b4928bc50f168d157b6b4939f3062402a#L2R78 [01:40] (ah, my bad, wayland does actually give you the surface the event happened on) [01:41] smspillaz: Fair point. I would then say... use a single callback prototype demultiplexed at registration: set_event_handler(filter, callback) [01:41] duflu: eg - wl_pointer_add_listener :) [01:43] (I would show you an example, but I can't because I have to dlopen libwayland-client.so and then use the protocol directly because things like wl_pointer_add_listener are all static inline functions ....) [01:44] but eg: https://github.com/smspillaz/xbmc/commit/ddab367b4928bc50f168d157b6b4939f3062402a#L2R36 [01:49] smspillaz: BTW pointer events are meant to be surface-relative in Mir too. It's just not implemented yet [01:50] -pointer +motion [02:24] That's odd. My Mir performance dropped about 5% over the weekend (after updates) [02:26] But it's only compositing performance that dropped. Bypass results are unchanged [02:33] duflu: There are no *official* cdimages.ubuntu.com images, but the Xubuntu team did create one using the latest from the system-compositor-testing PPA for ease of testing. [02:33] TheDrums: Ah thanks. That explains the new bug reports from Xubuntu users against Mir [02:34] Yes, seems while several of the Mir devs were sent the message, you were not one of them. [02:36] Marking the one report about complete screen corruption as incomplete was not a good thing as the only information that was recoverable was provided. The logs are inaccessible. [02:36] Unless we were running exterior serial consoles, we wouldn't have had a way to recover such. [02:38] duflu: http://www.mail-archive.com/xubuntu-devel@lists.ubuntu.com/msg08905.html is the message. [02:41] skellat, I know that now. About to fix it [03:22] ♪ And on that farm he had a laptop ♫ [03:30] RAOF: Awesome! (?) [03:31] Yes. [03:32] RAOF: Quad core IPS SSD goodness? [03:32] Correct [03:33] * duflu gives all builds to RAOF [03:44] RAOF: What's the key "depth" like? [03:45] It's pretty shallow, but typable. [03:47] Luncheon. [05:16] good morning :) [05:17] RAOF, ping [05:17] duflu, ping [05:18] tvoss_: Pong [05:20] duflu, ping [05:43] tvoss_: pong [06:00] alf__, duflu could you guys please sync up on the multi-monitor and switch-branch integration? A summary by mail would be great! [06:01] tvoss_: duflu: sure [06:03] alf__: I will try to do the timing workaround to solve non-cloned multi-output. Then "more robust solutions" are not on the critical path and blocking... [06:06] duflu: The BackBufferStrategy mechanism was introduced as a way to inject policy for such situations (MultiAcquisition being one such policy). I think it is the right layer to put the policy into, vs the Compositor, which should not have to care about this at all. [06:07] alf__: I think the strategy layer is a bit hackish. It exists to match the exact semantics in which buffers will be called/used. That would be better enforced where they are called and used (hence "more robust") [06:08] -called +acquired [06:11] alf__: I mean, a nicer solution would be to keep that multi-monitor logic closer to the multi-monitor compositing. [06:11] I was only suggesting the timing workaround as a quick solution which requires no effort on your part [06:12] Unless there are other "simple" ways to semi-synchronize the compositing threads without actually synchronizing them [06:13] And without breaking bypass requirements [06:13] duflu, are you loosing the z character? [06:14] tvoss_ ? [06:14] duflu, my xchat eats away certain characters :) [06:14] tvoss_: No, it's just you... ? [06:14] duflu, damn :) [06:14] duflu: how would that work in the (DisplayBuffer)Compositor? [06:15] alf__: You mean timing workaround? [06:15] duflu: yes [06:15] alf__: Actual comsumed compositor buffers get a timestamp. And new ones are not allowed to be consumed (hence get reused) for the next 10ms [06:16] So multiple monitors with roughly the same refresh rates share the same compositor buffer. Or at least don't steal each other's or wake the client up any faster than one monitor would [06:17] It actually feels close to the "right solution", just maybe in the wrong place [06:18] And bonus: That won't break bypass. [06:20] duflu: How does MultiAcquisition break bypass (I don't mind dropping it, I am just trying to undestand). In any case the ultimate benchmark for this is how much each policy affects visual fluidity. BTW, you can run mir_demo_server_shell --display-config=sidebyside (with two screens) and move clients between the outputs to test. [06:21] (from lp:mir) [06:21] alf__: Cool thanks [06:22] alf__: The issue with multiacquisition, which had be stuck for weeks, was its assumptions about the exact ordering of compositor acquire/release calls. Bypass has two acquired simultaneously most of the time, but also requires that they're always different buffers (when available) [06:22] -be +me [06:23] alf__: Also, no one has pinpointed the first primary cause of the lag bug. Other than it was in the buffering code I replaced, _somewhere_ :/ [06:23] duflu: isn't this fixed by https://code.launchpad.net/~vanvugt/mir/fix-1199450/+merge/178236 ? [06:24] alf__: The first cause is fixed by switch (prerequisite). But switch introduces triple buffering which would cause the same problem. So the fix- branch solves that too [06:26] duflu: do we always use triple buffering or only for framedropping and bypass? [06:27] alf__: It's always triple now, logically. But I defer allocating the third buffer until the client behaves in a way that uses 3 simultaneously [06:28] The lazy allocation is generalized... it keeps the number of real buffers low until more are required [06:29] duflu: sounds good [06:30] * duflu shuffles monitors [06:33] duflu: hmm, how do you stop a client that is (or rather wants to be) double-buffered from acquiring the third buffer? [06:37] alf__: I just realized the primary thing keeping it at double was removed when I fixed those issues on Friday. Now it's only timing keeping it at double. If a client tries to render without using a timer (limited only by swapping) then it will expend to triple very quickly now :/ [06:37] -expend +expand [06:37] That might need revisiting. I can add dynamic resizing without much fuss [06:50] alf__: Multi-monitor just works, nice. If only I had a GUI to set the layout :) [06:51] Or a language... like "DVI1 leftof VGA1" [07:22] didrocks: Have we won a Mir promotion to Main? [07:23] RAOF: it was too late on Friday and risky, so we pinned to proposed. The promotion/publication is now in progress [07:23] didrocks: Cool. Sorry about that delay. [07:24] RAOF: no worry ;) [07:32] good morning [07:43] Hm. Zoë bath time! === hikiko is now known as hik|afk [08:17] alf__: Just a minor speedhump: https://bugs.launchpad.net/mir/+bug/1208354 [08:17] Ubuntu bug 1208354 in Mir "mir_demo_server_shell crashes with --display-config=sidebyside" [Undecided,New] [08:18] duflu: ahh, yes this is fixed by lp:~afrantzis/mir/multimonitor-misc-fixes ⇒ lp:mir (will hopefully land soon) [08:18] alf__: Very nice, thanks === hik|afk is now known as hikiko [08:32] RAOF: still around? [08:39] didrocks: Yeah. [08:40] RAOF: see #ubuntu-devel please :) [08:40] didrocks: Ah, I see #ubuntu-devel. [08:40] heh ;) [08:40] can we just drop ppc? :p [08:41] +1000 :p === dholbach_ is now known as dholbach [09:51] alf__: I will have most of your requests resolved tonight but not all... At least multi-monitor is fixed, without breaking bypass \o/ [09:52] duflu: great! [09:58] duflu, \o/ [10:24] Saviq, ping [10:26] doko, pong [11:05] hikiko: how's it going? [11:18] alan_g, I started from create display [11:18] and now I am writing a NestedDisplay class [11:19] do you think I should do something else first [11:19] ? [11:20] hikiko: that sounds a sensible approach === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === bregma_ is now known as bregma [14:15] Morning [14:29] racarr: morning! [14:29] Afternoon === alan_g is now known as alan_g|tea [14:30] greyback: Morning! welcome back [14:30] racarr: thanks :) [14:32] greyback: I'm sure you are still catching up but maybe we should do a catch up soon? [14:32] I was kind of doing other stuff last weekly so expect for some stuff for OSK mostly not on unity [14:32] racarr: certainly. Whenever you're ready [14:32] so kind of lost track of exact status [14:32] Yep I'd like to know where the OSK work is at [14:32] greyback: Ok after the 8:00 mir stand up maybe? [14:32] Daniel is away, so I need to at least know what it's status is [14:32] racarr: perfect [14:46] greyback: racarr can i lurk on your sync? [14:46] kgunn: sure [14:50] kgunn: Eh... [14:50] it's kind of "cool crowd only"...so I dunno [14:50] :p [14:51] I am just teasing. Have a good time in IoM? [14:52] racarr: consider we were the only people at that hotel under 60.... :-/ [14:54] racarr: we did gointo town one night...me ancell, didier & michal... food was sooo good & company was good :) === alan_g|tea is now known as alan_g [14:59] kgunn: Aha. that must have been a little strange (hotel situation) [14:59] didrocks: just checking in...did RAOF overcome the alioth issue [14:59] hey! [14:59] racarr: it was bizzare [14:59] kgunn: he did, and so we have everything uploaded [14:59] promoted some components to Main [14:59] howerver, multiples upload from him and I to ignore properly powerpc [15:00] however, on two components [15:00] we still try to build with mir for the -ati and -nouveau driver [15:00] so this one should be fixed, RAOF assume this wasn't needed (but it wasn't built) when I asked him [15:01] we can: [15:01] - either do a bad/ugly #ifdef [15:01] - let RAOF fix it more properly (I would be more in favor of that) [15:01] the second point is that unity-system-compositor don't enable accceleration anymore on the intel or ati machine [15:01] so even unity doesn't start [15:02] didrocks: good ol' powerpc :)....ok, that stinks about new prob [15:02] didrocks: did you really mean intel ? or nvidia rather [15:03] nvidia, sorry :) [15:03] I can't even use jetlag as an excuse [15:03] kgunn: for powerpc, I'll be in favor of guns if this continues that road ;) [15:04] :)) [15:04] I'll send an email with you/RAOF/robert [15:25] greyback: Sync up? [15:25] kgunn: ^ [15:25] racarr: ok [15:26] racarr: gotta link ? [15:27] making one [15:27] https://plus.google.com/hangouts/_/a38f0a95d50f766f61f95dd52ef79056c74c360c?authuser=1&hl=en [15:27] kgunn: greyback: ^ [15:28] ricmm: ^ [15:56] racarr: were you going to refactor down to singled method interface first ? or try chasing some approval on the current mp ? [15:56] regarding...https://code.launchpad.net/~robertcarr/mir/surface-configuration-interface--for-shell/+merge/177055 [16:05] kgunn: i am not sure [16:06] I am not throwing up my hands (actively thinking about it) but am kind of at a loss on both branches as it stands [16:08] The single method variant is awkward, because like in the comment I just left [16:08] you end up applying the surface state changes, etc, before you actually update the member variable tracking the state [16:10] and there are all sorts of ways around that (i.e. the function returns the new state, and an std::function to apply it which the surface then calls after updating the member variable. Or the configuration interface gets some object/function passed in that it uses to update the surface state in between the selection and application step [16:11] but both of these just mean, instead of an interface with two roles it's now a method with two roles. [16:12] so I am not sure this makes sense. [16:13] I also can't make an argument that it makes sense to split each method in to a seperate interface, i.e. AttributeDecider and AttributeApplier because [16:13] they will always be passed around in a pair in the server [16:14] so pattern is to pass them as a composite type i.e. some AttributeStuff, which has ethods like decider() and applier() [16:14] but then it's not clear why that method doesn't just have decide, and apply, like the configurator does now in the MP [16:17] I think it's probably somewhat more of an indication tht the way we are handling state of msh::Surface is bad [16:18] so I guess I am seeing if there is something I can do about that for the attribute stuff without taking more than a few days [16:24] alan_g: A completely different proposal for surace-configuration-interface [16:24] alan_g: msh::Surface loses the state, type, etc member variables [16:24] racarr: sorry, my head is full of ~vanvugt/mir/switch/+merge/178527 [16:24] that's ok :) [16:25] But that sounds interesting [16:26] alan_g: Basically the thought is if mir is only passing these values through the shell and frontend perhaps it should be a shell component that stores them and mir just passes interfaces to this component for getting back out to frontend [16:26] but it's not too much hassle so maybe I will just try and implement it and you can check it out later :) [16:26] switch branch scares me ;) [16:29] alan_g: btw if you are ever bored remind me to tell you about the craziest (most interesting ;) idea I have ever heard for handling mutable state in highly threaded C++ programs XD [16:29] racarr: The problem of where to store these values (and how to synchronize access to them) dates from the decision to hold them in the shell, and not in the model. [16:29] it needs GC though so it's not for us. it's just really interesting [16:29] racarr: I'll take a raincheck [16:30] XD [16:30] yeah, I understand that bit sort of [16:31] racarr: maybe kdub can take a peek this afternoon [16:32] Yeah. I'll harass him ;) [16:33] alan_g: This might be a step in that direction, i.e. rather than the surface holding this state directly it gets it through some get_attribute and set_attribute interface to this SurfaceConfiguration from the shell [16:34] which could also be implemented by [16:34] super scene graph model 2.0 :p [16:34] racarr: I know I need to get back on that hobbyhorse [16:34] And actually propose something concrete. [16:35] alan_g: Ok. That would be good [16:35] If only folks would stop with the big complicated MPs [16:35] I haven't been able to get to anything concrete on that [16:35] ... ;) [16:35] and I am worried that we are [16:35] approaching feature freeze [16:37] alan_g: I.e. feature freeze is august 29th [16:37] racarr, peek at notify focus? or switch [16:38] kdub: Err, the surface-configuration-interface [16:38] it doesn't exactly need review, just ideas I guess [16:38] racarr, i'll refill my coffee and take a look now [16:39] kdub: Ah. excellent. Thanks :) [16:42] bschaefer: are you free-ish today ? [16:42] kgunn, a bit more ibus stuff to do, but after that I should be [16:42] kgunn, still trying to get my desktop back up and working :( [16:43] bschaefer: oh crap [16:43] bschaefer: but ok...i'll loop you in [16:43] yeah, my HD decided to die and can no longer read/write to it...soo its toast :(, but i've to reinstall some new things to a new HD! [16:43] kgunn, sounds good! [16:46] kdub: racarr ...yeah, hate to be the management ogre....but we really need to target gettting unity/mir onto touch trunk (w/ osk consideration) 10 days from now [16:47] * racarr takes one of the little pills labelled "Up" [16:47] :p [16:53] Another option for client-focus-notifications [16:54] surface loses surface_state_focused/unfocused. introduce an interface msh::Focus with one method Focus::give(std::shared_ptr) [16:55] this obect tracks the current focus, so it can do unfocused notifications [16:55] it also needs to know to give the focus to the next surface if [16:55] the focused surface is destroyed, so I think msh::Surface also gains a method like [16:55] racarr, the cloggable event sink [16:56] i still feel like i'm missing the big picture on the 'why' [16:56] msh::Surface::take_focus(std::unique_ptr) [16:56] with a d'tor that knows what to do [16:56] kdub: Basically the idea is inbetween the call to create_surface [16:56] and sending a response to the client [16:57] we may generate surface configuration events [16:57] i.e. surface id 7 took focus [16:57] but if we send this to the client before it's been told what surface id 7 is [16:57] it can't interpret it [16:58] ah, gotcha [16:58] so we have to ensure the wire events are sent after the create_surface response [16:58] kdub: it's a little sketchy actually because it relies [16:58] on the fact that invoking the Done callback from create_surface [16:58] synchronously writes the message. [17:00] seems like the object with the best information to control that timing is the msh::Surface [17:00] perhaps the SessionManager as well [17:00] hmm, not as it stands now, because even after SessionManager::create_surface_for [17:00] returns [17:00] the SessionManager can't know if things have been sent over the wire yet [17:01] right, so it seems the shell has a false idea about when a surface is up and running [17:02] maybe msh::Surface should have the same lifetime as the client surface on the other side of the ipc barrier? [17:03] that way a focus event could block there until we know the client is ready [17:03] maybe [17:04] alternatively, we could just have more complex logic client side [17:04] I think you can always end up with [17:04] situations where the client can't decide? Maybe not. === alan_g is now known as alan_g|EOD [17:05] well [17:05] if the client buffers the events and waits until the surface appears [17:05] then it can't really detect events which are actually malformed/in error [17:06] kdub: The lifetime idea is kind of nice but I'm not sure how it would be implemented [17:06] i guess we have two responses now to that rpc call [17:07] 'you are focused' or 'you are not focused' [17:07] that would take care of it too :) [17:07] i.e. you construct all of the surface dependencies, allocate the id, make sure everything works, send the response and then allocate the msh::Surface [17:07] kdub: Not quite because a surface may open and not necessarily receive focus [17:07] or maybe it opens and the shell restores it's state to maximized [17:08] because that's how it was last run [17:08] so there could be many responses I think [17:08] right, the surface opens and is not focused [17:08] at the time the surface is created, we should be able to know the state of the surface [17:08] seems that should be sent as the initial state in the return of the rpc message [17:09] hmm [17:09] ok, so the current model is kind of like, the initial state is defaulted [17:09] i.e. your state is restored, your surface type is normal, you do not have focus [17:09] right [17:09] and you will be notified of anything else [17:10] so we could extend create surface to return like [17:10] surface_id, state, type, focus [17:10] but then wont e still need a proxy event sink? [17:10] Because we have to ensure that later when these change [17:10] that seems like a separate issue [17:10] we still send notification [17:11] the event sink still has to be accessible to the shell surface, yes [17:11] but that we don't send notification on this first call [17:11] but I mean, the surface will still be created in the default state [17:12] so what makes the first change to 'focused' occur as part of the create_surface reply [17:12] and not as an event over the wire [17:12] the shell decides the initial state when the surface is created [17:12] or :) it should be [17:13] that gets sent in the reply, and afterwards, any updates to the state are sent via the event sink [17:14] kdub: I think it's hairy for the shell to decide that way [17:14] because now essentially any interface like [17:15] kdub: Ok, I was thinking [17:15] as opposed to deciding state after creation, and imposing synchronization across/near the ipc boundary so the client can figure out what state its in? :) [17:15] it had to happen before surface construction, but actually it could happen [17:16] kdub: Well my concern s that doing it before surface construction was difficult because then the shell will have methods like [17:16] decide_state_for_surface_creation_params and decide_state_for_surface [17:16] right, not before [17:17] kdub: But actually, the surface could use the SurfaceConfigurator from the other branch (XD) [17:17] er welll I still cant quite figure it out but will go on [17:17] then in it's constructor it calls like [17:17] ipc request comes in, we ask the shell to create a surface, we read the created surface, and then we run done [17:17] state = select_attribute_value(surface_state) [17:17] type = select_attribute_value(type) focus = select_attribute_value(focused) [17:18] and it doesn't go over the event sink because there was no call through to msh::Surface::configure [17:19] sounds better [17:20] kdub: Ok so.I think this makes sense, but now I am having a little difficulty figuring out how the mechanism happens [17:21] kdub: i.e. the surface is being constructed [17:21] i think we need some extra fields in protobuf's Surface [17:21] so the shell gets select_focused(msh::Surface &) [17:21] and says, hey this is a new surface, so it says yes, focused [17:21] but now what actually sets [17:21] the input focus to [17:21] that surface [17:21] I'm not sure if it makes sense for [17:22] it to be select_focused because [17:22] the surface isn't even initialized at that point. [17:23] we need to ban the use of the word 'surface' :) [17:24] it isn't initialized where? [17:24] client side? [17:24] no, I meant, on the server, if we use some interface like [17:24] select_attribute_value(focused) that is called during the constructor [17:24] and no one is notified of this [17:24] then what actually sets the input focus [17:27] from the frontend, i see this [17:27] http://pastebin.com/vD7UCRUs [17:29] kdub: Ok. [17:29] kdub: trying to reword the last concern. [17:29] the thing is, right now the FocusMechanism, sets the focused attribute on the surface [17:29] okay, yeah. i sorta detected we were talking about two different parts of code [17:30] after, applying the mechanism of the focus of the surface. i.e. making sure it's on top and giving it key focus [17:30] so, if the surface instead takes the focused attribute itself during creation [17:31] then what actually [17:31] does this giving key focus, etc step. [17:34] racarr, don't know where that question ended :) [17:34] err, sorry [17:34] I mean which component, or hwere in this flow [17:34] do we actually set the key focus [17:35] because there is no [17:35] been reading through a bit of the code more [17:35] msh::FocusSetter::set_focus_to(msh::Surface) now [17:35] as the only entry point for focus changing [17:35] (when I say now, I mean, in this select_attribute_value model) [17:35] and really, i think in msh::SessionManager::create_surface_for, it calling set_focus_to is probably in the wrong place [17:36] my head's currently exploding with 'hey, a std::future seems perfect for this sort of thing' :) [17:36] but [17:37] mm [17:37] the call to set_focus_to is wrong I agree [17:37] that should be entirely shell policy it's just there so we could have focus before we had a shell or example servers [17:37] a notification after SessionMediator::create_surface's done->Run() to the focus setter seems appropriate sorta [17:38] I was thinking about that, or even right before i.e. say [17:38] with the idea, 'hey Focus stuff, time to reconsider who has focus' [17:38] SessionManager::create_surface_for(... [17:38] surface = create_surface() [17:38] and then like [17:38] apply_surface_attributes(surface) [17:39] then it returns to the SessionMediator (not sure it needs to happen after done->Run()) [17:39] but, what does this function apply_surface_attributes look like? I mean it's not an interface because it's just...do_stuff(surface) [17:39] might not be, just musing a bit [17:39] and is it supposed to be written like [17:40] switch (surface_state): case maximized: unity_maximize_surface(), .... swtich(surface_focused): case focused... [17:40] etc... [17:44] kdub: Yes. thanks for the musings :) this is helpful [17:47] racarr, no problem :) [17:48] kdub: The CloggableEventSink solves another problem too [17:49] which is, say we have sorted out this focus stuff by setting it as part of construction, or even without client-focus-notifications [17:49] So, the SessionMediator invokes create_surface, then before calling done->Run() [17:49] the thread yields [17:50] right, and then the shell changes focus [17:50] in the time period, or something [17:50] yeah or maximizes the surface or whatever [17:50] EventSink, primarily, is not an interface which has any synchronization guarantees, its purpose is to send messages [17:51] i think a richer synchronization [17:51] even 'client ready for events' on msh::Surface, that is invoked after done->Run makes a bit more sense [17:51] I think the CloggableEventSink keeps it that way though, it's still not providing any synchronization guarantees to the msh::Surface, it's just sending messages [17:52] it's only the SessionMediator that knows about the synchronization [17:52] but hmm, yeah [17:52] right, so why not synchronize between SessionMediator and SessionManager then [17:52] instead of synchronizing between SessionMediator and EventSink, so that SessionManager can sync with Event sink too later :) [17:53] hmm, how [17:54] I guess I see two ideas, one could be maybe msh::Surface contains some attribute [17:54] client_ready_for_events [17:55]