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