| === Trevinho is now known as Trevinho|holiday | ||
| mhall119 | thanks ogra_, I may just rig up my old phone to record | 00:06 |
|---|---|---|
| racarr | Back for more. | 01:31 |
| racarr | (I just cant get enough) | 01:31 |
| === chihchun is now known as chihchun_afk | ||
| mhall119 | hey racarr | 02:14 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| RAOF | Stupid valgrind. Be faster. On the N10 | 05:55 |
| duflu | Hmm, launchpad and Canonical servers seem to be down... ? | 08:20 |
| chunsang | duflu: I think so, couldn't connect to Canonical servers. | 08:21 |
| seb128 | it's being looked at | 08:22 |
| duflu | I have the whole rest of the internet and still feel cut off :/ | 08:24 |
| 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:25 |
| 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:27 |
| 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:28 |
| greyback | duflu: not sure what you're fixing but uhhh.. good job! :) | 08:29 |
| duflu | greyback: Wrong frame seen (sometimes) on wakeup | 08:29 |
| greyback | duflu: does it fix this too? https://bugs.launchpad.net/unity8/+bug/1353374 by any chance? | 08:30 |
| ubot5 | Ubuntu bug 1353374 in qtmir (Ubuntu) "Last dash frame not posted to display" [Undecided,In progress] | 08:30 |
| duflu | greyback: Don | 08:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| duflu | greyback: Although I have added a *flush* for the whole scene. Need to get launchpad back to test on the phone | 08:34 |
| 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:39 |
| 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:40 | |
| 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:42 |
| 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:43 |
| 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:44 |
| 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 | 08:45 |
| 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:10 |
| duflu | alan_g: Where can I find the nested-server input event logic? | 09:13 |
| duflu | Is there a pass-through somewhere? | 09:13 |
| 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:18 |
| duflu | alan_g: Aha, you're right. I didn't think to look under graphics/ for input code :) | 09:21 |
| duflu | Whee, launchpad returns | 09:22 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| === pete-woods is now known as pete-woods|away | ||
| 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:33 |
| ubot5 | Ubuntu bug 1353374 in qtmir (Ubuntu) "Last dash frame not posted to display" [Undecided,In progress] | 11:33 |
| 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:35 |
| 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 | 11:36 |
| 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:55 |
| dandrader | alf_, no really. just wanted to know | 12:57 |
| alf_ | dandrader: ok | 12:57 |
| alf_ | dandrader: for https://bugs.launchpad.net/mir/+bug/1353374, does "in progress" mean that you have traced the problem in unity8/qtmir? | 12:58 |
| ubot5 | Ubuntu bug 1353374 in qtmir (Ubuntu) "Last dash frame not posted to display" [Undecided,In progress] | 12:58 |
| 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:13 |
| alf_ | mardy: do you have some code you can share? | 13:15 |
| mardy | alf_: http://bazaar.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/trust-sessions/view/head:/online-accounts-service/mir-helper.cpp | 13:16 |
| mardy | alf_: lines 118-121 | 13:17 |
| alf_ | mardy: hmm, that's strange, is there an easy way to reproduce this? | 13:23 |
| mardy | alf_: not without building the branch... but I could try to write a simpler test case | 13:29 |
| mardy | alf_: or maybe the MirConnection is simply NULL? | 13:30 |
| === chihchun is now known as chihchun_afk | ||
| 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:31 |
| mardy | alf_: yep: http://paste.ubuntu.com/8026826/ | 13:33 |
| mardy | alf_: let me see if I can install debug symbols... | 13:33 |
| 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:39 |
| 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:40 |
| mardy | alf_: the default one (I just run the app from the phone's terminal) | 13:42 |
| alf_ | mardy: ok, what's your "MIR_SOCKET" env value? | 13:43 |
| mardy | alf_: the variable is unset | 13:44 |
| alf_ | mardy: ok, then it should connect to $XDG_RUNTIME_DIR/mir_socket | 13:45 |
| alf_ | mardy: probably /run/user/32011/mir_socket | 13:46 |
| 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:47 |
| alf_ | mardy: ok, just to be sure can you confirm that XDG_RUNTIME_DIR is set properly? | 13:49 |
| mardy | alf_: yes, it's correct | 13:50 |
| 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:52 |
| alf_ | mardy: alternatively export APP_DESKTOP_FILE_PATH=<desktop-file> | 13:53 |
| 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:57 |
| dednick | mardy: looking | 13:59 |
| greyback | mardy: oh, should you not be using the trusted socket: $XDG_RUNTIME_DIR/mir_socket_trusted | 14:00 |
| 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:01 |
| mardy | dednick: OK, I will try that, thanks | 14:02 |
| 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:06 |
| mardy | then it's working fine :-D | 14:07 |
| greyback | woo! | 14:07 |
| 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. | 14:59 |
| kdub | groot_, no, flickering is usually caused by some timing problems that are tricky to pin down | 15:00 |
| 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:04 |
| qengho | I upgraded to uptopic on my machine. My xmir buffer n-1 problem is gone, yay. | 15:10 |
| qengho | mir test clients don't run, though. mir_demo_client_basic #-> Assertion `mir_connection_is_valid(mcd.connection)' failed. | 15:15 |
| racarr | Good morning | 15:21 |
| racarr | delayed standup is mostlyu studying inpout resampling | 15:22 |
| === dandrader is now known as dandrader|afk | ||
| alan_g | qengho: what are you using as the Mir server? Is it publishing an endpoint at $XDG_RUNTIME_DIR/mir_socket? | 15:27 |
| qengho | alan_g: There is no socket. What am I using? Er, xmir, I think. | 15:28 |
| alan_g | XMir is an X11 server, not a Mir server - so I wouldn't expect it to support Mir clients. | 15:29 |
| qengho | Oh. I'm using regular desktop on Utopic. I have a client I wish to test. What's the best way? | 15:36 |
| 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:39 |
| 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:40 |
| alan_g | qengho: http://unity.ubuntu.com/mir/using_mir_on_pc.html | 15:41 |
| qengho | alan_g: thanks. | 15:42 |
| 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. | 15:43 |
| 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:34 |
| racarr | which I just did with the branch on a clean mako... | 16:35 |
| 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:41 |
| 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:42 |
| racarr | https://launchpad.net/~chris.gagnon/+archive/ubuntu/mir-demo-tester perhaps | 16:43 |
| robotfuel | racarr: that doesn't use autopilot, I think that needs the mir-demos or mir-test-tools package to be installed | 16:45 |
| === dandrader|afk is now known as dandrader | ||
| 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:47 |
| 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:49 |
| robotfuel | racarr: mir-demo-tester is in my ppa. it's not in the archive. | 16:50 |
| === alan_g is now known as alan_g|EOD | ||
| 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:16 |
| 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:17 |
| 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:22 |
| kdub | racarr, yeah, thats somewhat what i'm thinking | 17:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| kdub | yeah, its about time to get that one through though | 17:34 |
| 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:35 |
| kdub | sure | 17:36 |
| * kdub grumbles about GLRenderer | 17:37 | |
| kdub | i think there should be SceneElements::with_shell_data(std::function<void(std::shared_ptr<void>)> const&) | 17:39 |
| 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:40 |
| racarr | maybe... | 17:43 |
| 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:45 |
| racarr | see between qtmir and demo-shell | 17:47 |
| 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:49 |
| 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:50 |
| racarr | I mean with respect to the renderables it almost is right there is a certain serializable input stream | 17:51 |
| racarr | i.e. {buffer: 3, geometry: some rectangle} | 17:52 |
| 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:53 |
| 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:54 |
| racarr | but maybe that's not really particularly meaningful :) | 17:55 |
| === dandrader is now known as dandrader|afk | ||
| Nothing_Much | Are there problems with running XMir with the Oibaf PPA on Radeon APUs? | 19:09 |
| 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:33 |
| racarr | hmm | 20:41 |
| === dandrader|afk is now known as dandrader | ||
| 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:45 |
| racarr | render take | 20:46 |
| racarr | SceneElementSequence | 20:46 |
| racarr | then the API to compositor becomes very clumsy...i.e. | 20:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| racarr | the entire point of moving is_a_surface toSceneElement | 20:50 |
| racarr | is invalidated | 20:50 |
| racarr | the thing is I think the inheritance of implementation | 20:57 |
| racarr | from GLRenderer->DemoRenderer is weird | 20:57 |
| 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:58 |
| racarr | it wants to share the code to draw a rectangle* | 20:59 |
| kdub | right | 21:00 |
| racarr | I think I am going to hack around it in demo renderer | 21:01 |
| racarr | rather than make any mir interfaces weirder | 21:01 |
| racarr | i.e. DemoRenderer::begin(std::set<mg::Renderable::ID> const& renderable_ids_not_to_decorate) | 21:02 |
| racarr | lol... | 21:02 |
| racarr | unordered_set even | 21:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| kdub | hah, yeah | 21:07 |
| 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:41 |
| 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:43 |
| 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:44 |
| racarr | oh | 23:45 |
| racarr | yeah | 23:45 |
| racarr | hmm | 23:45 |
| racarr | what does it mean | 23:46 |
| 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:47 |
| RAOF | Stupid bloody code bloody bloody grumble mumble grumble... | 23:49 |
| RAOF | Why do you leak, damnit?! | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!