[00:06] <mhall119> thanks ogra_, I may just rig up my old phone to record
[01:31] <racarr> Back for more.
[01:31] <racarr> (I just cant get enough)
[02:14] <mhall119> hey racarr
[05:55] <RAOF> Stupid valgrind. Be faster. On the N10
[08:20] <duflu> Hmm, launchpad and Canonical servers seem to be down... ?
[08:21] <chunsang> duflu: I think so, couldn't connect to Canonical servers.
[08:22] <seb128> it's being looked at
[08:24] <duflu> I have the whole rest of the internet and still feel cut off :/
[08:25] <alan_g> Launchpad seems to be working here - but canonical irc isn't
[08:25] <duflu> greyback: Can you explain what it is exactly that makes the summary screen appear when waking from sleep? Is it Unity8 getting a wakeup event of some sort?
[08:27] <greyback> duflu: u8 gets a dbus message from powerd when the display has been blanked - for which it draws the greeter (summary screen as you called it)
[08:28] <duflu> greyback: OK, cool. So my solution should work then. Unfortunately I can't x-compile for android now I deleted my cache and launchpad is gone
[08:29] <greyback> duflu: not sure what you're fixing but uhhh.. good job! :)
[08:29] <duflu> greyback: Wrong frame seen (sometimes) on wakeup
[08:30] <greyback> duflu: does it fix this too? https://bugs.launchpad.net/unity8/+bug/1353374 by any chance?
[08:30] <duflu> greyback: Don
[08:31] <greyback> woo!
[08:31] <duflu> greyback: Don't think so
[08:31] <greyback> aww
[08:31] <duflu> greyback: I'm only working on restarts right now
[08:31] <greyback> ok
[08:31] <duflu> greyback: Although I suspect Mir shouldn't need fixing. Why wouldn't you get U8 to have some greeter frame ready when it goes to sleep?
[08:32] <duflu> Mir is getting *fixed* regardless
[08:32] <duflu> I mean, switch to greeter mode and then it redraws at the sleep rate of 10Hz
[08:32] <greyback> duflu: u8 isn't blocked from drawing when the display goes to sleep. So it does eventually draw the greeter
[08:32] <alan_g> alf_: do you have any insight? https://code.launchpad.net/~alan-griffiths/mir/deduplicate-platform-plugin-symbols-maps/+merge/229939
[08:33] <greyback> duflu: there's some reason it takes >1 second for u8 to actually show the greeter though. That I don't understand
[08:33] <duflu> greyback: That's a worry. It means my solution of waiting 500ms for a fresh frame before forcing one isn't enough
[08:34] <duflu> greyback: Although I have added a *flush* for the whole scene. Need to get launchpad back to test on the phone
[08:39] <alf_> alan_g: I am OK with exporting the mesa symbol for now, I can't think of a sane way to do it otherwise (but admittedly I haven't thought too hard).
[08:40] <alan_g> alf_: I don't feel I've any real understaind
[08:40] <alan_g> understanding of the problem it solves - just how the current solution works
[08:40] <duflu> alan_g: (I still can access LP but) I reproduced the link failure of USC again today. Seems I was the only one testing in a pure clean environment so still had the bug after yesterday's fix. Found the bug is actually in USC so proposed a final fix there
[08:40]  * alan_g wonders why backspace is so close to enter
[08:42] <alan_g> duflu: I think you were testing USC trunk not .../devel-mir-next which has a similar fix (I think yours is probably more correct though)
[08:42] <duflu> alan_g: Tested both today :)
[08:42] <duflu> The bug is consistent
[08:43] <duflu> I do wonder how the silo(s) built USC at all. It means they're not building it correctly if they succeeded last night
[08:44] <alan_g> duflu: camako and I were wondering the same about Friday's "successful" build
[08:44] <alf_> alan_g: problem is: because Mesa supports multiple platforms, when we call eglGetDisplay(handle), Mesa needs to decide which platform to load based on handle. For mir it tries to load the ...is_valid function and uses that to check if that is a Mir handle so it can use the mir platform.
[08:45] <alan_g> Either the environment or the build settings must be significantly different in a debuild
[08:45] <alf_> alan_g: an idea is to expose that function through a helper library instead of mirclientplatform
[09:10] <alan_g> alf_: I think there should probably be a better way, but without a second platform requiring analogous capability it is hard to know what the right abstraction is. So I'm OK with exporting the mesa symbol for now (or trying to).
[09:13] <duflu> alan_g: Where can I find the nested-server input event logic?
[09:13] <duflu> Is there a pass-through somewhere?
[09:18] <alan_g> duflu: not sure exactly there's an event handler around somewhere ... NestedOutput::mir_event(?) ... that takes input events and injects them in the input stack
[09:21] <duflu> alan_g: Aha, you're right. I didn't think to look under graphics/ for input code :)
[09:22] <duflu> Whee, launchpad returns
[11:33] <alf_> Saviq: https://bugs.launchpad.net/mir/+bug/1353374 , have we concluded that it's qtmir or unity8 at fault here, I see that they are marked in progress for those components ?
[11:35] <Saviq> alf_, Daniel was working on those, dunno how far he got though
[11:35] <Saviq> alf_, so I can't comment on whose fault it is yet
[11:36] <alf_> Saviq: ok, I will wait for Daniel... I just want to know if I should be looking into it from the Mir side of things
[12:55] <alf_> dandrader: Hi! About take_snapshot(): it is synchronous when returning an empty snapshot (e.g. when there is no session/surface), but ideally you should assume nothing about it, only that the callback will be called at some point.
[12:55] <alf_> dandrader: is this causing a problem for you?
[12:57] <dandrader> alf_, no really. just wanted to know
[12:57] <alf_> dandrader: ok
[12:58] <alf_> dandrader: for https://bugs.launchpad.net/mir/+bug/1353374, does "in progress" mean that you have traced the problem in unity8/qtmir?
[13:13] <mardy> after calling mir_connect_sync(), mir_connection_is_valid() returns false, and the error is: "connect not called"
[13:13] <mardy> any ideas?
[13:15] <alf_> mardy: do you have some code you can share?
[13:16] <mardy> alf_: http://bazaar.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/trust-sessions/view/head:/online-accounts-service/mir-helper.cpp
[13:17] <mardy> alf_: lines 118-121
[13:23] <alf_> mardy: hmm, that's strange, is there an easy way to reproduce this?
[13:29] <mardy> alf_: not without building the branch... but I could try to write a simpler test case
[13:30] <mardy> alf_: or maybe the MirConnection is simply NULL?
[13:31] <alf_> mardy: not null, it would crash in that case
[13:31] <alf_> mardy: can you run under gdb and "catch throw" to see if any exceptions are thrown inside mir?
[13:33] <mardy> alf_: yep: http://paste.ubuntu.com/8026826/
[13:33] <mardy> alf_: let me see if I can install debug symbols...
[13:39] <alf_> mardy: so there are two aspects to this 1. that mir_connect_sync fails 2. that it returns an error message that is not expected
[13:40] <alf_> mardy: Let's focus on (1) since that's what's blocking you I presume
[13:40] <alf_> mardy: Which server are you trying to connect to?
[13:42] <mardy> alf_: the default one (I just run the app from the phone's terminal)
[13:43] <alf_> mardy: ok, what's your "MIR_SOCKET" env value?
[13:44] <mardy> alf_: the variable is unset
[13:45] <alf_> mardy: ok, then it should connect to $XDG_RUNTIME_DIR/mir_socket
[13:46] <alf_> mardy: probably /run/user/32011/mir_socket
[13:47] <mardy> alf_: do you mean that I should pass that instead of NULL, or you are just saying that it will connect there by default?
[13:47] <alf_> mardy: it should connect there by default, so need to do anything
[13:47] <mardy> alf_: OK, the file exists
[13:49] <alf_> mardy: ok, just to be sure can you confirm that XDG_RUNTIME_DIR is set properly?
[13:50] <mardy> alf_: yes, it's correct
[13:52] <alf_> mardy: so, unity8 has been known to reject connections that do not have an associated desktop file, can you try running with --desktop_file_hint=/usr/share/applications/online-accounts-ui.desktop (or some other valid .desktop file)
[13:53] <alf_> mardy: alternatively export  APP_DESKTOP_FILE_PATH=<desktop-file>
[13:57] <mardy> alf_: ah, right, there was an e-mail discussion about authenticating trusted helpers, that might be the issue
[13:57] <mardy> dednick: hi! Does the above ring a bell to you? ^
[13:59] <dednick> mardy: looking
[14:00] <greyback> mardy: oh, should you not be using the trusted socket: $XDG_RUNTIME_DIR/mir_socket_trusted
[14:01] <dednick> mardy: is this a trust helper? or an app?
[14:01] <mardy> greyback: ah-ah! makes sense :-)
[14:01] <mardy> dednick: a trusted helper
[14:01] <dednick> mardy: yeah. trust helpers need the trusted socket to connect otherwise qtmir will reject the connection
[14:02] <mardy> dednick: OK, I will try that, thanks
[14:06] <mardy> looks like it's working! :-)
[14:06] <mardy> greyback: the helper is supposed to slide up from the bottom, right?
[14:06] <greyback> mardy: yep (dednick's work)
[14:07] <mardy> then it's working fine :-D
[14:07] <greyback> woo!
[14:59] <groot_> kdub: Hello :). Did you find any solution to my problem? Earlier, I was running some mir_demo test in the phone. Most of them works fine, some failed with exception.
[15:00] <kdub> groot_, no, flickering is usually caused by some timing problems that are tricky to pin down
[15:04] <groot_> kdub: Any particular log you need to identify the problem? Here's the tests log anyway, if it helps http://pastebin.com/aHqTs0qH.
[15:10] <qengho> I upgraded to uptopic on my machine.  My xmir buffer n-1 problem is gone, yay.
[15:15] <qengho> mir test clients don't run, though.  mir_demo_client_basic    #->   Assertion `mir_connection_is_valid(mcd.connection)' failed.
[15:21] <racarr> Good morning
[15:22] <racarr> delayed standup is mostlyu studying inpout resampling
[15:27] <alan_g> qengho: what are you using as the Mir server? Is it publishing an endpoint at $XDG_RUNTIME_DIR/mir_socket?
[15:28] <qengho> alan_g: There is no socket. What am I using? Er, xmir, I think.
[15:29] <alan_g> XMir is an X11 server, not a Mir server - so I wouldn't expect it to support Mir clients.
[15:36] <qengho> Oh. I'm using regular desktop on Utopic. I have a client I wish to test. What's the best way?
[15:39] <alan_g> switch to (say) VT1 & run a mir server (as root) e.g. "sudo mir_demo_server_basic"
[15:39] <alan_g>  switch back to VT7 and sudo chmod a+rw /tmp/mir_socket
[15:40] <alan_g> then run your app using /tmp/mir_socket as the socket (on command line or via $MIR_SOCKET)
[15:40] <alan_g> Switch back to VT1 to see the results
[15:41] <alan_g> qengho: http://unity.ubuntu.com/mir/using_mir_on_pc.html
[15:42] <qengho> alan_g: thanks.
[15:43] <groot_> kdub: I tested eglMakeCurrent() with some ALOG commands like this http://paste.ubuntu.com/8027461/
[15:43] <groot_> found that sometimes it reports "No context", "Not drawn", "No surface". But function returns EGL_TRUE.
[16:34] <racarr> Is anyone familiar wiht test failures in the phablet-test-run mir-demo-suites fixture on mako CI
[16:34] <racarr> touchspot-renderable has failed CI twice because of that...it looks like the tests(I can't figure out how to run them yet) are just runnin
[16:34] <racarr> g
[16:34] <racarr> a demo server and a client
[16:35] <racarr> which  I just did with the branch on a clean mako...
[16:41] <racarr> or does anyone know how I can reproduce this suite locally? I don't seem to have it as an autopilot test suite which apparently it is
[16:42] <racarr> + phablet-test-run -x -s 04ccca120acd4dea -v mir-demo-tester --mir-demo mir_demo_client_fingerpaint /tmp/mir_demo_client_fingerpaint-log
[16:42] <racarr> this sort of stuff
[16:43] <racarr> https://launchpad.net/~chris.gagnon/+archive/ubuntu/mir-demo-tester perhaps
[16:45] <robotfuel> racarr: that doesn't use autopilot, I think that needs the mir-demos or mir-test-tools package to be installed
[16:47] <racarr> robotfuel: Ah the -x arg to phablet-test...thanks :)
[16:47] <racarr> the -s was so confusing I filtered out the -x too and had been trying to run it as autopilot I guess
[16:49] <robotfuel> racarr: the phablet-test-run -x just executes a command on the phone, the -s is the phone's serial number :D
[16:49] <racarr> robotfuel: It looks like I need mir-demo-tester from the PPA? Or was I supposed to get it from some package in archive.
[16:49] <racarr> ah
[16:50] <robotfuel> racarr: mir-demo-tester is in my ppa. it's not in the archive.
[17:16] <racarr> kdub: Should I consider touchspot renderable rejected until demo shell is fixed?
[17:16] <racarr> as long as demo shell is decorating based on renderable
[17:16] <racarr> there is obviously no way to
[17:16] <racarr> have it not decorate certain renderables
[17:17] <racarr> without adding information to renderable that
[17:17] <racarr> post_renderables_if_optimized
[17:17] <racarr> can't interpret
[17:17] <racarr>  demo shell is fixed, renderable is fixed, the tesselate method is changed, whatever
[17:22] <racarr> I mean one "solution"
[17:22] <racarr> is to have renderer accept scene elements
[17:22] <racarr> while display buffer would only accept renderable
[17:29] <kdub> racarr, yeah, thats somewhat what i'm thinking
[17:30] <kdub> i mean, Renderer needs to be picked apart, but thats a bit of a tough task
[17:30] <kdub> and after lp:~kdub/mir/fix-1348330 lands
[17:30] <kdub> the demo shell's compositor can operate on renderables
[17:30] <kdub> so then the scene elements can carry the info
[17:30] <kdub> sorry, rephrase
[17:31] <kdub> the demo shell's compositor can operate on _scene elements_
[17:31] <racarr> aha ok
[17:31] <kdub> actually, that one is moderately clear to land
[17:32] <kdub> oh, yeah, have to track down that valgrind thing
[17:32]  * kdub can shift to doing that
[17:32] <racarr> :) No real hurry on my end besides
[17:32] <racarr> generic trying to iterate on open branches in the morning
[17:32] <racarr> style situation
[17:34] <kdub> yeah, its about time to get that one through though
[17:35] <racarr> :) ok yeah it looks like after that it would be pretty straightforward to extend
[17:35] <racarr> well
[17:35] <racarr> change would_embellish to work in terms of scene elements
[17:36] <kdub> sure
[17:37]  * kdub grumbles about GLRenderer
[17:39] <kdub> i think there should be SceneElements::with_shell_data(std::function<void(std::shared_ptr<void>)> const&)
[17:40] <kdub> or a get/set that shells can program in data thats affixed to the specific SceneElement
[17:40] <kdub> but, doesn't clutter up core mir with a bunch of specific interfaces for decarotions/animations
[17:40] <kdub> that all the shells want to rewrite anyway
[17:43] <racarr> maybe...
[17:45] <kdub> yeah, doesnt really apply to the cursor stuff though, as that's something that comes out of 'core mir'
[17:45] <racarr> It makes sense in that it solves problems so far we
[17:47] <racarr> see between qtmir and demo-shell
[17:49] <racarr> I guess im still attached to this idea
[17:49] <racarr> of functional purity of the renderer with respect to
[17:49] <racarr> scene elements/renderables
[17:49] <racarr> which shell data, definitely kind of flies at
[17:49] <racarr> on the other hand um
[17:50] <racarr> that idea has never really panned out
[17:50] <racarr> nor has any reasoning why it
[17:50] <kdub> I guess I just don't see that the renderer is functionally pure right now :)
[17:50] <racarr> should pan out really been proven
[17:50] <racarr> no! It's not
[17:50] <racarr> well
[17:51] <racarr> I mean with respect to the renderables it almost is right there is a certain serializable input stream
[17:52] <racarr> i.e. {buffer: 3, geometry: some rectangle}
[17:53] <racarr> I mean I don't know you can view it as outputting some hardware command stream
[17:53] <racarr> which obviously is stateful
[17:53] <racarr> depending on overlay state and bla blabla.
[17:54] <racarr> but you can also view, the renderer, and the renderer...backend (i.e. opengl, hwc...) as
[17:54] <racarr> a function from Renderlist -> pixels
[17:55] <racarr> but maybe that's not really particularly meaningful :)
[19:09] <Nothing_Much> Are there problems with running XMir with the Oibaf PPA on Radeon APUs?
[20:33] <racarr> [ 68%] Building CXX object tests/unit-tests/CMakeFiles/mir_unit_tests.dir/graphics/mesa/test_buffer_allocator.cpp.o
[20:33] <racarr> [ 69%] [ 69%] Building CXX object tests/unit-tests/CMakeFiles/mir_unit_tests.dir/graphics/mesa/test_display.cpp.o
[20:33] <racarr> ...whoops
[20:33] <racarr> selection buffer strikes again
[20:41] <racarr> hmm
[20:45] <racarr> ugh
[20:45] <racarr> tried moving is_a_surface/needs_decoration/whatever to SceneElement
[20:45] <racarr> but now...the problem is how does the DemoRenderer know about it
[20:45] <racarr> in particular DemoRenderer::tesselate which is called from the bowels of DemoRenderer::render
[20:45] <racarr> the thing is if you make
[20:46] <racarr> render take
[20:46] <racarr> SceneElementSequence
[20:46] <racarr> then the API to compositor becomes very clumsy...i.e.
[20:47] <racarr> Query scene elements, see if you want to offer to hardware compositor, if you do copy each elements renderable to a renderable list
[20:47] <racarr> pass it to post_renderables_if_optimizable
[20:48] <racarr> if not you pass the scene element sequence to the renderer
[20:48] <racarr> the list copying is pretty ugly :p even if you can make it efficient i.e. make Renderable
[20:48] <racarr> List(SceneElementSequence const&) zero copy
[20:49] <racarr> its a weird assymetry between
[20:49] <racarr> Renderer::render(SceneElementSequence) and DisplayBuffer::post_renderables_if_optimizable(RenderList)
[20:49] <racarr> of course, if you make post_renderables_if_optimizable take SceneElementSequence then
[20:50] <racarr> the entire point of moving is_a_surface toSceneElement
[20:50] <racarr> is invalidated
[20:57] <racarr> the thing is I think the inheritance of implementation
[20:57] <racarr> from GLRenderer->DemoRenderer is weird
[20:58] <racarr> I mean, DemoRenderer could have a totally different interface than GLRenderer because its only used from DemoCompositor
[20:58] <racarr> except that it wants to duplicate the code to draw a rectangle
[20:58] <racarr> which while convenient for saving the original author a half an hour
[20:58] <racarr> isnt a realistic design imo
[20:58] <racarr> err
[20:59] <racarr> it wants to share the code to draw a rectangle*
[21:00] <kdub> right
[21:01] <racarr> I think I am going to hack around it in demo renderer
[21:01] <racarr> rather than make any mir interfaces weirder
[21:02] <racarr> i.e. DemoRenderer::begin(std::set<mg::Renderable::ID> const& renderable_ids_not_to_decorate)
[21:02] <racarr> lol...
[21:03] <racarr> unordered_set even
[21:04] <kdub> yeah, I kinda feel like DemoRenderer/GLRenderer have to be a different objects that share some objects
[21:04] <kdub> like a tessellation object
[21:05] <kdub> like, even if it it didn't share anything, writing a gl program to draw squares isn't that tough
[21:05] <kdub> even if it is a few scores of lines of code, just gl's nature
[21:05] <kdub>  /end my 2cents
[21:06] <racarr> kdub: I agree....maybe it shouldn't share anything.
[21:06] <racarr> we will see...I think this strangeness of what I am doing here will attract some comments lol
[21:06] <racarr> so ium sure discussion will continue
[21:07] <kdub> hah, yeah
[23:41] <racarr> I think one of the test makos may be failing or something
[23:41] <racarr> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2376/console
[23:43] <RAOF> racarr: Hm. That looks more like a setup error.
[23:43] <RAOF> “unable to make backup link of `./lib/udev/rules.d/70-android.rules' before installing new version: Invalid cross-device link”
[23:44] <racarr> I think thats
[23:44] <racarr> just  a thing that happens
[23:44] <RAOF> That doesn't look like hardware failure to me?
[23:44] <racarr> you always get that in the emulator too
[23:44] <RAOF> That should fail the tests, though?
[23:45] <racarr> oh
[23:45] <racarr> yeah
[23:45] <racarr> hmm
[23:46] <racarr> what does it mean
[23:47] <RAOF> I think that the /lib mount point has gone weird?
[23:47] <RAOF> Man, valgrind is not the greased lightning on an N10.
[23:49] <RAOF> Stupid bloody code bloody bloody grumble mumble grumble...
[23:49] <RAOF> Why do you leak, damnit?!