anpokRAOF: oh hm kernel 3.1203:06
RAOFanpok: Oh, yeah. Forgot about that. It'd be easy enough to provide a less-efficient work-around, though. (uinput via libevdev)03:07
RAOFOr maybe, just maybe, the phone platforms we need this on will use a kernel less than two years old!03:08
anpokseems simple to backport03:10
RAOFAlso true.03:10
RAOFNow with bonus Xorg crash!03:24
=== alf is now known as alf_
RAOFHeh. 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:27
guest42315uu mir 0.15 in wily06:40
guest42315too bad wily is broken X-(06:40
RAOFShouldn't be (anymore)06:48
dufluRAOF: Do as I say, not as I do07:02
dufluGenerally I don't mean to me contradictory. It just sounds that way if I fail to communicate adequately07:03
dufluWoo, Mir 0.15.0 is done. Unfortunately even with that large bug count subtracted the backlog remains over 300 now07:04
RAOFduflu: Yeah; writing code that's readable for other people is hard (which is one reason why we have reviews ☺)07:12
dufluRAOF: I still wish we could get more reviewers. mir-team feels statistically not quite significant and we sway with confirmation bias (and mood) a lot07:13
dufluOr even better: testers(!)07:15
RAOFEh, testers solve a different problem07:18
dufluRAOF: They would solve one problem, of reviewers approving things that actually don't work :)07:18
RAOFWell, reduce it :)07:19
dufluAn 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:22
dufluThere is risk of course, but that can be mitigated with long release cycles and branching (which Ubuntu doesn't quite accommodate)07:23
dufluAlthough I only remember that working when there actually was a dedicated test team. And more full-time testers of the code than developers07:34
=== marcusto_ is now known as marcustomlinson
dufluUmm, Jenkins is over-eager now: https://code.launchpad.net/~vanvugt/mir/merge-distro-changelog-0.15.0/+merge/26888408:56
alan_galf_: 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
alf_alan_g: sure12:50
attentehttp://paste.ubuntu.com/12183271/ <- does anyone know what this error means? i can't seem to launch a u8 session12:54
alf_alan_g: libmirclient.so.912:54
zzarrare there any nVidia Mir drivers yet?12:56
alan_galf_: that's good, thanks. (Now I just have to double check overlay)12:56
guest42315zzarr, mir runs on nouveau12:57
zzarrokey, so they are not finished yet I guess12:59
anpokzzarr: yes.. time will tell if they will settle gbm ..13:01
anpokor they might continue with their own path.. and expose something along the lines of the egl streams extension13:01
alf_attente: what versions of mir packages do you have? (e.g. dpkg -l '*mir*' | grep '^ii' )13:02
zzarranpok, thanks13:03
kdubvogons, reviews of https://code.launchpad.net/~kdub/mir/fix-1487967/+merge/268908 ?13:55
alan_gkdub: I'm trying to track down a CI problem on mako and am seeing "<ERROR> 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
alan_gkdub: will look13:55
kdubalan_g, sounds like https://bugs.launchpad.net/mir/+bug/144155313:55
ubot5Ubuntu bug 1441553 in Mir "[regression] Screen flickering and error messages on Android overlay surfaces: <ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use" [High,In progress]13:55
kdubwhich happens when overallocation occurs, there's a quick fix in there to try out (increase mf::client_buffer_cache_size)13:56
kdubbasically, the client and server don't agree on how many buffers are around, which android has a hard time with13:57
alan_gkdub: would that be causing a hang? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/6354/console13:57
kdubI guess its not unfathomable that it could13:58
alan_gOK, what's a good size to try?13:58
kdubprobably 4 (nbuffers + 1)13:59
attentealf_: thanks, i had two different versions installed14:17
alf_attente: np14:17
alan_gkdub: the "quick fix" seems to fix my problem locally. (I assume it isn't a good thing to add to my MP though.)14:20
kdubthe bad side effect with the cache size being 4 is that we can potentially have 2 old buffers lingering on the client client side14:22
kduband, its in progress because with nbs, the client and server agree on the buffer count14:22
kdubbut, I guess the side effect is better than the symptoms14:25
kdubits not a regression, but a problem with the overallocation feature of BufferQueue... so reverting that is another solution14:25
alan_gOK, I'll add to the MP with a dirty great TODO and see if it also works in CI14:27
kdubalan_g, ack, sounds good14:32
alan_gkdub: Like this? LL90-93 https://code.launchpad.net/~alan-griffiths/mir/fix-1486496/+merge/26874714:42
bschaeferanpok, im not at the sprint :)17:23
bschaeferanpok, 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:24
anpokbschaefer: RAOF pointed me to a ioctl in evdev to do that.. just read about it last night.. since kernel 3.1217:25
anpokso atm not available in touch kernels..17:26
anpokbut it was made for us :) in an embarssing way17:26
anpoki am off for a moment17:26
bschaeferthats nice :)17:26
bschaeferanpok, are we still focusing on dbus as well?17:26
bschaeferthen trying to implement the fd?17:26
anpokyes usc-dbus interface .. and later a input configuration / introspection .. through mirclient17:28
anpokthe chances for fd passing to happen have declined..17:28
* bschaefer goes to figure out how dbus works17:28
bschaefernever actually used it for the most part :)17:28
=== JanC_ is now known as JanC

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!