| === duflu_ is now known as duflu | ||
| RAOF | Ah, bollocks. | 04:17 |
|---|---|---|
| RAOF | umockdev doesn't handle marking fds as readable, so poll/select/epoll etc don't. | 04:18 |
| RAOF | Which is why I'm not getting any events. | 04:19 |
| RAOF | HUZZAH! | 06:46 |
| duflu | w00t? Bah. | 07:17 |
| anpok | alf__: could you have a look at https://code.launchpad.net/~andreas-pokorny/mir/report-namespace/+merge/205577 | 08:24 |
| alf__ | anpok: sure, I have it in my list for this morning | 08:25 |
| duflu | alf__: Also https://bugs.launchpad.net/mir/+bug/1281938 ? :) | 08:37 |
| alf__ | duflu: I wonder if calling glFinish() on the client has any effect (it shouldn't be needed since we are swapping the buffers, but...) | 08:42 |
| duflu | alf__: Yeah, haven't tried | 08:42 |
| duflu | Now checking the old SessionMediator | 08:42 |
| alf__ | duflu: Also if this is not present on Android, it could indicate a problem with our Mesa mir egl | 08:50 |
| duflu | alf__: Yeah, I'm completely unfamiliar with that | 08:50 |
| duflu | Although we should have seen this bug sooner. Might have to try older Mesa | 08:51 |
| duflu | alf_: Put a huge delay in the client. And the server still shows an old frame immediately, much sooner than the client has posted the frame. Somehow the compositor thinks it's been given a frame before it has | 09:10 |
| alf__ | duflu: strange | 09:13 |
| duflu | Which is weird, because just asking the server it shows it doesn't post until it gets a next_frame. Seems like perhaps the client is next_frame'ing prematurely | 09:14 |
| anpok | I believe mterry was looking into that topic last week | 09:16 |
| anpok | or is that bug ticket the result of that? | 09:16 |
| duflu | anpok: One is an enhancement request, the other is a bug :) | 09:27 |
| duflu | So they're still separate for now | 09:28 |
| duflu | alf__: Found the problem, but still don't understand the why. Mesa has decided that eglCreateWindowSurface will trigger a surface_advance_buffer immediately | 09:28 |
| alf__ | duflu: hmm, sounds like an issue in our mesa mir egl layer | 09:30 |
| duflu | alf__: Yep. But I'm still surprised I never saw it before | 09:30 |
| alf__ | duflu: so, looking at https://github.com/RAOF/mesa/blob/egl-platform-mir/src/egl/drivers/dri2/platform_mir.c , we do a mir_advance_colour_buffer() @ line 201 when creating the egl surface | 09:33 |
| alan_g | duflu: is that what is causing 1280842? | 09:33 |
| duflu | alf__: Excellent. Well if it's needed then we need to tell BasicSurface to ignore the first 2, not the first 1. Otherwise fix Mesa | 09:33 |
| duflu | alan_g: Looks possible. But I'd like to keep the enhancement request separate to the bug report | 09:34 |
| alan_g | duflu: sure - especially until it is proven | 09:35 |
| duflu | alan_g: I mean we wouldn't implement the enhancement if it's just a bug to fix | 09:35 |
| alan_g | ack | 09:36 |
| alf__ | duflu: MirMesaEGLNativeSurface only has surface_advance_buffer)(MirMesaEGLNativeSurface* surface, 50 MirBufferPackage* buffer_package) | 09:38 |
| alf__ | duflu: which means that the only way mesa can currently get the buffer package is to advance the buffer | 09:38 |
| duflu | alf__: Yeah I figured there was a reason. But still, buggy :) | 09:38 |
| alf__ | duflu: so we need to fix that, so that that advancing and getting the buffer package are separate operations, like in the client api | 09:39 |
| alan_g | Or at least have it return the buffer it already has | 09:40 |
| alf__ | alan_g: what do you mean? | 09:40 |
| anpok | at the first call of surface_advance_buffer let it behave like "get buffer package"? | 09:41 |
| alan_g | alf__: it is a bad solution - but the first call to surface_advance_buffer() could just return the current buffer | 09:41 |
| alf__ | alan_g: well, I wouldn't want to use this as our final solution, but it makes a good quick test to validate our hypothesis | 09:44 |
| duflu | Yep, that seems to be how software surfaces work around it | 09:45 |
| alan_g | alf__: yep | 09:45 |
| duflu | On the other hand, I can't see how that's safe. It requires buffer_depository->current_buffer() which dereferences an empty front() value (end()) | 09:48 |
| duflu | Oops, not end() but it should throw | 09:48 |
| alf__ | duflu: when the surface is created, it sends a buffer to the client, so that should be saved in the depository. Do you mean something different? | 09:50 |
| duflu | Oh, I see. We do a dummy process_incoming_buffer on startup to ready the depository | 09:51 |
| alf__ | duflu: it's not a dummy operation, there is a buffer there for real. | 09:54 |
| duflu | alf__: Semantics... Anyway I think I have a simple workaround for mirclient | 09:54 |
| duflu | Sigh. That's enough. Net zero bug progress. One found, one fixed. | 10:14 |
| alan_g | anpok: there are some merge conflicts to fix and then we can finally land: https://code.launchpad.net/~andreas-pokorny/mir/report-namespace/+merge/205577 | 11:44 |
| === pete-woods is now known as pete-woods-lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === dandrader is now known as dandrader|afk | ||
| === alan_g|lunch is now known as alan_g | ||
| === dandrader|afk is now known as dandrader | ||
| === Trevinho_ is now known as Trevinho | ||
| === pete-woods-lunch is now known as pete-woods | ||
| alf__ | fginther: Hi! I want to try mir-mediumtests-trusty-touch/572 with a custom hook, is that possible? Basically, I want to enable valgrind on all architectures again for this build (i.e., remove the arch check in hook H15enable_testing), to see if everything works, before I push to trunk and amend H15enable_testing permanently. | 15:09 |
| fginther | alf__, that job specifically isn't, but the mir-team-mir-development-branch-trusty-$arch-ci can be. That should provide a sufficient test | 15:14 |
| alan_g | fginther: can we get the tests run on the clang CI build? | 15:19 |
| fginther | alan_g, this one ? https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1281591 | 15:20 |
| ubot5 | Launchpad bug 1281591 in Ubuntu CI Services "Mir build with clang doesn't run tests" [Undecided,New] | 15:20 |
| alan_g | fginther: yes | 15:20 |
| alf__ | fginther: yes, that would be sufficient. What's the best way to achieve that? (e.g. add a temporary script that enables valgrind or perhaps temporarily amend H15enable_testing, or ...?) | 15:22 |
| fginther | alf__, go ahead and prepare it as an MP to pbuilderjenkins | 15:36 |
| alf__ | fginther: ok, I will add a new script so I don't affect other builds until we are sure this is fixed | 15:37 |
| fginther | alan_g, i'll get back to you in a moment, in a meeting | 15:44 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| dednick | getting the following error on mir 0.1.5 | 15:56 |
| dednick | (process:13028): GLib-ERROR **: Creating pipes for GWakeup: Too many open files | 15:56 |
| dednick | anyone seen it before? | 15:56 |
| dednick | although i guess i'm not 100% sure it's mir that's causing it. | 15:57 |
| === dandrader is now known as dandrader|lunch | ||
| === cyphermox_ is now known as cyphermox | ||
| alf__ | fginther: https://code.launchpad.net/~afrantzis/pbuilderjenkins/mir-enable-testing-temp/+merge/207252 | 17:03 |
| === bschaefer_ is now known as bschaefer | ||
| fginther | alf__, thanks, I have a plan to test this today after lunch | 17:03 |
| alf__ | fginther: great, thanks | 17:04 |
| kdub | alf__, trying to remember, why did our mg::GLContext not have a swap_buffers() method? kinda forces us to use eglGetCurrent*() | 17:12 |
| kdub | trying to remember if that was intentional or not :) | 17:13 |
| rsalveti | alf__: hey, there's just one issue with mir trunk currently, that is not working nicely in nested mode | 17:17 |
| alf__ | kdub: none of the mg::GLContext consumers (PixelBuffer,CompositingScreencast) need it | 17:17 |
| rsalveti | alf__: and not x86 specific, got the same crash on armhf as well | 17:17 |
| rsalveti | alf__: flashing latest on my n4 and will test that as well to see if I'm able to reproduce it | 17:18 |
| alf__ | rsalveti: that's with the android platform or mesa? | 17:18 |
| rsalveti | alf__: android platform | 17:18 |
| rsalveti | alf__: http://paste.ubuntu.com/6957542/ | 17:19 |
| rsalveti | this is with the armhf emulator | 17:19 |
| rsalveti | alf__: and with the x86 one: http://paste.ubuntu.com/6952522/ | 17:20 |
| rsalveti | alf__: http://paste.ubuntu.com/6951930/ | 17:20 |
| kdub | alf__, I have a place where it would be useful to android... debating putting swap_buffers() in mg::GLContext or making a mga::SwappingGLContext interface | 17:20 |
| rsalveti | alf__: in case you want to try the x86 emulator https://plus.google.com/+RicardoSalveti/posts/1u7HSYjF2He | 17:20 |
| rsalveti | to use nested mode, just install ubuntu-touch-session from the archive (downgrade the package) | 17:21 |
| rsalveti | as I had to disable it in a ppa for now, to get unity8 to work | 17:21 |
| alf__ | rsalveti: ok, can you please file a bug about this? | 17:25 |
| rsalveti | alf__: sure | 17:26 |
| === dandrader|lunch is now known as dandrader | ||
| rsalveti | alf__: bug 1282248 | 20:12 |
| ubot5 | bug 1282248 in Mir "Unity8 crashes when using latest mir/android backend with system-compositor" [Undecided,New] https://launchpad.net/bugs/1282248 | 20:12 |
| rsalveti | kgunn: from the mir perspective, I guess this is the last remaining blocker for the x86 emulator | 20:12 |
| rsalveti | kgunn: also know that without fixing this issue, we can't land current mir/devel, as it also affects every device | 20:13 |
| rsalveti | just a heads up | 20:13 |
| === dandrader is now known as dandrader|afk | ||
| kgunn | rsalveti: ack,thanks...i'll get someone on it | 20:25 |
| rsalveti | thanks | 20:26 |
| fginther | kgunn, can someone help me with https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1281591 ? I'm trying to figure out the correct build configuration to trigger running of the tests | 22:49 |
| ubot5 | Launchpad bug 1281591 in Ubuntu CI Services "Mir build with clang doesn't run tests" [Undecided,New] | 22:49 |
| === dandrader|afk is now known as dandrader | ||
| kgunn | racarr: can you help fginther ? | 23:08 |
| racarr | kgunn: fginther: Hi :) | 23:10 |
| racarr | so the default build options should enabe running the tests | 23:10 |
| racarr | so the way I thought it was set up was just the amd64 job runs ctest | 23:10 |
| racarr | and the clang job | 23:10 |
| racarr | omits it | 23:10 |
| racarr | RAOF: p.s. about my recent user data mp...I have this vague memory of you talking with Gerry | 23:11 |
| racarr | and agreeing that surface user data was reasonable XD | 23:11 |
| racarr | 1. Was that a dream. | 23:11 |
| racarr | 2. Do you remember the context? | 23:11 |
| fginther | racarr, thanks | 23:17 |
| fginther | racarr, thanks, it appears to be working: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-trusty-amd64-build-fjg/5/console | 23:37 |
| RAOF | racarr: I don't recall that conversation with Gerry. | 23:38 |
| RAOF | racarr: When would this have been? | 23:38 |
| racarr | RAOF: Haha cest la vie | 23:38 |
| racarr | I think in london | 23:38 |
| RAOF | Ah. | 23:38 |
| racarr | dont worry about all I remember | 23:38 |
| racarr | is this image of you being like So some sort of user data...thats reasonable | 23:38 |
| racarr | :p | 23:39 |
| RAOF | I certainly discussed a bunch of things with Gerry, and I'm not generally opposed to user data thingies :) | 23:39 |
| racarr | just collecting thoughts | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!