[03:06] RAOF: oh hm kernel 3.12 [03:07] anpok: Oh, yeah. Forgot about that. It'd be easy enough to provide a less-efficient work-around, though. (uinput via libevdev) [03:08] Or maybe, just maybe, the phone platforms we need this on will use a kernel less than two years old! [03:10] seems simple to backport [03:10] Also true. [03:24] Now with bonus Xorg crash! === alf is now known as alf_ [06:27] Heh. I love the juxtaposition of https://code.launchpad.net/~alan-griffiths/mir/simplify-connect-code/+merge/268740/comments/675948 with https://code.launchpad.net/~vanvugt/mir/fix-1476201/+merge/268693/comments/675947 :) [06:40] uu mir 0.15 in wily [06:40] too bad wily is broken X-( [06:48] Shouldn't be (anymore) [07:02] RAOF: Do as I say, not as I do [07:03] Generally I don't mean to me contradictory. It just sounds that way if I fail to communicate adequately [07:04] Woo, Mir 0.15.0 is done. Unfortunately even with that large bug count subtracted the backlog remains over 300 now [07:12] duflu: Yeah; writing code that's readable for other people is hard (which is one reason why we have reviews ☺) [07:13] RAOF: I still wish we could get more reviewers. mir-team feels statistically not quite significant and we sway with confirmation bias (and mood) a lot [07:15] Or even better: testers(!) [07:18] Eh, testers solve a different problem [07:18] RAOF: They would solve one problem, of reviewers approving things that actually don't work :) [07:19] Well, reduce it :) [07:22] An interesting observation I made years ago (and continues to be true throughout the world) is that some projects without code review actually yield higher quality. It's a matter of being able to achieve a sufficiently high throughput that your average number of fixes significantly outweighs the regressions. [07:23] There is risk of course, but that can be mitigated with long release cycles and branching (which Ubuntu doesn't quite accommodate) [07:34] Although I only remember that working when there actually was a dedicated test team. And more full-time testers of the code than developers === marcusto_ is now known as marcustomlinson [08:56] Umm, Jenkins is over-eager now: https://code.launchpad.net/~vanvugt/mir/merge-distro-changelog-0.15.0/+merge/268884 [12:50] alf_: you're on wily - could you check which libmirclient .so is used by glmark2-es2-mir? (I'm at the pocketdesktop sprint with only vivid to hand) [12:50] alan_g: sure [12:54] http://paste.ubuntu.com/12183271/ <- does anyone know what this error means? i can't seem to launch a u8 session [12:54] alan_g: libmirclient.so.9 [12:56] Hello! [12:56] are there any nVidia Mir drivers yet? [12:56] alf_: that's good, thanks. (Now I just have to double check overlay) [12:57] zzarr, mir runs on nouveau [12:59] okey, so they are not finished yet I guess [13:01] zzarr: yes.. time will tell if they will settle gbm .. [13:01] or they might continue with their own path.. and expose something along the lines of the egl streams extension [13:02] attente: what versions of mir packages do you have? (e.g. dpkg -l '*mir*' | grep '^ii' ) [13:03] anpok, thanks [13:55] vogons, reviews of https://code.launchpad.net/~kdub/mir/fix-1487967/+merge/268908 ? [13:55] kdub: I'm trying to track down a CI problem on mako and am seeing " MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use" in src/platforms/android/client/gralloc_registrar.cpp. (This is running glmark - which hangs.) Is this error likely to be significant? [13:55] kdub: will look [13:55] alan_g, sounds like https://bugs.launchpad.net/mir/+bug/1441553 [13:55] Ubuntu bug 1441553 in Mir "[regression] Screen flickering and error messages on Android overlay surfaces: MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use" [High,In progress] [13:56] which happens when overallocation occurs, there's a quick fix in there to try out (increase mf::client_buffer_cache_size) [13:57] basically, the client and server don't agree on how many buffers are around, which android has a hard time with [13:57] kdub: would that be causing a hang? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/6354/console [13:58] I guess its not unfathomable that it could [13:58] OK, what's a good size to try? [13:59] probably 4 (nbuffers + 1) [14:17] alf_: thanks, i had two different versions installed [14:17] attente: np [14:20] kdub: the "quick fix" seems to fix my problem locally. (I assume it isn't a good thing to add to my MP though.) [14:22] the bad side effect with the cache size being 4 is that we can potentially have 2 old buffers lingering on the client client side [14:22] and, its in progress because with nbs, the client and server agree on the buffer count [14:25] but, I guess the side effect is better than the symptoms [14:25] its not a regression, but a problem with the overallocation feature of BufferQueue... so reverting that is another solution [14:27] OK, I'll add to the MP with a dirty great TODO and see if it also works in CI [14:32] alan_g, ack, sounds good [14:42] kdub: Like this? LL90-93 https://code.launchpad.net/~alan-griffiths/mir/fix-1486496/+merge/268747 [17:23] anpok, im not at the sprint :) [17:24] anpok, and yeah revoking the fds could be an issue ... as well as adding the changes in relative mouse... possibly RAOF has ideas on that? [17:25] bschaefer: RAOF pointed me to a ioctl in evdev to do that.. just read about it last night.. since kernel 3.12 [17:26] so atm not available in touch kernels.. [17:26] but it was made for us :) in an embarssing way [17:26] i am off for a moment [17:26] thats nice :) [17:26] anpok, are we still focusing on dbus as well? [17:26] then trying to implement the fd? [17:26] passing [17:28] yes usc-dbus interface .. and later a input configuration / introspection .. through mirclient [17:28] the chances for fd passing to happen have declined.. [17:28] sweet [17:28] * bschaefer goes to figure out how dbus works [17:28] never actually used it for the most part :) === JanC_ is now known as JanC