[00:38] <camako> 0.6.1 ppa ready in silo 4... This is a mir only landing (no ABI breaks)... Here are the instructions for testing... http://pastebin.ubuntu.com/8049567/
[02:50] <racarr> camako: A landing without ABI breaks?!?!
[02:50] <racarr> *choirs of angels sing*
[02:58] <camako> I'm sure we have broken something... Just not the ABIs :-)
[03:01] <racarr> "Didn'
[03:02] <racarr> t break the ABI. Diodn't break the ABI. There may be a few bad commits. But I didn't break the ABI" to the tune of https://www.youtube.com/watch?v=3TY8vLI4buo
[03:02] <racarr> ...that's all...
[03:02] <racarr> :p
[03:14] <camako> :-) "There ain't no bugs in Mir" would work too...
[03:23] <duflu> Anyone else notice how stable the "8" in libmirclient8 is? :)
[03:26] <duflu> libmirclient has the luxury of C to keep in stable. But C++ can be just as stable... we're just not there yet. I suspect we could still move a bunch of headers out of include/ and into src/ so they don't contribute to any ABIs any more
[03:30] <duflu> camako: In exciting news, I think I've got the "butter" branch where I want it. Seems to improve the usability of the phone quite nicely
[03:32] <camako> duflu, sounds good.. Folks can start reviewing, then
[03:32] <duflu> I had to sacrifice a little bit of lag to get scrolling up from 48Hz to 60Hz, but it feels nicer now
[03:33] <duflu> Still, much less laggy than the phone is right now
[03:34] <camako> duflu, nice! I think you can empirically tell the difference, right? Any caveats?
[03:35] <duflu> camako: Yes, it's all based on human eyes now. No caveats any more, just improvement :)
[03:36] <camako> ok good... let's hope for a smooth review :-)... If you can generate some before and after numbers, it'd help the review process
[03:36] <duflu> You may also find MIR_CLIENT_INPUT_RECEIVER_REPORT now mentions negative lag for some input events. This is correct, because they're predicted a few milliseconds into the future
[03:36] <camako> hah interesting
[03:38] <camako> hey I saw you marked some 0.7.0 targeted bugs as "Fix released"... I had done some too.... thanks for that...
[03:39] <racarr> duflu: I think...there are a few problems
[03:39] <racarr> with the branch, but im not 100% finished studying yet
[03:39] <racarr> but I think, if you look at
[03:39] <racarr> droidinput::MotionEvent and
[03:40] <racarr> the way historical pointer coordinates are added
[03:40] <racarr> where 1 event will include
[03:40] <racarr> multiple pointer coordinate samples over time
[03:40] <racarr> I think the likely effect of the branch is to
[03:41] <camako> Hmmm this failed twice now if anybody wants to take a look : https://code.launchpad.net/~mir-team/mir/0.6/+merge/230879/comments/561324
[03:41] <racarr> drop half of pointer samples
[03:41] <racarr> hence why you see
[03:41] <racarr> something close to 50 fps (half the 100hz input rate of most touch screens)
[03:41] <racarr> and then I have no clue where the 60hz is coming from. but may be close to coincidental from the 48hz because of the frame time tweaking
[03:42] <racarr> the idea with the resampling is
[03:42] <racarr> because of the mixed refresh rate of the monitor and the input device
[03:42] <racarr> sometimes you will get
[03:42] <racarr> frames where you have two touch samples
[03:42] <racarr> which, say in the case of a scroll, means a greater scroll
[03:43] <duflu> racarr: That was true for the old branch. The new one has consumeBatches=true and a sample window that moves every 16ms. Hence 60Hz
[03:43] <racarr> per frame
[03:44] <duflu> racarr: So essentially you have all the raw events from during the frame contributing to a single prediction, single cooked event
[03:45] <duflu> Devices seem to vary a lot. Nexus4 produces events at 96Hz whereas my mouse is 125Hz
[03:45] <racarr> no
[03:45] <racarr> its multiple interpolated pointer samples
[03:45] <racarr> in one event
[03:45] <racarr> and we are ignoring all
[03:45] <racarr> except the last
[03:45] <duflu> racarr: OK, if you've got a practical suggestion for improvement that works please put it in the review
[03:46] <racarr> duflu: I am still studying like I said...just wanted to fill you in one what I had learned
[03:46] <racarr> duflu: The thing is...ok so if you imagine a scroll
[03:46] <racarr> then you can think of say, the displacement, which on a given frame, i.e. how far it drags behind
[03:46] <racarr> the finger
[03:47] <racarr> so the way your branch is configuring things, is lowering
[03:47] <racarr> the minimum value of the displacement (i.e. the latency)
[03:47] <racarr> on the other hand, butter on android, intentionally suffers
[03:47] <racarr> 1 frame latency in order to be able to
[03:48] <racarr> resample the 100hz display smoothly to frame time, such to
[03:48] <racarr> minimize the CHANGE in the displacement
[03:48] <racarr> which is like jerk, or some such.
[03:49] <duflu> racarr: Yes, I realized I had to suffer one extra frame of latency to make the batch size sufficiently big for a nice experience.
[03:49] <duflu> That's the big change in yesterday's version
[03:50] <duflu> The new version does indeed minimize the change in displacement (slightly higher latency but smoother scrolling)
[03:52] <racarr> I think it's dropping most touch samples though -.-
[03:53] <duflu> racarr: The raw samples are all used in InputConsumer to affect the resampled curve. Where is the "drop"?
[03:53] <racarr> duflu: http://developer.android.com/reference/android/view/MotionEvent.html
[03:53] <racarr> For efficiency, motion events with ACTION_MOVE may batch together multiple movement samples within a single object. The most current pointer coordinates are available using getX(int) and getY(int). Earlier coordinates within the batch are accessed using getHistoricalX(int, int) and getHistoricalY(int, int). The coordinates are "historical" only insofar as they are older than the current coordinates in the batch; however, they ar
[03:53] <racarr> its
[03:53] <racarr> interpolate
[03:53] <racarr> not extrapolate :)
[03:54] <racarr> the drop is
[03:54] <racarr> clients want 100hz or so of touch samples for computing
[03:54] <racarr> acceleration, like the device has
[03:55] <duflu> racarr: I can see some clients might want a configurable option to get the raw event stream. But are you saying that the cooked event stream should be faster than the frame interval?
[03:56] <duflu> That's a nice ideal, but I'm not sure InputConsumer works that way..?
[03:56] <racarr> I'm pretty sure it does ;)
[03:56] <racarr> I mean thats how we are using it the only problem is
[03:56] <racarr> we are literally ignoring the historical pointer coords.
[03:57] <racarr> which would give us
[03:57] <racarr> the 100hz rate
[03:57] <racarr> I think we would find if we enabled the 100hz rate without
[03:57] <racarr> proper frame timing
[03:57] <racarr> the jerk would come back
[03:57] <racarr> because we would have the problem where
[03:57] <racarr> you get multiple events per frame
[03:58] <duflu> racarr: I'm still a bit confused. I would really like to get a higher cooked event rate. If you know how to do it without the experience degrading (for me it mostly means no resampling benefit) then please point out the required code changes
[03:59] <racarr> I think the answer is use the historical coordinates + real frame timing :) but
[03:59] <duflu> It's easy to deliver events to clients faster. But so far that always means a worse looking experience
[03:59] <racarr> im still trying to figure it out completely
[04:00] <duflu> racarr: I would love to get a merge proposal for any improvements to try out
[04:01] <duflu> Although I might ignore that branch for the week now. Not enough time left to dive back in. It usually sucks me in for days at a time of obsessive testing
[04:03] <racarr> :) ill have something next week
[04:04] <racarr> im going to try and work up a test that lets you pick a
[04:04] <racarr> refresh rate and an input streaming rate
[04:04] <racarr> and then simulates a smooth scroll
[04:04] <racarr> and measures
[04:04] <racarr> the displacement from "ideal scroll"
[04:04] <racarr> and then we can automatically test various
[04:04] <racarr> parameters, etc.
[04:04] <racarr> I mean obviously still some manual testing will be required but
[04:05] <racarr> it should give us a nice method to be sure we are making things better
[04:05] <duflu> Yeah, some trustworthy automation would be good. I've developed a distrust of the input latency metrics we have right now
[04:07] <duflu> Kind of like the bogus "render time" argument :)
[04:07] <duflu> We need to work on building more reliable metrics
[04:09] <racarr> Yeah...its hard :( lol
[04:09] <racarr> android and ios arent exactly jumping to publish their
[04:09] <racarr> tips and tricks on accelerating
[04:09] <racarr> your input stack
[04:09] <racarr> hahaha
[04:10] <racarr> *pictures cosmo magazine at grocery store checkout: 10 tips and tricks for accelerating your input stack*
[04:10] <RAOF> Bah. Our CI fails in the most inscrutable way. The thing passes the tests _locally_, damnit.
[04:11]  * duflu needs to fix up and get his client perf report branch for review. That makes a good start
[05:58] <RAOF> Why is cmake such unmitigated garbage?!
[06:01] <duflu> RAOF: Because it's an evil conspiracy to annoy you
[06:01] <duflu> DMake is better
[06:01] <duflu> And EMake will solve everything
[06:03]  * duflu misses pure GNU make. Unfortunately it's too sharp an instrument that people constantly cut themselves on it
[06:03] <duflu> Or just mess it up
[13:23] <kdub> alan_g, I'm thinking about: https://code.launchpad.net/~kdub/mir/testable-surface-tracking/+merge/230814/comments/561452
[13:24] <alan_g> kdub: not clear? Sorry
[13:24] <kdub> well, no, clear enough
[13:24] <kdub> I guess i'm just thinking about testing now
[13:25] <kdub> and how SessionMediator test is really somewhat of an integration test
[13:25] <kdub> or rather, if we did hoist the SessionSurfaceTracker, it would be more of an integration test
[13:26] <kdub> of two objects composed together
[13:26] <kdub> and am wondering if you thought that was wrong-headed thinking
[13:26] <alan_g> Not so - it would simply not test their interaction
[13:27] <alan_g> And I don't think we need to require that interaction
[13:29] <alan_g> Analogy: "vector" gets tested. Vector gets used in cache. We don't test that cache uses vector a specific way. Just that it works.
[13:29] <kdub> alan_g, hmm, okay
[13:30] <kdub> I'll keep thinking about it, but it seems reasonable
[13:30] <kdub> and a good, small way to shift my own thinking about tests
[13:30] <kdub> thanks
[13:30] <alan_g> yw
[13:31] <alan_g> And the comment doesn't say the MP is wrong, just suggests that it could be an interface too far.
[13:32] <kdub> sure, I'm beginning to think that too
[16:17] <mibofra> hi guys, can anyone help me to start mir/lightdm on ubuntu touch? (http://paste.ubuntu.com/8054602/ the log)
[16:19] <greyback_> mibofra: that's not a very useful log, what has  /var/log/lightdm/unity-system-compositor.log ?
[16:19] <alan_g> Hmm "[+1.16s] DEBUG: Process 25466 terminated with signal 11" - a segfault doesn't look promising
[16:20] <greyback_> mibofra: what device are you testing it on?
[16:21] <mibofra> greyback_, http://paste.ubuntu.com/8054953/
[16:21] <mibofra> on a samsung galaxy s3 (i9300)
[16:21] <mibofra> but anyway maybe I've to explain my setup xD
[16:22] <greyback_> mibofra: I suggest for initial debugging, you install the "mir-demos" package and try out mir_demo_server_basic and see if it crashes or not. If it does crash, we'd appreciate a backtrace
[16:23] <mibofra> ok anyway
[16:25] <mibofra> greyback_, I've a strage setup. I've used to have a debian bootstrapped and chrooted on android (cyanogenomd). With debian I could start the X server (after stopped surfaceflinger), and I could use X and it worked fine, so I've decide to try with ubuntu touch
[16:25] <mibofra> in the same way
[16:25] <greyback_> mibofra: interesting!
[16:25] <mibofra> I can start pulseaudio, ping, traceroute, use apt, start dbus and more, but I can't start lightdm
[16:26] <mibofra> greyback_, my goal is to use chroot to use android as layer to support the hw
[16:26] <racarr> Good morning
[16:27] <mibofra> more or less if it will work in this way any arm7 device with android is supported by ubuntu touch
[16:28] <mibofra> and because android and the bootstrapped system share /dev /sys /proc ecc as I can see a device from chroot, if for example I use xboxdrv on ubuntu chrooted I can use the device on android for example
[16:28] <mibofra> but the only obstacle is lightdm that won't start xD
[16:29] <mibofra> (because debian with X is great, but unity fits better the smartphone that's why I wanted to try this possibility)
[16:30] <greyback_> sure. unity-system-compositor is crashing for you, which most likely means mir is crashing for some reason
[16:30] <mibofra> greyback_, anyway let's try the dem
[16:31] <mibofra> *demo
[16:31] <kgunn> you could try running the mir integration tests to just validate the android-driver working
[16:32] <mibofra> I've launched mir_demo_server_basic without options, but I can't see anything, but I don't receive errors and the applications continue to run
[16:32] <mibofra> *continues
[16:34] <mibofra> greyback_, kgunn lightdm launches also [+0.81s] DEBUG: Session pid=26012: Running command /usr/sbin/ubuntu-touch-lightdm-session ubuntu-touch-session . If I launch it I receive this: http://paste.ubuntu.com/8055058/
[16:34] <mibofra> but I can't see anything
[16:35] <mibofra> (note the upstart bridge, I'm into chroot so I can't use upstart or init or similar)
[16:35] <greyback_> mibofra: mir_demo_server_basic runs a basic mir server - it has nothing to draw yet. With it running, execute mir_demo_client_flicker or something else
[16:35] <mibofra> ok
[16:36] <greyback_> kgunn: how does one run the integration tests?
[16:36] <greyback_> I don't even know where they live
[16:36] <kgunn> greyback_: i've only ever run them in a build dir from a local native build
[16:37] <kgunn> uh...
[16:38]  * kgunn goes digging
[16:39] <mibofra> greyback_, I receive something like this and continuing http://paste.ubuntu.com/8055089/
[16:39] <mibofra> but I can't still see anything
[16:39] <kgunn> apt-get install mir-test-tools
[16:39] <kgunn> ./mir_unit_tests
[16:39] <kgunn> ./mir_integration_tests
[16:39] <kgunn> ./mir_acceptance_tests
[16:39] <mibofra> *I hope it uses the framebuffer (/dev/fb0 or /dev/grapichs/fb0) as X
[16:40] <kgunn> AndroidBufferIntegration.*
[16:40] <kgunn> Tests basic gralloc (gpu buffer allocation HAL) usage
[16:40] <kgunn> AndroidInternalClient.*
[16:40] <kgunn> tests that the unity8 surface can establish an EGL context
[16:40] <kgunn> AndroidGPUDisplay.*
[16:40] <kgunn> Tests that the primary and fallback display HAL works, and can render with OpenGLES.
[16:40] <kgunn> TestClientIPCRender.*
[16:40] <kgunn> tests that the client can receive buffers over IPC and draw to them with software and OpenGLES.
[16:40] <kgunn> mibofra: the integration & acceptance tests are the interesting ones ^
[16:41] <mibofra> ok
[16:41] <kgunn> can probably skip the unit tests
[16:41] <kgunn> kdub: ^ still accurate ?
[16:42] <camako> mibofra, you wanna stop unity8 and lightdm
[16:42] <kdub> kgunn, yes
[16:42] <camako> before starting basic server
[16:42] <mibofra> camako, they are not started
[16:42] <greyback_> camako: it wasn't even running for him
[16:42] <kgunn> camako: i think he's on a weird setup...like he's in android, chroot'd into starting ubuntu
[16:42] <kgunn> but he's got SF stopped
[16:43]  * kgunn wonders if stopping sf is enough to release the hw ?
[16:43] <alan_g> kgunn: if server_basic doesn't exit with an error it probably is
[16:44] <kgunn> yeah...and he got x to work in his chroot
[16:45] <kdub> it should be
[16:49] <mibofra> http://paste.ubuntu.com/8055122/ mir_unit_tests , http://paste.ubuntu.com/8055134/ mir_integration_tests , http://paste.ubuntu.com/8055170/ mir_acceptance_tests  but I'm not really sure if the tests were finished.
[16:49] <mibofra> (or it was only my impression as there were not other output)
[16:50] <mibofra> kgunn greyback_
[16:55] <mibofra> (there isn't a way to start unity8 on Xorg, right? just to know)
[17:09] <alan_g> A working draft of a symbol map for libmirserver is a good place to end the week. lp:~alan-griffiths/mir/initial-symbol-map-for-libmirserver
[17:17] <mibofra> kgunn, there is a config file for mir like xorg.conf for x ?
[17:19] <racarr> No, there are a few options
[17:20] <racarr> you can see mir_demo_server_basic --help for example
[17:20] <mibofra> ok
[17:20] <racarr> probably  nothing that makes it work on a device where it doesnt
[17:21] <mibofra> racarr, just to know how much it is configurable
[17:22] <mibofra> racarr, anyway a demo works
[17:22] <mibofra> mir_demo_standalone_render_to_fb
[17:22] <mibofra> kgunn
[17:23] <mibofra> I can see something on the phone
[17:23] <anpok> those are the builtin opions for default components.. you can override pretty much everything through the mirserver api
[17:23] <mibofra> ok
[17:23] <mibofra> mir_demo_standalone_render_to_fb writes on the framebuffer, right?
[17:24] <kgunn> cool you see something, and yeah
[17:25] <mibofra> kgunn, so can I force mir (with lightdm) to write on the framebuffer?
[17:26] <mibofra> uhm with mir_demo_standalone_input_filter I can have inputs form the touchscreen and more
[17:26] <kgunn> mibofra: what do you mean force ?
[17:26] <mibofra> so it works more or less
[17:27] <anpok> mibofra: hm that example uses egl/glesv2 and draws some stuff..
[17:27] <mibofra> kgunn, use the framebuffer unaccelerated
[17:27] <anpok> it is similar to a mirserver drawing with egl/glesv2
[17:27] <anpok> it is accelerated
[17:28] <mibofra> anpok, I think it's using the software rendering
[17:29] <kgunn> mibofra: no, i thot that test just writes to frame buffer directly rather than going via hwc
[17:29] <kgunn> with mir on android there's really no sw rendering afaik
[17:29] <kgunn> kdub ^ sw rendering on mir on android ?
[17:32] <mibofra> kgunn, the matter is that the drivers are loaded, android use the hw rendering, but I think X or other wants another drivers to work (for mali400 gpu there are the drivers for x)
[17:37] <racarr> mibofra: Mir has no support for software rendering via writing to /dev/fb like your X drivers are working
[17:38] <racarr> almost certainly you are using the android drivers
[17:38] <racarr> if the demo works
[17:38] <mibofra> ok
[17:38] <mibofra> racarr, the demo works
[17:38] <racarr> what about running demo_server_basic and one of the clients? e.g. mir_demo_client_fingerpaint
[17:39] <kdub> yeah, writing to the fb directly wont work
[17:39] <kdub> well, lets just say its not the path thats supported :)
[17:42] <mibofra> with mir_demo_client_fingerpaint I don't receive any output on the screen, but the executable doesn't give to me errors and it doesn't quit
[17:42] <mibofra> *if I don't stop it
[17:43] <kdub> have you tried mir_demo_standalone_render_to_fb?
[17:43] <mibofra> kdub, it works
[17:44] <kdub> oh great
[17:44] <kdub> thats the tricky part
[17:55] <mibofra> ok I'm going to have dinner
[17:55] <mibofra> see you later guys
[18:02] <racarr> :)
[18:37] <mibofra> re-hi xD
[18:38] <racarr> Lunch!
[19:32] <mibofra> kdub, racarr kgunn just for curiosity I've installed also xorg and lxde, in a glxgears test, debian used to do 60fps more or less, ubuntu touch 91 :D
[19:32] <mibofra> anyway
[19:33] <mibofra> 1|root@m0:/root # glxinfo -display :0 | grep OpenGL
[19:33] <mibofra> OpenGL vendor string: Mesa Project
[19:33] <mibofra> OpenGL renderer string: Software Rasterizer
[19:33] <mibofra> OpenGL version string: 2.1 Mesa 10.2.5
[19:33] <mibofra> OpenGL shading language version string: 1.20
[19:38] <anpok> \o/
[19:38] <anpok> what device are you using?
[19:39] <mibofra> a samsung galaxy s3
[19:39] <mibofra> the gpu is a mali 400
[19:40] <kgunn> yep good to hear
[19:54] <mibofra> uhm kgunn I get something useful (I think)
[19:55] <mibofra> kgunn, racarr, kdub http://paste.ubuntu.com/8056495/
[19:55] <kdub> mibofra, you have to use upstart
[19:55] <kdub> "service lightdm restart"
[19:56] <kdub> as the phablet user
[19:56] <mibofra> kdub, I've tried but it doesn't work
[19:56] <mibofra> kdub, it's set to autologin with phablet user
[19:56] <kdub> just running like that won't work, as it has to be started with certain arguments
[19:57] <mibofra> ok but that's lightdm : http://paste.ubuntu.com/8056507/
[19:57] <mibofra> kdub
[19:57] <kdub> well, the X server shouldn't be starting at all
[19:57] <kdub> don't know what might be going wrong there though
[19:59] <anpok> mibofra: is there no unity-system-compositor.log in /var/log/lightdm/ ?
[19:59] <mibofra> kdub, the x server start on the framebuffer
[19:59] <mibofra> anpok, yep but it isn't very useful
[20:00] <mibofra> anpok, it's this http://paste.ubuntu.com/8056543/
[20:01] <mibofra> (anyway, if you have anything more important to I can leave :) , just I won't to disturb)
[20:01] <mibofra> *I don't want disturb
[20:02] <mibofra> (xchat autocorrect xD fantastic)
[20:03] <anpok> you could pretend being lightdm .. by calling unity-system-compositor with --from-dm-fd 0 --to-dm-fd 1 if you want to debug that
[20:05] <mibofra> anpok, in fact I don't pretend the problem it's light xD
[20:05] <mibofra> but I've to use light to launch it, that's the poin
[20:05] <mibofra> *point
[20:05] <anpok> why is that a problem?
[20:09] <mibofra> anpok, it isn't a problem, I like also the startx approach, so I don't have to use a display manager to run the display server. But mir is really all the package display manager + libraries + greeter
[20:16] <anpok> mir provides the libraries for that.
[20:21] <mibofra> anyway some demos works anpok kdub like the framebuffer one
[20:22] <mibofra> some like mir_demo_client_eglflash go in segfault
[20:22] <anpok> mibofra: try launching mir_demo_server_shell --file /tmp/somwhere  ... then mir_demo_client_eglfingerpaint -m /tmp/somewhere
[20:22] <kdub> mibofra, the framebuffer one drives the display via HWC
[20:23] <kdub> not the /dev/fb0
[20:23] <mibofra> kdub, I've understood
[20:25] <mibofra> anpok, I can find the mir_demo_client_fingerpaint not the egl one
[20:25] <anpok> oops
[20:25] <anpok> typo
[20:25] <mibofra> ah ok
[20:27] <mibofra> anpok, anyway I launch a test like this one and I don't receive errors or similar, only the binary that keeps running without output on the screen
[20:27] <anpok> oh
[20:28] <mibofra> eh anpok , the only demo that works with an output on the screen is mir_demo_standalone_render_to_fb at the moment
[20:36] <anpok> mibofra: to solve that you need a few hours out of kdub or AlbertA
[20:36] <mibofra> fantastic xD
[20:37] <mibofra> anpok, and if they want
[20:46] <kdub> mibofra, try
[20:46] <kdub> ./mir_demo_server_basic --launch-client "./mir_demo_client_egltriangle"
[20:51] <mibofra> ok
[20:52] <mibofra> kdub, sh: 1: ./mir_demo_client_egltriangle: not found
[20:52] <kdub> probably in /usr/bin
[20:52] <mibofra> ah lol ok don't worry
[20:53] <mibofra> yes I didn't see the point kdub sorry
[20:53] <mibofra> kdub, Current active output is 720x1280 +0+0
[20:53] <mibofra> Server supports 3 of 6 surface pixel formats. Using format: 2
[20:53] <mibofra> Surface 0 DPI
[20:53] <mibofra> but I don't see anything
[20:53] <kdub> okay, so something is locking up probably
[20:55] <kdub> try adding --msg-processor-report log to the end and pastebinning the out
[20:57] <mibofra> kdub, --msg-processor-report on/1 or similar?
[20:58] <mibofra> only adding the option I get the help.
[20:58] <mibofra> with --msg-processor-report 1 or on I get segfault
[20:58] <kdub> has to be "log"
[20:59] <mibofra> kdub, yep I've noticed now that on the help
[21:00] <mibofra> kdub, http://paste.ubuntu.com/8057321/
[21:00] <kdub> hmm, so the client's blocking
[21:00] <kdub> could you pastebin /system/bin/logcat?
[21:01] <mibofra> kdub, I can do a better thing, if you have netstat I can send you the logcat output in realtime
[21:01] <mibofra> if you want
[21:04] <mibofra> netstat lol, kdub I wanted to mean netcat
[21:05] <kdub> mibofra, lets just stick with pastebin, dont know that one
[21:05] <mibofra> kdub, ok
[21:07] <mibofra> kdub, I've passed logcat output to pastebinit
[21:07] <mibofra> let's wait until it finishes
[21:08] <mibofra> (I hope it will finish)
[21:09] <mibofra> kdub, anyway I've stopped any service can lock hw, like the media manager, zygote, surfaceflinger, audioflinger and drm
[21:09] <kdub> it wont finish
[21:09] <mibofra> *of the android system
[21:09] <mibofra> kdub, I'm pasting
[21:17] <mibofra> kdub, http://paste.ubuntu.com/8057442/
[21:18] <kdub> cool, no errors
[21:21] <kdub> does
[21:22] <kdub> ./mir_integration_tests --gtest_filter="TestClientIPCRender.*"
[21:22] <mibofra> kdub, a thing, I've the executables in /usr/bin and /usr/bin is in the path
[21:22] <mibofra> so you can omit the ./
[21:24] <mibofra> kdub, http://paste.ubuntu.com/8057461/
[21:24] <kdub> interesting, the client rendering is working too
[21:25] <kdub> not sure what's blocking then
[21:26] <mibofra> kdub, <mibofra> http://paste.ubuntu.com/8055122/ mir_unit_tests , http://paste.ubuntu.com/8055134/ mir_integration_tests , http://paste.ubuntu.com/8055170/ mir_acceptance_tests  but I'm not really sure if the tests were finished.
[21:26] <mibofra> tests I've done some hours ago
[21:27] <kdub> no, the integration tests don't finish for some reason
[21:27] <kdub> and the MultiThreadedCompositor test is hanging
[21:28] <mibofra> kdub, I've send a ctrl+c after a while because I thought they were frozen
[21:28] <mibofra> but I can repeat the test and I can wait them finish
[21:28] <mibofra> *tests
[21:48] <mibofra> ah kdub yep the integration tests were aborted but I've not aborted them
[22:35] <mibofra> good night kdub and thanks
[22:35] <mibofra> see you
[22:36] <mibofra> good night everyone and thanks too
[22:37] <Nothing_Much> I forgot whether my question was answered or not, so... Does Mesa need patches for XMir to work from the Oibaf PPA?
[22:40] <racarr> Nothing_Much: First time hearing about the oibaf ppa so can't be sure
[22:40] <racarr> if Mir works but XMir does not Mesa will not need additional patching
[22:40] <racarr> The DDX drivers, i.e. xserver-xorg-video-intel
[22:40] <racarr> do require a patch and if xmir isnt working but mir is
[22:40] <racarr> thats a good guess