[01:55] RAOF, are you adding that .symbols file to libmirclient? If too busy, I can do it [01:55] robert_ancell: Yeah, I am in the background. [01:56] Turns out that it's a little bit more complicated, because we accidentally export about 100KB worth of C++ symbols too. [01:56] RAOF, time for symbol filter.. [01:57] Time for -fvisibility=hidden. [01:57] It should also significantly reduce our startup time. [01:57] nice [01:58] RAOF, in the background? [01:58] It builds while I do other things :) [01:59] k [02:01] RAOF: That's the fun part about C++ symbols. Often their name lengths far exceed their code size :) === kode54 is now known as kode55 === kode55 is now known as kode54 [03:02] Is 60 degrees at idle good? :P [03:19] RAOF, those SNA changes you made - are they on https://github.com/RAOF/xserver? [03:20] robert_ancell: No, they're on lp:~raof/mir/xf86-video-intel-vladmir [03:20] RAOF, aha [03:20] Because Intel is too cool to use an acceleration architecture that lives in the xserver tree :) [03:22] RAOF, that branch doesn't seem to exist [03:22] is it private? [03:22] Shouldn't be? [03:22] Ah, sorry. [03:22] oh ~mir-team? [03:22] lp:~mir-team/mir/xf86-video-intel-vladmir [03:23] I just read our own documentation :) [03:23] :P [03:25] RAOF, btw, is there a reason why it isn't lp:~mir-team/xserver-xorg-video-intel/vladmir? [03:25] Not really. Does that project exist, though?+ [03:26] RAOF, yes [03:26] and lp:~mir-team/nouveau/vladmir [03:26] Then the answer is probably “because at one point that branch was private” [03:26] I thought so [03:26] and lp:~mir-team/xserver-xorg-driver-ati/vladmir [03:27] for bonus inconsistency in source package naming [03:27] upstream naming rather [03:27] Well, none of those projects have the actual upstream name :) [03:27] Upstream they're xf86-video-{ati,intel,nouveau} [03:27] RAOF, yeah, sad eh? [03:28] Would you prefer it if the canonical repositories were under the various projects? [03:28] RAOF, well, look. You registered nouveau :) [03:28] I can't remember why :) [03:29] RAOF, it confuses me slightly, but it doesn't really matter [03:33] Am I imagining things, but did saucy's power usage drop significantly when it moved to 3.10? [03:33] -but +or [03:35] Oh, that actually wasn't recent [05:29] RAOF, ping [05:29] tvoss: Pong [05:53] * duflu does the no-more-deadlocks dance [06:18] * RAOF goes to get milk [07:14] hi :) [07:15] question: I wonder how could I check in which platform mir runs (to see for example which type of buffers I will need) without using ifdef [07:16] hikiko: Not sure. But I have been wondering much the same. I would say it should be a function of the platform to produce (factory) its own buffers. This would eventually be owned by a "graphics driver" which would take over platform roles [07:18] good morning [07:18] Morning dholbach [07:19] duflu, you mean a factory in each native platform isn't it? and the nested one will just use it? [07:20] I mean: buffer interface that is implemented by android and gbm separately [07:20] hikiko: I think I mean the "platform" should be a portable interface to operate on the interfaces to platform-specific objects, like buffers [07:20] Yes [07:20] But that's just what I think. Not necessarily how it works now [07:21] :) it doesn't sound a bad idea :) [07:21] I'll try it! [07:21] hikiko: There's also mir_surface_get_platform_type [07:21] yes [07:21] but to use this [07:22] I need to have a client platform isn't it? [07:22] hikiko: I guess the first question is why do you need to explicitly know on which platform you on. [07:22] hi duflu [07:22] +i saw at tests/unit-tests/client/test_client_platform.cpp that we use ifdef to call it [07:23] alf_, yes I do because I will use native buffers [07:23] alf_: That's my point. There should be a (portable) interface always available to give you what you want. If not already at lower-level classes then at least implemented per platform [07:24] hikiko: where/how are you going to use native buffers? [07:24] hikiko: (I am trying to understand your scenario better) [07:26] hmm... I needed gbm in my last branch because nested mir was a different platform [07:26] but I see what you mean [07:26] maybe this time (runtime) I won't need to do anything === alan_g is now known as alan_g|afk [07:27] since I will create both a native platform (- initializes gbm, drm creates devices etc) and the nested one [07:28] ok, I ll check if I need it first :> [07:30] (thanks all) [07:43] New laptop should be shipping soon... shipping sooooooon! [07:43] RAOF, \o/ [07:43] or will it?! dun dun duun [07:44] RAOF, disabling semaphores seems to work [07:44] Yay for year-old i915 bugs! [07:45] RAOF, but it means a degradation in terms of throughput and morre cpu load [08:11] Man, why don't we just default to clang everywhere? [08:13] because clang doesn't compile a linux kernel === didrocks1 is now known as didrocks === alan_g|afk is now known as alan_g [08:40] alan_g: The scenegraph is probably the proper way to handle a lot surface properties. However, unless we make it a priority, we will just continue to scatter more surface bits and pieces around the code base... Not sure how it ties with our current xmir and mobile priorities. [08:41] alf_: I was just discussing that with tvoss [08:41] alf_, alan_g seems like we should have a discussion about that topic with the team [08:44] alf_: tvoss: quick hangout to discuss how we schedule this discussion? [08:44] alan_g, on another call right now [08:45] np later today? [08:46] alan_g, sure [09:00] I would have imagined only the shell would have a scene graph. I don't understand why you would have one accessible inside libmirserver... ? [09:01] We need something approximating a scenegraph to actually draw, though. [09:02] Yes, but what gets drawn in what order is all up to the shell. I guess the server code hasn't quite reached that level of clarity yet [09:02] ... so some of it is scattered around the server [09:02] duflu, largely due to us not having a scenegraph in place [09:03] tvoss: Yes, I guess. Just saying it should eventually live in the shell only. Not Mir [09:03] duflu, but Mir at least needs to know how to talk to it, with the shell being able to inject the actual implementation [09:04] tvoss: Most of it... no. If we aspire to the shell "being" the compositor, then any properties that affect composition would be stored in the shell's scene graph [09:04] Mir needs to be able to query the scenegraph without trips into javascript [09:04] What? Javascript? Where? [09:05] duflu, the shell [09:05] duflu, is written in QML [09:05] Oh. Right. That's sillyness on behalf of the shell [09:05] Hmm [09:05] duflu, at a future point we want the shell to do the actual compositing [09:06] duflu, however, right now, that's not the case and we need to make that we do not scatter functionality across the system that would better fit into a consistent scenegraph model [09:06] if that moves to the shell over time, awesome [09:08] duflu, not entirely sure why you think that doing the shell is in qml, though [09:09] tvoss: At least part of the Unity8 shell is C++ already though. We don't have to wait for the distant future to put shell things in the shell [09:10] duflu, fair, but I'm not confident that we have the resources available right now to implement the actual compositing in the unity-mir glue layer [09:10] duflu, from my pov, having a concept of a scenegraph hammered down helps us in the short and in the long term [09:11] tvoss: Is it just like shell-specific surface properties we need storage for? [09:12] duflu, nope, it's really a bigger problem we need to solve as the current (very naive) surface stack is not capable of holding the information and providing the operations we really want [09:12] tvoss: That's my concern. The assumption that the scene graph is a stack is a very bad assumption. That's an implementation detail that is shell-specific [09:13] I fear hard-coding more inflexible assumptions into the server [09:13] duflu, a stack is only the final view assembled from the scenegraph, in that I do agree [09:13] duflu: that's the problem we're trying to solve [09:14] tvoss, alan_g: Alright. I guess part of the generalization will involve rejigging the "stack" as used in input too [09:15] duflu, yup [09:15] Since it's not always a stack [09:15] ack [09:15] Unfortunately a few of us did point this out before that code landed [09:15] But at least we have something working I guess [09:15] duflu, and I think there were compelling reasons to land it nevertheless, iirc for bootstrapping purposes [09:16] Yep [09:17] I think I just talked myself into having a general scene graph interface in the server [09:17] Good idea [09:17] We already discussed that we'd be here, doing this, in Oakland - it isn't a surprise [09:22] Ok. Let's see if swapbuffers+bypass works... [09:22] RAOF: I hope you're not talking about my branch. Still working on it [09:23] Though I did get over the deadlock today... and now find a theoretical reason why it should not work as well as it is... [09:24] No, I'm talking about the XMir side - having SwapBuffers actually wait to swap the buffers, and handing out the Mir buffer to fullscreen GLX clients. [09:25] RAOF: Oh, so XMir is now a regular client? [09:26] No? [09:26] Well, yes, but it doesn't use EGL. [09:26] RAOF: Nevermind. Resolving the confusion I have right now is not required. Happy hacking [09:30] Eh, it's building. [09:30] I've got time to resolve confusion if you like :) [09:41] RAOF: still around? do you mind listing me the binary packages I should install from xmir and mesa? [09:41] didrocks: Sure, after I have collected pizza! [09:41] :) [09:41] thanks! [10:04] * tvoss does not like gmail telling me that I have 666 unread mails [10:06] tvoss: it would be even more interesting/disturbing if it automatically redirected you to https://www.youtube.com/watch?v=jsmcDLDw9iw :) [10:10] alf_: And even more so for https://www.youtube.com/watch?v=2EdWwEMSyuY [10:11] duflu: :) [10:17] didrocks: [10:18] RAOF: wrong copy/paste? :p [10:18] didrocks: Yo! Do you need all the binaries, or can I assume the apt resolver is in effect? [10:19] RAOF: no, it's whitelisting, so we need all the binary packages we need to install [10:20] RAOF: to prevent uncontrolled transitions :) [10:20] Ok. [10:21] So what we want is the list of all the binary packages built by the relevant source packages, right? [10:23] didrocks: That's a *big* list. [10:23] RAOF: all the binary packages from xmir and mesa that we need to install by default, yep :) [10:23] Ah, just the ones that need to be installed by default? [10:24] RAOF: right, the one we need and are tested :) [10:24] as we are running the unity tests, I think all xmir/mesa is involved at some point (with the patches for xmir/mir) [10:25] RAOF: my list right now is: unity-system-compositor libmirprotobuf0 libmirserver0 libmirclient1 lightdm liblightdm-gobject-1-0 unity-greeter [10:25] libegl1-mesa [10:27] this is quite short for a long list :p [10:27] libegl1-mesa-drivers libgbm1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libgles2-mesa xserver-common xserver-xorg-core [10:28] xserver-xorg-video-ati xserver-xorg-video-radeon xserver-xorg-video-intel xserver-xorg-video-nouveau [10:28] RAOF: sounds like reasonable, adding them! [10:29] RAOF: thanks! will try that soon :) === sil2100_ is now known as sil2100 [11:01] * RAOF is confused. How does xf86-video-intel load, when it *should* be trying to resolve symbols that don't exist in xmir? [11:02] RAOF: they're marked "load on use?" [11:03] They *should* be used. === greyback is now known as greyback|food [11:03] * alan_g gives up - ask the link loader where it resolves them [11:04] LD_DEBUG= to the rescue! [11:24] * alan_g finds his brain can't focus on any more MP reviews [11:29] RAOF: seems you forgot libegl1-mesa :) I'm adding it === alan_g is now known as alan_g|lunch === greyback|food is now known as greyback [12:48] alan_g|lunch: what do you think about ViewableArea::view_area() -> DisplayGeometry::geometry() or DisplayLayout::layout() [12:49] alan_g|lunch: that is "geom::Rectangles DisplayGeometry::geometry()" === alan_g|lunch is now known as alan_g [12:53] alf_: I don't think "geometry()" tells anyone what it does [12:53] alan_g: get() ? [12:54] alan_g: get_current_geometry()? [12:54] visible_region() [12:54] alan_g: or are you referring to the term geometry itself? [12:55] I think the word is too generic [13:03] layout() is a bit better, but to me would imply that it includes information about which outputs are where [13:03] alan_g: alf_ ...just my 2 cents +1 on visible_region vs geom....or you could even say region_to_be_displayed [13:14] alan_g: kgunn: I think we need to take a step back with this + "tell don't ask"... I am looking at the code that uses ViewableArea and I think the interface we need is actually something like DisplayRegionBoundaries::place_point(p) and ::place_rect(r), i.e. find the closest position of point or rect so that they are within Display boundaries [13:14] alf_: I was wondering about that approach [13:15] alan_g: SessionMediator is one exception to this, but it needs DisplayConfiguration (not just a collection of rectangles) anyway [13:16] alan_g: so it doesn't really count, the other is the ability to make something fullscreen, like msh::ConsumingPlacementStrategy does, but we can "tell" our object to do that too [13:18] alan_g: however, I don't know if there are future needs that will make the whole approach too restrictive and we would be better off just giving out all the information anyway... [13:19] alf_: IME giving out all the information introduces unnecessary coupling [13:22] Can we make something line void DisplayGeometry::change_to_fullscreen(blah&) work now? [13:23] alan_g: (assuming blah==Rectangle) yes [13:23] alf_: I didn't know it would be SomeSurfaceInfoHolder ;) [13:24] *if it [13:33] alan_g: I will go with this approach, i.e., DisplayBoundaries::bound_point() ::bound_rect() ::make_fullscreen() (and perhaps also ::fit_rect() which resizes the rectangle to fit instead of moving it to be within bounds, but I will check what the current consumers need) [13:34] alan_g: (names are tentative, I am open to suggestions) [13:37] alf_: is "bound" a term of art here? "To bound" can be "to bounce" [13:38] restrict_point(Point&) et alia? [13:38] alan_g: I used it as: verb (used with object) [13:38] 5. [13:38] to limit by or as if by bounds; keep within limits or confines. [13:40] confine_point() sounds good [13:40] alan_g: agreed [13:41] fit_rect() => clip(Rectangle&)? [13:42] alan_g: Yes, much better! [13:57] alan_g: The other point is that it seems fitting to have a mi::InputBoundaries and a msh::SurfaceBoundaries interface, implemented by an mg::DisplayBoundaries concrete class [14:00] alf_: is there an OutputBoundaries lurking sonewhere? [14:04] alan_g: (assuming OutputBoundaries is for a single screen/output), conceptually it could be there, but I don't see a consumer for it at this point. It's the same as the DisplayBuffer/ViewableArea case we discussed last week. [14:05] alf_: ack - it just seemed symmetric [14:12] tvoss, robotfuel has some results to look at, have a min to spare [14:13] * alf_ really needs to create a vim snippet/template for an abstract base class [14:13] olli_, sure [14:14] * alf_ decides that there is no better time than right now to do it... [14:37] kgunn: can you clear something up for me? Does XMir require xorg drivers for the hardware it'll run on, or does it only need Mir drivers for the hardware it will run on? === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [14:57] mhall119: yes :) [14:58] remember xmir is still the x stack....with x apps rendering into backbuffers....then the sys-compositor takes those as inputs rendered out into the frontbuffer [14:58] kgunn: "yes" doesn't work for an "A or B?" question :P [15:00] kgunn: right, but if I'm running XMir on, say, a Tegra shipset, does it need Tegra XOrg drivers, or just a Tegra Mir system-compositor driver? [15:01] mhall119, right now it still needs Xorg drivers [15:02] ok [15:02] mhall119: tegra ? [15:02] nVidia's mobile SoC [15:02] right [15:02] just questioning whether or not there are xorg drivers for that === pete-woods2 is now known as pete-woods [15:03] might be android drivers [15:03] :) [15:03] there are android drivers, yes [15:03] so if there are Android drivers, but not Xorg drivers, then we can't run XMir on it? [15:03] mhall119: right... [15:04] why is that? I thought XMir would abstract the specific hardware from Xorg [15:04] that was what i was getting at questioning your mix of tegra w x [15:04] Morning [15:04] kgunn: I'm discussing XMir with someone on G+, just want to have my facts straight [15:05] greyback: Was reading your email at the coffee shop ,didn't entirely process yet [15:05] but maybe this is the case for the [15:05] EventFilter [15:05] ? [15:05] mhall119: well...think of it this way....xmir/u-s-c is sort of rerouting what the x stack thinks is going into a fb....into a input buffer of the compositor [15:05] the x stack itself is still using gl drivers for the app renderings [15:05] racarr: could be. I'd like some guidance please [15:06] mhall119: ....to answer your question tho, xmir & android are mutually exclusive topics [15:06] greyback: Thats my theory let me catch up on email and give it a solid read [15:06] if you install an event_filter via server configuration [15:06] it gets all events, and ut returns true/false from a callback [15:06] to handle [15:07] kgunn: hmmm, so apps get a buffer from XMir, but then use the hardware-specific Xorg driver to draw into that buffer? [15:07] mhall119: yes [15:08] ok, I think I understand now [15:08] racarr: okay. And I can direct all those events to a surface of my choice? [15:08] kgunn: so XMir doesn't provide the GL drawing methods in a hardware-abstracted way? [15:09] mhall119: well...i guess that is where i get nit-picky [15:09] the drawing methods are provided by opengles [15:09] greyback: No hmm, this is just like you can consume them [15:10] drivers are specific against the soc (cpu & gpu) [15:10] or let them go to first surface [15:10] they would have otherwise gotten to [15:10] I can add some sort of targetting filter [15:10] there are some hooks in android [15:13] racarr: you see what I need though? Do let me know what I need to do. [15:14] mhall119: make sense ? [15:14] greyback: I don't yet but I'm sure I will by 830 XD [15:14] racarr: no prob. Thanks! [15:15] kgunn: not entirely, but that's probably my fault :) [15:15] mhall119: no, keep poking until we get there [15:17] kgunn: so is XMir a non-hardware-specific-hardware-driver like vesa, or is it just a frame-buffer-provider that still need an accompanying hardware-specific-harware-driver? [15:18] pardon the gratuitous use of hyphens [15:18] mhall119: :) [15:19] mhall119: As I understand it it' a new 'DIX' i.e. Device Independent X, plu changes to the hardware specific drivers (very small basically just replacing one buffer allocation function) [15:20] mhall119: right ^ [15:21] mhall119: one thing i might have left out...compiz is still there [15:21] so you are still fully composing all the windows in x....so when it hits the u-s-c, its just 1 frame [15:21] duflu: smspillaz: compiz4ever [15:21] greyback: I'm awake now XD [15:22] so my current stack is Intel GPU -> intel Xorg driver -> Xorg Xserver [15:22] ...when i say 1 frame, i mean 1 composed view... [15:22] if I start using XMir, where will it fit into that stack? [15:22] greyback: I think, conceptually the EventFilter is what we want [15:22] greyback: The only difficulty with the EventFilter is getting the events in to Qt... [15:22] mhall119, xorg == xmir -> usc [15:23] mhall119: i think maybe the bit that escapes a lot of people....even tho you say "gpu/xorg driver".... [15:23] there are multiple clients here [15:23] the app (maybe), compiz & usc/mir [15:25] greyback: Basically I see two approaches but don't understand how to fit them both with Qt, so you should help :) um [15:26] tvoss: not sure what you meant by that [15:26] ok so possibility 1 is you install an mi::EventFilter. [15:26] it always gets all events, so you recognize the gestures there, and just chop out the events you want [15:26] mhall119: xmir is xorg with a patch on top [15:26] this can be extended over time, to support reinjecting/targeting events etc [15:26] that racarr described in scrollback [15:27] though I'm not sure anything is needed for the simpel gestures (only foro ptimization later like the cancellation stuff) [15:27] kgunn: ok, so it's not just a driver for Xorg, it's a whole modified server? [15:27] can also be easily extended with like: [15:27] mhall119, for the 13.10 stack it is the following flow of rendering: x app -> xorg(which is xmir) -> usc (which is a minimal shell on top of Mir) -> screen [15:27] filter_event_beore_dispatching_to(target, event) [15:27] mhall119: sort of....(you make it sound ominous, when its not :) [15:27] mhall119: so yeah... [15:27] greyback: The problem here, is Event is a MirEvent passed [15:27] mhall119, it's a minimally patched Xserver exposing hooks to the x drivers to be able to render to Mir buffers [15:27] to this callback [15:27] on the C++ side [15:28] and I am not sure what you can do with that [15:28] maybe you can use some QPA functions [15:28] to inject it somewhere [15:28] mhall119: what tvoss said....which is what i meant by "rerouting" x compiz output to mir input buffers instead of the fb [15:29] plubming [15:29] ok, so we modify each of the Xorg drivers too, I didn't realize that [15:29] mhall119, the links to the modified drivers are here: http://unity.ubuntu.com/mir/building_source_for_pc.html [15:30] thanks, I think that was the part I was missing [15:30] greyback: The other bit is we cn add support for creating windows with 'monitor' channels [15:31] so you can create an invisible window that always gets all events [15:31] and get things in to Qt that way [15:31] kind o ugly but works I uppose [15:31] and how the input setup works on SF afaict [15:32] racarr, I would vote against having this input trap setup [15:32] tvoss: Me too XD [15:33] the event filter way, or some variant down that lines is the only scalable way [15:33] as opposed to using the [15:33] client input delivery mechanism [15:33] because eventually to do better/fater gesture recognition [15:33] the shell might want to replay events, or do that event cancellation stuff we talked about, etc. === tvoss is now known as tvoss|dinner [16:00] alan_g, updated surface-owns-render-info to separate size_and_position() [16:00] * alan_g finds his brain can't focus on any more MP reviews [16:05] ok :) [16:06] i guess technically its able to be top-approved, anyone else want to take a look? [16:14] alan_g: alf_: Want to avoid another day of iteration, but having a little trouble with client-focus-notifications [16:14] What is reasonable behavior for ~Clog? [16:14] unclog shouldn't throw? or ~Clog should...catch it and abort? [16:14] assert on failure [16:14] should ust clog/unclog assert [16:14] directly? [16:15] first thought was just have the dtors assert [16:16] racarr: It is a precondition failure to unclog when not clogged so asserting seems right to me [16:17] ok [16:18] I am never really sure when to assert ;) [16:18] my style used to be to assert everything I thought was assertable [16:18] but that tends to lead to trouble so now I never use it [16:19] alan_g: racarr: We had some dicussion before, but I don't remember if we reached a conclusion about using C assert() (=assert_if_not_ndebug()) vs a new assert (=always assert) function. Does anyone remember? [16:23] style assert is fine for a precondition failure - as detecting the problem isn't a post-condition [16:24] Speaking of assert... [16:24] has anyone ever looked in to the problem of [16:24] restarting mir without killing clients? [16:25] Not to my knowledge [16:27] Lets do that and then assert everything ;) [16:27] hmm. I wonder how large of a chunk of work that would be/if its interesting now === dholbach_ is now known as dholbach === Debolaz is now known as Guest70312 === alan_g is now known as alan_g|EOD [17:40] alf_: Hey. I am thinking of tackling [17:41] ...omg copy paste doesn't work anymore [17:41] https://bugs.launchpad.net/mir/+bug/1193222 [17:41] Launchpad bug 1193222 in XMir "Screen never sleeps; missing power management" [Critical,Triaged] [17:41] and just wanted to make sure you hadn't started on the assosciated GBM platform changes or [17:41] well see if you had any thoughts :) === ricmm is now known as ricmm||lunch [18:11] racarr, wasn't there some plan for power management external to mir or something? [18:12] kdub: Well, yes this is interesting :p on converged/the phone [18:13] the pln is just mir needs to expose methods out of the graphics platform [18:13] and unity provides [18:13] some DBus API [18:13] or some such [18:13] but...xmir needs to be able to request display on/off [18:14] but i'd imagine it would make that request to different places [18:14] and well...I dunno if we want to hook xmir up to USC via DBus...so it seems to make more sense to have it in the client API [18:14] what do you mean? [18:14] specifically, pause mir [18:14] turn screen brightness off somewhere else [18:15] or at least I thought that was the plan :) [18:15] there is more [18:15] than screen brightness [18:15] there is backlight control [18:15] sure [18:15] but then also setting the zero mode [18:15] on the CRTC [18:15] 'turns it off' [18:15] that is the pause mir step I guess [18:15] right, i was being vague :) [18:15] because if there is no CRTC everything grinds to a halt until pages start flipping again [18:16] mm [18:16] I do nt think everything actually grinds to a halt now [18:16] racarr, swapinterval 0 clients would keep going [18:16] but it will ;) [18:16] yeah [18:18] i get confused when new feature requests are made via bugs :-/ [18:18] "Screen fails to sleep" [18:18] is a bug version XD [18:18] I wonder if xmir clients are [18:18] prepared for the aggressive kind of [18:19] power management we want to do [18:19] "mir won't fit on a 3.5 floppy" [18:19] i.e. I am using my X11 music player, the screensaver comes on, display goes off, we pause mir [18:19] is my [18:19] silly ingle threaded X11 music player going to [18:19] start blocking? [18:20] on some X calls [18:20] and will it still keep playing music if so [18:21] racarr, i'd guess that that's parallelized in X clients too [18:22] my... [18:22] thought is that it isnt :p [18:22] but I am not sure if pausing mir actually makes anything block for X clients [18:22] yeah, thikning back to past experiences... [18:22] * kdub doesn't know [18:23] I'm almost certain most GTK apps wouldn't respond well [18:23] to some X/GL calls just blocking forever [18:23] *shrugs* [18:23] *adds to list of things to harass RAOF about* === ricmm||lunch is now known as ricmm [19:02] Lunch === racarr is now known as racarr|lunch === racarr|lunch is now known as racrr [19:52] RAOF: Ping? [19:55] racrr, you are missing an a === racrr is now known as racarr [19:57] tvoss|dinner: I tried to fit that statement to about 10 scenarios [19:57] before realizing what you meant XD [19:58] ;) === thomi_ is now known as thomi [20:13] hi guys! will XMir work on VirtualBox? [20:13] as accelerated, not sw rendering. [20:16] Wellark: This isn't a support channel. Go away! [20:17]