=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === marcusto_ is now known as marcustomlinson_ === chihchun_afk is now known as chihchun [08:30] hey mir-ers [08:31] I just quickly want to check if Mir is known to work/not work on desktops with nvidia graphics [08:31] I'm trying the desktop-next (Unity 8) ISO that we've been building and it looks like it's hung on my machine with nvidia [08:31] but I can't do anything with it to find out. :) [08:34] Laney: it doesn't work with the proprietary nvidia drivers yet [08:34] alf_: I didn't install any drivers yet [08:34] this is a live session from the iso === chrisccoulson_ is now known as chrisccoulson === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [10:02] alf_: feel like contributing to a discussion? https://code.launchpad.net/~kdub/mir/share-occlusion-with-examples/+merge/222577 [10:04] alan_g: sure [10:04] thanks. Otherwise it will keep going in circles [10:33] alf_: sorry for slow feedback - I had a very different algorithm in mind: http://paste.ubuntu.com/7657755/ still trying to think yours through [10:34] alan_g: no worries [11:02] alf_: your options "A" and "C" are rather procedural - they are "ask" interfaces not "tell" ones. I'd go with "B" === dandrader is now known as dandrader|afk [11:15] alan_g: I haven't thought through how to pass up-to-date information about available compositors in this case, but it should be workable. [11:15] alan_g: s/workable/doable/ [11:20] doesn't the buffer queue already track compositors? === chihchun is now known as chihchun_afk [11:22] alf_: I've been thinking and we really only need to know that compositors have been removed [11:24] http://paste.ubuntu.com/7657933/ === dandrader|afk is now known as dandrader [11:44] I heard that mir works under vmware [11:44] is that true? === alan_g is now known as alan_g|lunch [12:12] Laney: Yes. On a Linux host most free drivers are blacklisted, so you need to unblacklist them to get accelaration and get Mir to run. [12:13] alf_: Interesting, how can I do this? Will they work or are they blacklisted for a good reason? :) [12:13] Point me to documentation if it exists [12:14] Laney: There are some glitches, but they work more or less. http://askubuntu.com/questions/181829/how-to-fix-3d-acceleration-for-vmware-workstation-9 [12:15] Laney: (the fixe is applicable for vmware player too) [12:16] Laney: note that you need a relative recent version of Mir that works with vmware, not sure what version the iso you have has [12:17] alf_: It's built from utopic === dandrader is now known as dandrader|afk [12:18] hrm, my host session hung [12:19] Laney: as long as mir >= 0.2.0 you should be ok [12:36] alf_: can't stop it from crashing my session every time [12:36] oh well === alan_g|lunch is now known as alan_g [13:14] alf_: @share-occlusion-with-examples: http://programmer.97things.oreilly.com/wiki/index.php/Beware_the_Share [13:26] mterry: hey, trying to land 0.3.0 mir, packages built, but i'm not booting....is this a normal u-s-c log [13:26] https://pastebin.canonical.com/111823/ [13:27] kgunn, sort of... except that the "Closing session session-0" line means the user session died for some reason [13:27] kgunn, look at the ~/.cache/upstart/unity8.log file [13:27] ack [13:29] mterry: eeewww....doesn't look good https://pastebin.canonical.com/111824/ [13:29] kgunn, well that explains that anyway :) [13:29] hmmm, wonder if this has to do with the platform-api v2 transition.... [13:30] or the gcc4.9 stuff i wrestled with... [13:30] kgunn, well we worked with v2 before, eh? I assume you've rebuild platform-api against the new Mir? [13:32] mterry: yes...i'm starting to think this might be gcc4.9 hoo-ha working its way through...(stuff being stuck in proposed etc) [13:32] ah [13:33] silo got built against proposed archive last night at slangasek's request...so it built...but [13:33] i don't think i'm trusting this [13:34] kgunn, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1328485/comments/12 [13:34] Ubuntu bug 1328485 in unity8 (Ubuntu) "unity8 crashed with SIGABRT on Qt 5.3" [High,In progress] [13:34] seems relevant [13:36] * kgunn looks === dandrader|afk is now known as dandrader [13:49] alan_g: yeap [13:49] alan_g: (@beware-the-share) [13:57] fginther: can you see what's different about our mako tests today? Mir is having a hard time that doesn't appear to relate to the MPs being built: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/ [14:01] alan_g, I can't take a look right away, you should try the cihelp vanguard. I'll guess that the change is due to a new image, but I'll have to look closer to know for sure. [14:02] fginther: OK thanks [14:18] anpok on holidays? [14:21] dandrader: he is, but he doesn't know how...he's been showing up alot [14:21] what do you need? [14:23] kgunn, wondering who took over https://code.launchpad.net/~andreas-pokorny/mir/input-sender/+merge/220984 === alan_g is now known as alan_g|tea [14:26] dandrader: even i don't know, he acted like he was going to prep someone on the team before dropping completely....he might have plans to come back on just for this... [14:26] alf_: alan_g|tea ^ you guys know ? [14:27] kgunn: I just know that anpok asked us to revisit and review the input-sender related branches === alan_g|tea is now known as alan_g [14:35] kgunn: I know the same as you - he's on vacation but not gone [14:50] Morning [14:53] kgunn: yeah my vacation needs fixing [14:53] it does fail all basic acceptance tests [14:54] but I make a lot of progress [14:56] :) [14:56] racarr_: hey, i was just trying to scrub some blueprints... [14:57] am i right to include cursor renderable as part of "making cursor settable by client" ? (as one big task...i mean that's the point right?) [14:57] kgunn: *incoherent stream of 8 am mumbling* [14:57] lol [14:57] kgunn: no the cursor settable by client stuff is the rest of the cursor spike [14:58] only if i get an racarr "wheeee" [14:58] making hte cursor a renderable [14:58] is software cursor and [14:58] ok...so its really 2 things [14:58] visualization spots [14:58] and android cursor support I guess [14:58] whatever we want that for lol [14:58] right...3...but i already broke out the viz spot [15:00] :) [15:03] alan_g: alf_, kdub_, racarr_, AlbertA: If there are further discusions, i.e. on naming moving things around I wont be able to apply them this week. In that case someone needs to take over or it will rest for another week [15:03] kgunn: ^ [15:04] anpok: enjoy your time off :) [15:06] thx... i will go back to my wall [15:55] greyback: are you the one to talk to about the "add client & server API's to communicate orientations" requirements? [15:56] alan_g: I am, but I'm trying to clarify requirements from the SDK team right now [15:57] greyback: OK. I'll be doing the implementation - so grab me when you're ready. [15:57] alan_g: will do, thanks [16:26] kdub_: is your question answered? https://code.launchpad.net/~alan-griffiths/mir/rework-integration_tests-test_surfaceloop.cpp/+merge/222946 [16:26] checking... [16:27] approved [16:30] ta === alan_g is now known as alan_g|EOD [20:27] the cursor renderable observable problem is annoying... [20:28] the thing with just making a "renderable" observer, is what seperates a renderable from a surface? Well its things like [20:28] MirSurfaceAttrib... [20:28] which a surface observer needs [20:28] but a renderable doesnt have [20:28] so then do you really need [20:28] a renderable observer/render state observer and a surface state observer [20:29] and then. there is the awkward position of input which happens to basically want [20:29] a renderable [20:29] something doesn't mesh with the questions with me [20:29] except it doesnt care about the buffers [20:29] a renderable is what the compositor sees [20:29] kdub_: So I am trying this...build the cursor renderable in to the stack approach [20:29] sure [20:29] and the problem is how does the compositor get change [20:29] notifications for it [20:30] because its not a surface, so it cant install a surface observer on it [20:30] and just promoting "add/remove_observer" to renderable, and scene::observer::surface_added to renderable_added [20:31] isnt enough, because it doesnt make sense to install [20:31] a surface observer on a renderable [20:31] because it has things like attrib_changed(MirSurfaceAttrib... [20:31] which a renderable certainly doesnt have [20:31] well, it doesn't make sense to have the add/remove observer on mg::Renderable [20:31] mm [20:32] but why not have a CursorRenderable: public Renderable, public [20:33] Where UpdateNotificationThing is an interface like add/remove_observer ? [20:33] right [20:33] * kdub_ is obviously a step removed from the problem, so it could also be reasonable to have that be a constructor dependency [20:33] What is the type of the observer though? It shouldn't contain things like [20:33] attrib_changed [20:33] because the cursor renderable doesnt have surface attributes [20:34] let me poke through the code for a min [20:35] :) thanks. I am feeling kind of stuck on it. [20:37] oh, i kinda see the problem digging through... the msc::Observer interface is pretty surface-based at the moment [20:37] yeah [20:38] and unity-mir wants that interface I think...I mean it makes sense that you should be able to observe all surface state somehow [20:38] and msc::Surface inherits from classes that don't make sense for a cursor [20:39] mm [20:39] like, msc::Surface : public input::Surface [20:39] well [20:40] input::Surface wouldn't be SO bad [20:40] because essentially you can be a null input::Surface and everything could skip you [20:40] and really all it needs at the core is a rectangle [20:41] well, its still ugly [20:41] but then also there are all these [20:41] extra methods, i.e. [20:41] allow_framedropping, type, state [20:41] force_requests_to_complete [20:41] aha [20:42] it kinda feels like msc::Surface is too specific [20:42] and the msc::Observer should be based around an interface that's generic enough for the cursor too [20:42] and the surface and the cursor can both use that [20:42] and both poke the scene via the msc::Observer interface [20:42] mm, but I think the shell [20:43] really wants i.e. notify_attrib_changed [20:43] etc [20:44] right, but cursor just never calls that [20:47] yeah...it's possible that way.... it just feels a little like interface abuse I guess [20:50] eh, observer is a semi-coherent interface of all the levers that can be pushed to trigger a scene change [20:50] mostly-semi-coherent even :) [20:50] lol yes semi coherent [20:50] part of the thing too is [20:50] strictly like [20:50] I dont think MirSurfaceAttrib changing by itself [20:50] is enough to trigger recomposition right [20:50] or like input changes [20:50] etc [20:50] the shell has to [20:51] action it [20:51] well maybe input [20:51] but not recomposition [20:51] well, it shouldn't be, i'm not sure of the current state [20:51] right shouldn't be [20:51] the logic there can be improved for sure [20:52] like, MultiThreadedCompositor actually got a bit of smarts to it after some of the recomposition changes [20:54] mm