[00:03] RAOF: maybe. Unity has binary deps on lots of other things though, so you often can't release libdee (for example), unless you release the rest of the stack at the same time [00:03] Oh, that totally makes sense. [01:48] RAOF, do you know who I can talk to about lightdm still being in proposed? The one in main has a serious bug [01:49] robert_ancell: Probably most people in #ubuntu-release? [01:49] RAOF, ta [01:49] I'd expect a random archive admin to know. [01:52] RAOF: oh btw can lts-raring and mesa in raring be promoted to -updates? :P [02:12] robert_ancell: Could you do me a favour? [02:13] duflu, sure [02:13] robert_ancell: Change the "development focus" to 0.9.11 on https://launchpad.net/compiz [02:13] ? [02:13] duflu, done [02:14] robert_ancell: Thanks [02:17] mlankhorst: that was extra annoying, finding out it was in -proposed after recommending it to people instead of edgers :) [02:18] mlankhorst: but infinity was talking about making daily builds work so "any day now" [04:32] RAOF, hey [04:32] olli: Yo! [04:32] just wanted to say thanks for proposing all the patches over the weekend [04:32] :) [04:33] seems like the intel one got the most traction so far [04:34] Well, the most reaction at least :) [04:37] RAOF, true [04:38] so, it seems like we have missed all major upstream releases (at least Mesa and X iirc) [04:38] not sure if "missed" is the right term [04:39] * duflu wanders off to lunch [04:39] enjoy duflu [04:39] RAOF, how will we ship these in 13.10 then? [04:39] By patching? [04:39] Same way we did XI2-multitouch? [04:41] heh, the amount of "?" indicates I was asking a stupid question ;) [04:41] will you have to maintain 2 versions of the patches then, one for Mesa/X/... at 13.10 and one for the respective latest version [04:41] will that be a big delta, if at all? [04:48] Depends on how things change underneath. [04:49] The patch as-of 13.10 though probably won't need _too_ much support that isn't simple backporting. [05:22] RAOF, ping [05:22] tvoss: Yo. [05:22] RAOF, good morning :) got some time in your voip lair? [05:22] Sure. [05:23] My new, improved, VoIP lair! [05:25] RAOF, \o/ let me grab coffee [05:27] RAOF, can you open a hangout and add me to it, would like to join on the ipad [05:43] kgunn: just to reash, I'm not thrilled to drop 50% of our testing, and just having one machine with "a workaround" to get Mir starting [05:43] rehash [05:44] RAOF: hey, you confirm that the ati issue isn't due to lxc, but a real issue, right? [05:45] didrocks: Yeah, looked like it. [05:45] RAOF: if you need access to the machine, we can provide you that [05:46] * didrocks is seeing that we diminish more and more on Mir quality side "just" to ship in universe [06:49] didrocks, how many machines can we provision in the lab to start mir? [06:50] tvoss_: 2 right now [06:50] didrocks, why not more? it is my understanding that we have 2 ati, 2 intel and 2 nvidia machines [06:50] tvoss_: we have that since yesterday [06:50] didrocks, what gpu is running in the two machines? [06:50] tvoss_: we just need to provision the nvidia [06:50] one intel, one ati [06:51] tvoss_: the 3 others are for raring [06:51] didrocks, why do we need them for raring? [06:51] tvoss_: because we support our users? [06:51] so we do have SRUs everyday [06:51] didrocks, sure, but I thought we could just reprovision them with a different Ubuntu version? [06:51] tvoss_: no, we need kernel == container [06:52] tvoss_: the machines are the same anyway, between the ati, intel and nvidia FYI [06:52] didrocks, okay, I was told some time back that we have he/le ati, he/le nvidia, he/le intel [06:52] maybe you are not mentionning the same machines then [06:52] because the 3 others arrived this week [06:53] and we only have 3 until then [06:53] didrocks, that might well be [06:53] didrocks, so which machine is causing issues? the ati one? [06:53] yep [06:53] didrocks, intel and nvidia come up cleanly? [06:53] tvoss_: well, nvidia is on raring (one of the 3 we had) [06:53] we need to wire up the other one [06:53] on intel, it was failing as well [06:53] and we needed my workaround [06:53] the sleep :/ [06:54] I got a "we never see it" [06:54] then, when I gave the description, starting to see devs telling they saw it [06:54] and "just" reboot :/ [06:54] we need to change that behavior [06:54] didrocks, as far as I know we do not see those issues in the cert lab [06:55] tvoss_: so, we are inventing the issues? [06:55] "not seen here" -> then, when opening "oh btw, I saw it some times" [06:55] regular rules [06:55] didrocks, of course not, I'm just trying to track down the issue [06:55] didrocks, can I get access to the ati machine? [06:56] tvoss_: see the bug report, RAOF already dived to it [06:56] tvoss_: yeah, once daily are finished, I can give you access [06:56] didrocks, ack, can you paste the bugreport again? [06:56] didrocks, my backlog is a bit fucked up after numerous reboots [06:56] tvoss_: bug #1203070 [06:56] bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] https://launchpad.net/bugs/1203070 [06:57] Chris told: "it's failed to create the hw cursor buffer, and I don't believe that there are any more relevant logs [06:57] available." [07:00] mlankhorst, ping [07:04] pong! [07:08] mlankhorst, hey there :) we are trying to solve an issue with Mir failing to create a hardware cursor buffer on ati. [07:08] mlankhorst, I wonder if you are aware of any known ati issue in that area? [07:09] erm cursor usually has special requirements for buffer [07:30] mlankhorst, okay, the call succeeds in general, we only have an issue on one specific card. Is there any way to get something like a last error from gbm? [07:31] use the debugger(TM) [07:32] mlankhorst, woot, thanks for the enlightenment ;) [07:32] it's what it's for :P [08:05] alf__: How do you guarantee that only one compositor buffer is consumed per 16ms in the multimonitor stuff? Is it still partial releases? [08:07] ... or yet to be figured out? [08:09] duflu: there is no guarantee for that atm [08:10] alf__: OK, I thought I might be too early. When you have an idea, please let me know [08:10] duflu: hmm, sorry, there is a partial guarantee [08:11] alf__: Saved resources? [08:13] alf__: I would suggest enforcing that compositor_acquire only happens for real on one monitor (which must also have the highest refresh rate of all monitors) [08:13] Probably #0. And recycle till that monitor refreshes again [08:15] duflu: about partial release... essentially the first release of a buffer marks its end as a preferred buffer for next acquisitions. Since under normal operation this happens once per ~16ms, the consumed once per 16ms is enforced. [08:15] duflu: (more or less) [08:15] alf__: I know but that won't be true under bypass, so I'm hunting for a more robust guarantee [08:16] Under bypass, two compositors are held and one consumed, per 16ms [08:19] duflu: Couldn't we just have a differently constructed BufferStream for bypass, that doesn't enforce the MultiAcquisition policies? [08:21] alf__: Yes. However I suspect that will cause the client to get buffers at Nmonitors*60Hz [08:21] Which is fine for me with one monitor right now. Not fine for working with multimonitor [08:23] Dear POSIX: signals are hateful, and [08:23] I hate you. [08:24] hi [08:24] question [08:25] alf__... So before it becomes a problem I would like to see some more explicit distinction between buffer recycling and guaranteed buffer advancement [08:25] duflu: I haven't really thought about this yet, but perhaps using a combination of a different back buffer strategy in BufferStream plus a different CompositingStrategy (note, renamed to DisplayBufferCompositor in proposed MP), which we need anyway, perhaps we could reach the needed behavior. Hopefully we won't need to have a single behavior that works for both normal and bypass, if that means making compromises for both. [08:25] alf__, I tried to use the mir buffers as you said but I am not sure if you can fill the ipc package using those buffers [08:28] hikiko: what method are you referring to? [08:28] fill_ipc_package in platform alf__ [08:29] hikiko: well, the plan is to relay this request to the native platform to do this for you [08:32] Who thought that having read() able to return EINTR at any point and *partially* consume the buffer was a good idea? >:( [08:32] RAOF: Before threads were invented/common... [08:33] Though arguably, retrying I/O is less error prone than expecting programmers to do threads reliably [08:33] And who didn't want to make libc go to the effort to *not* consume the buffer in that case? [08:33] Yeah, but you can't retry IO. You need to keep track of how much was actually read, and then try to read the rest. [08:34] Because *that's* totally not going to be done badly, and couldn't be sensibly implemented in the goddamned system library. [08:34] I don't create a native and a nested platform at the same time alf__ either native or nested [08:38] Not that this is *necessarily* the cause of output delay, just that I hate noticing things that are going to explode when a SIGIO comes in at an inopportune time. [08:38] hikiko: the nested platform should create and use an instance of a specially configured native platform, see second paragraph of mir-on-mir mir-devel email reply [08:39] ok [08:40] I forgot to re-add this :p [08:40] sorry :) [08:40] Current Ubuntu Phone images uses Mir directly? [08:44] RAOF: sigh [08:44] I'm getting reports about mir now.. [08:44] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1201028 [08:44] Launchpad bug 1201028 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in raise()" [Undecided,New] [08:45] mlankhorst: I don't know what you're talking about officer. Mir couldn't cause *any* problems at all. See, we've corraled him in a PPA where he's kept safe from the masses! [08:46] the bugs get filed against xorg-server though, what should I do with them? [08:47] I just want them not be against xorg-server for now, i don't care if I close it as invalid or reassign to mir :P [08:47] That's odd. There should be no automatic reports when users (like that one) are using a PPA [08:48] mlankhorst: Feel to reassign to the xmir project. duflu set that one up :) [08:49] link? [08:49] * duflu assigned it [08:49] mlankhorst: Launchpad project "xmir" [08:49] https://bugs.launchpad.net/ubuntu/+source/xorg-server?field.searchtext=mir&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= [08:51] but I'll reassign all then [08:54] Oh, I was reassigning. But OK [09:02] deathcrawler: not yet (it still uses surfaceflinger) but we are getting close to switching === jono is now known as Guest19501 [09:20] RAOF, disabling sigio event reporting in X is great, works fine here ;) [09:47] alf__: Thanks [10:42] Oh dear. My diff is now over 4kloc to trunk. This is a worry [10:57] tvoss_: Oh, disabling sigio events avoids the bug? [10:57] RAOF, nope [12:17] didrocks, alf__ https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 [12:18] tvoss_: looking [12:27] tvoss_: what does the waitpid (pid, NULL, 0) call do after PTRACE_ATTACH? [12:28] alf__, it waits for the child process to be stopped as a result to the parent attaching. that should help us avoid a lot of races [12:33] LOL [12:33] http://www.indiegogo.com/projects/support-ubuntu-edge-enthusiast [12:33] awesome [12:34] oops, i'm not in -touch, sorry [12:34] ogra_, still great :) [12:36] tvoss_: is this because of WUNTRACED also return if a child has stopped (but not traced via ptrace(2)). Status for [12:36] traced children which have stopped is provided even if this option is not speci‐ [12:36] fied. [12:37] alf__, yes, partly and PTRACE_ATTACH really is what we want to do here [12:40] tvoss_: I guess my question is what guarantees that we have that waitpid(..., 0) is notified about the stopped child (normally waitpid() only gets termination events). [12:41] alf__, that's the usual flow of ptrace_attach and then waitpid [12:42] tvoss_: ok, I am not familiar with it, and the manpages are not very clear, but if it works then great :) [12:42] alf__, tests pass and I haven't seen any flakyness locally [13:54] oh darn, I had the mir ppa enabled still.. [13:57] might have been why my nv50 was still not working after fixing all the card bugs :> [14:10] mlankhorst: are you free to help with ati debug wrt this "unable to provision hw cursor" ?...we have a QA machine on which this is consistently failing 100%, didrocks can help provide access [14:10] its blocking mir entering universe [14:11] robotfuel: ^ let's see if mlankhorst can help [14:15] kgunn: sure ;P [14:15] what kind of hw btw [14:16] question: do we have an env variable for the platform already? I'd like to see if my native platform is gbm or android at runtime without ifdef and maybe getenv is an option.. [14:17] mlankhorst: https://bugs.launchpad.net/mir/+bug/1203070 [14:17] Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] [14:17] "cedar" [14:19] tvoss_: ^ [14:19] kgunn, yup [14:28] mmm lets see [14:30] kgunn: that's only starting with unity-system-compositor from ppa:mir-team/unity-system-compositor right? [14:32] mlankhorst: well, this may be a didrocks build, via his daily ppa (not necessarily exactly system-compositor-testing) [14:32] mm lets try anyway.. [14:32] kgunn: mlankhorst: to ensure to run the same version, use those from ppa:ubuntu-unity/daily-build-next [14:34] ok, upgrading [14:35] mzanetti, ping [14:35] tvoss_: pong [14:35] mzanetti, soemthing weird going on here: https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1415/console [14:36] tvoss_: hmm... seems to be the same as last time [14:36] tvoss_: I wonder why this is build on ps-android-sandybridge. That seems wrong [14:36] tvoss_: as that's the machine where the devices for testing are attached [14:40] tvoss_: yeah. this definitely seems wrong to me. who sets up Mir jobs usually? [14:41] hikiko: should be easy to add...i would think you could check if gralloc is present [14:42] mzanetti, same happens for clang: https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1300/console [14:43] mzanetti, not sure, thomi perhaps? [14:43] alf__, ^ can you help here? [14:43] tvoss_: hmm... not sure why the one on kinnara fails. that should work. [14:44] tvoss_: I contacted fginther. he's in a phone call right now. when he's free again we'll try to resolve it asap [14:44] yes I've added kgunn I just wonder if we already used one because I couldn't find any [14:44] hikiko: why do you need to get the native platform type? [14:44] because my nested platform has a pointer to the native platform in order to call native functions when necessary [14:45] and I have to initialize that pointer to a new GBM or a new Android platform [14:45] (the pointer is mg::Platform) [14:45] hikiko, I thought the idea is that the nested platform does not need to know those details? [14:46] it won't know [14:46] then it will use the mg::Platform functions [14:47] but at some point I have to initialize the mg::Platform [14:47] hikiko, isn't it like auto platform = mg::NestedPlatform()? [14:47] hikiko: you can do it that the same way we get the platform currently, by exposing a symbol in the native platform library (e.g. create_native_platform_nested(...)) [14:48] I call create_platform_nested() :s [14:48] but even the current create_platform [14:48] returns a GBMPlatform in GBM case [14:48] and an Android in case of android [14:49] return std::make_shared(report, vt); [14:49] you specify that your pointer is mgg::GBMPlatform [14:50] kgunn: hm tons of fun spam in dmesg...... [14:50] hikiko: Isn't that what you need? The native platform knows what to do when you call create_native_platform_*(...). It creates an appropriate mg::Platform pointer and sends it back to you. [14:50] kgunn: http://paste.debian.net/18047/ [14:50] though no idea why.... [14:51] yes but in create_platform* you specify what type of platform this is [14:51] you can't have a mg::Platform pointer without initialize it with new GBM or new Android [14:51] mlankhorst: do we need to contact radeon guys? [14:51] but I guess that's what causes your issue here [14:51] you either have to do ifdef "GBM"... [14:51] kgunn: I think so.. [14:51] or get the platform at runtime [14:51] using getenv for example [14:52] mlankhorst: do you have a contact ? (i'm supposing you already have :) [14:52] kgunn: that was with drm-next + drm-fixes of today :P [14:52] create_platform returns a different pointer in gbm and in android case [14:52] I guess #radeon would work, brb buying some food [14:52] ta [14:53] hikiko: that's what create_native_platform_nested() will do also, no difference in the mechanism, just in the way the native platform is set up internally [14:53] that was a merge of drm-next + drm-fixes, dno how representive that is :P [14:53] hm i should probably try with a cleaner kernel later just in case [14:53] alf__, I am talking about the create_platform_nested implementation [14:53] mmm [14:54] I mean that [14:54] even if create_native_platform_mnested [14:54] lives in GBMPlatform [14:54] it has to return a GBMPlatform pointer [14:54] ah :) sec [14:56] lol ok :) mg::Platform lala = create_native... yeah... got it... :P [14:56] <-tired :p ok, ignore :) [14:57] thanx! [14:57] I wrote the func and forgot to use it 2 times today :p [15:05] greyback, ping [15:05] tvoss_: pong [15:27] kgunn: ugh, was lacking pm firmware [15:28] mlankhorst: pm == power management ?? (e.g. pmic ) [15:28] yeah [15:28] mlankhorst: oh...yeah...so hw mouse would be like one of the first hw accelerators i suppose [15:28] in terms of sw trying to use it [15:29] indeed [15:29] so I guess you should check dmesg, just in case [15:30] mlankhorst: so, where does that lie in the field of responsibility ?....is that a ubuntu saucy foundational problem ?...or? [15:30] kgunn: heck check dmesg on that machine, then you know for sure [15:30] mlankhorst: mmm, but X worked ? [15:31] gotta run [15:31] x can fallback to unaccelerated [15:31] brb [15:52] mlankhorst: ok...back, so "we" mir team need to add in fallback for sw cursor for xmir/radeon ? [16:00] bschaefer is this something you could look pre-australian time ? ^ [16:00] didrocks can give bschaefer access to machine if needed [16:01] kgunn, whats going on? The sw cursor thing? [16:01] bschaefer: yeah [16:01] https://bugs.launchpad.net/mir/+bug/1203070 [16:01] Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] [16:01] basically we know the problem....we need to create a solution & test it [16:03] kgunn, possibly, i've a few other things ive to work on :) [16:03] kgunn: sure, tell me once you need the access so that I can prepare [16:03] bschaefer: no prob...if you're helping robotfuel keep doing that [16:03] no pointing in switching just for the sake of it [16:03] kgunn, no, i do unity-maintenance under bregma and i've some new ibus changes I need to get landed [16:03] greyback: curious...you said unity8 now (w/ some caveats/bugs) runs on mir....do the instructions on the wiki need to change ? [16:04] or does it all just magically stay relevant ? [16:04] kgunn, if I can finish that up quickly I could possibly take a look :) [16:04] kgunn: which instructions? Let me check through them [16:04] bschaefer: ah...ibus...yeah...kinda critical :) [16:04] greyback: https://wiki.ubuntu.com/Touch/Testing/Mir [16:05] kgunn, yeah, as some would like the new version landed, but that SW fallback cursor is also critcal! [16:05] kgunn: hmm, so that URL to s-jenkins is an internal url only, so no community people will be able to use it. [16:06] * bschaefer goes to work fast [16:06] kgunn: other bits could be updated, yes. I'll add it to my list [16:06] greyback: doh...good point [16:06] np...in due time [16:06] kgunn: ack [16:08] greyback: crap...can you shoot me the link to your sketchpad of "todo's" closed it before saving link [16:09] kgunn: sure: http://studio.sketchpad.cc/UFFAX8fxc2 [16:10] greyback: one more interrupt, does "Use actual surfaces instead of screenshots for window management" actually address my "cut corners" blueprint ? [16:12] kgunn: I don't think so. That proposal is for shell to animate the actual application surface, not a screenshot of the application (as we're doing right now) [16:12] kgunn: nothing to do with single-surfac shell [16:14] greyback: got it...texture source for the single surf...not actual compositing... [16:29] didrocks: can you paste the dmesg output from the ati-trouble machine into the bug ? https://bugs.launchpad.net/mir/+bug/1203070 [16:29] Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] [16:31] mlankhorst, ping [16:38] kgunn: I just pasted the relevant time log: https://bugs.launchpad.net/mir/+bug/1203070/comments/5 [16:38] Launchpad bug 1203070 in Mir "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Confirmed] [16:38] (the lightdm segfault) [16:40] didrocks: ??....lankhorst indicated the pm firmware not being installed as the reason for hw mouse failing....this is somewhere after that [16:41] kgunn: pong, might be related, maybe not [16:41] kgunn: I don't see any logs for it, does he know what we should install? (even on the image by default) [16:41] can i start unity-system-compoistor alone [16:41] mlankhorst: it seems lightdm is setting up an environment for it [16:41] so stopping/start lightdm [16:42] without lightdmm... [16:42] would be a question for kgunn and robert_ancell I guess :) [16:42] mlankhorst: sure.. (in xmir config i assume you mean) [16:43] which should just kick of mir [16:43] tvoss_: ^ sanity [16:43] but obvioulsy...no mir clients (as xmir has failed by that point) [16:44] kgunn, ENOCONTEXT [16:46] tvoss_: could one, after a failure to boot in xmir, kick off the u-s-c process manually [16:46] kgunn, hmmm, no, you need lightdm and the env for that ... [16:48] tvoss_: is the need for lightdm because we cannot have a "clientless" mir ? [16:48] * didrocks wasn't on crack then :) [16:48] kgunn, of course not, it's because the usc needs t obe passed some file descriptors [16:48] kgunn, and a vt to operate upon [16:49] tvoss_: ack [16:49] * kgunn was insane... [16:52] gone [18:15] kgunn, ping [18:21] bschaefer: yo [18:21] kgunn, hey, so ive some time now, but I don't have an ATI card :( [18:21] i've a large desktop I can install ubuntu on but it'll take a bit of time [18:22] bschaefer: yeah....it'd be best to get access to didrocks machine [18:22] but he's not on [18:22] at least for the moment [18:22] dang and now hes gone... [18:22] kgunn, well I should have mentioned this acouple hours ago :) [18:22] he might show back up [18:23] yeah, Ill try poking some QA people in the meantime [18:23] cool [18:24] tvoss_: robotfuel: do you know if there is someone else who might be able to provide us access besides didrocks to the ati machine failing to boot ?? [18:25] kgunn, not sure, sil2100 might be able to help [18:25] I don't have access to the ati machine yet, jibel might? [18:25] kgunn: ^ [18:29] jibel: could you help us ? [18:30] kgunn, I think I found one [18:31] sweet! [18:31] bschaefer: i'm gonna break for lunch... [18:31] kgunn, cool, enjoy your lunch! [18:50] xjunior, hey there :) [18:50] xjunior, still busy debugging [18:51] tvoss_: nice man :) good luck with that!! [18:51] I believe it's a hard piece of code to debug [18:51] kgunn, yup, got access to a ati machine, thanks for the suggestion :) [18:51] xjunior, it is, raof is looking into it, too [18:51] fortunately it's not Xorg :P [18:52] I still can't get into Xorg, btw. I believe it's a intel driver issue. It's crashing and I remember it was updated a few days ago [18:52] xjunior, did you pin the ppa? [18:53] yeap [18:54] xjunior, something like this: https://bugs.launchpad.net/xmir/+bug/1203776 [18:54] Launchpad bug 1203776 in xserver-xorg-video-intel (Ubuntu) "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Undecided,Confirmed] [18:54] xjunior, just to make sure: you have got the system-compositor-testing ppa? [18:54] * bschaefer was getting an intel crash on normal X as well this morning [19:05] I am trying to process the scene graph discussion email [19:05] tvoss_: yea yeah, absolutely [19:05] I guess that's what's happening to me :) [19:06] and I think what Alan is describing, and what I've started to see we need through some of the pain in resolving races like in session-transactions [19:06] is not actually a scene graph in...any particular sense [19:07] one of it's responsibilities (it's interface to the compositor) coincides with some of the responsibility of a scene graph [19:07] That's exactly the situation I have here, tvoss_. I +1'd that bug [19:07] xjunior, thx [19:08] but it contains assosciations like session->surface, etc, which aren't actually 'scene' assosciations [19:08] I guess I feel like the problem we are trying to solve, is that we have dataa and state distributed over the system so we want to integrate it in to a single multi index store [19:09] and not [19:09] we need a "scene graph" [19:10] *trails off in to mumbling* [19:10] I am just thinking outloud :) [19:14] racarr, so your trying to come up with a data structure that can store all of the session/surfaces while having random access while having some sort of graph structure? [19:14] * bschaefer could have read that wrong [19:16] * bschaefer looks up scene graph... [19:16] which looks just like a B-Tree [19:18] but a bit crazier... [19:19] bschaefer: Hmm, thats probably part of the data structure. but I think finding a data structure once we know exactly what we need wont be so bad [19:20] I guess to me the thing is, state is distributed all over the system [19:20] i.e. the input state is held in some data structure that basically builds an input view of the surface stack [19:20] right, reading scene graph wiki was kind of funny: The definition of a scene graph is fuzzy [19:21] the shell bit with the session assosciation, and shell state lives in the shell, and acts as sort of another view/controller to the surface stack [19:21] isn't input in a different thread as well? [19:21] likewise, the compositor gets a view of the surface stack, and treats it like a scene graph [19:21] Right [19:21] so with all the state in different bits [19:21] synchronization gets [19:21] increasingly difficult [19:21] geez, thats going to be hard to get that all sync... [19:21] yeah [19:21] and, another thing is pretty much all state [19:21] changing in mir [19:22] needs to support some pattern like [19:22] notify the shell of this and potentially allow it to interfere, etc. [19:22] and without one authoratative source of...what is what when [19:22] this becomes kind of difficult and we've ended up with this weird pattern where the shell will do things like subclass one of our factory objects [19:22] you'll get lost...and out of order :( [19:22] and interfere and then call up to the base class [19:23] yeah [19:24]