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