[00:44] <RAOF> racarr_: Enjoy your +1 on cursor-spike.
[01:37] <AlbertA> looks like the landing ci is stuck?
[01:37] <AlbertA> there's 4 MP's ready to land for the last 10 hours and they haven't landed yet
[01:37] <kgunn> ack, will see if someone in ci can kick the coke machine
[01:38] <duflu> AlbertA: Umm, happy final release eve... ?
[01:38] <duflu> That shouldn't block anything though
[01:38] <AlbertA> duflu: oh is that what it is?
[01:38] <duflu> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[01:39] <duflu> Probably not related. People are usually working furiously on SRU-0/SRU-1 for their various projects around now
[01:39] <duflu> which means blocking is unexpected
[01:40] <AlbertA> kgunn: so for the non-blocking swapbuffers I believe the best course of action is to avoid
[01:41] <AlbertA> kgunn: starting the display buffer compositor threads during display off
[01:43] <kgunn> AlbertA: so does that just end up making it an order of operation issue, and can you guarantee display on prior to starting disp-buff-comp ?
[01:44] <AlbertA> kgunn: well currently the responsibility lies on whoever is changing the display configuration
[01:44] <kgunn> usc ?
[01:44] <AlbertA> kgunn: they need to make sure the compositor is stopped before changing the display configuration
[01:44] <AlbertA> kgunn: yes usc in this case
[01:45] <AlbertA> kgunn: the main issue will be that the compositor will have to have indication of the display power state somehow
[01:45] <AlbertA> kgunn: so either it's start method takes a hint parameter
[01:46] <AlbertA> kgunn: or the compositor interface exposes some method that makes sense for display power off
[01:46] <kgunn> AlbertA: right...i would think you'd want more of a handshake, hint "i need to know when you've actually stopped/started"
[01:46] <AlbertA> kgunn: well you want the compositor to only start the buffer consuming thread only
[01:47] <kgunn> mmm, yeah, maybe it does...
[01:47] <AlbertA> kgunn: the hard part is not exposing those internal implementation details
[01:47] <kgunn> well it is the "display" buffer compositor
[01:47] <kgunn> so it does imply it can "know" display stuff
[01:48] <kgunn> ok...still on irc on my other machine...trying xmir again :)
[01:50] <kgunn_> RAOF, ok...ssh'd into my other machine which is now a black screen on xmir attempt
[01:51] <RAOF> kgunn_: Good, good. If you restart lightdm, does anything happen?
[01:51] <kgunn_> one note, early today i reinstalled xserver-xorg-*, dri2 wondering if that would cleanly return any default conf files that might have been hosed....(e.g. apt-get install --reinstall..) is that true ? would it cleanly take care of conf files?
[01:51] <kgunn_> RAOF, so i just restarted lightdm, nada
[01:51] <kgunn_> just black screen
[01:53] <kgunn_> lightdm.log says waiting for signal from xserver, Process 8238 terminated with signal 6
[01:54] <RAOF> SIGABRT is unlikely to end in pleasantness.
[01:54] <RAOF> What sayeth /var/log/Xorg.0.log?
[01:55] <AlbertA> kgunn_: actually what I've said is already taken care of by https://code.launchpad.net/~afrantzis/mir/expose-display-buffer-only-for-power-mode-on/+merge/214758
[01:55] <AlbertA> kgunn_: I wonder why that's not the case...
[01:56] <kgunn_> RAOF, so it seems to go thru some display config checking & updates...then
[01:57] <kgunn_> just before backtrace its [  9484.653] (II) Putting surface on output 9
[01:57] <kgunn_> [  9484.653] (EE) Backtrace:
[01:57] <kgunn_> [  9484.653] (EE) 0: /usr/bin/X (xorg_backtrace+0x48) [0x7fd14470ec48]
[01:57] <kgunn_> [  9484.653] (EE) 1: /usr/bin/X (0x7fd144566000+0x1ac939) [0x7fd144712939]
[01:57] <kgunn_> [  9484.653] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd143663000+0x10340) [0x7fd143673340]
[01:57] <kgunn_> [  9484.653] (EE) 3: /lib/x86_64-linux-gnu/libpthread.so.0 (pthread_mutex_lock+0x4) [0x7fd14366d414]
[01:58] <kgunn_> ...is this some stupid "hybris got installed" thing ?
[01:58] <duflu> kgunn_: Only if you have hybris installed :)
[01:59] <kgunn_> hmmm, so libhybris isn;t, but ...libhybris-common1 is ?
[01:59] <duflu> kgunn_: Yeah apparently that much is safe
[01:59] <duflu> And required, for some reason
[02:00] <kgunn_> ok...everytime i see pthread's i think libhybris...just cause of the tegra thing
[02:02] <RAOF> Harumph.
[02:02] <duflu> kgunn_: When that happens the path name will contain "hybris" so it's OK
[02:02] <RAOF> That's *all* the backtrace?
[02:02] <duflu> Also it will only apply to lib*GL
[02:03] <kgunn_> the whole thing is https://pastebin.canonical.com/108605/
[02:05] <RAOF> Hm. Died in mir_surface_is_valid?
[02:10] <RAOF> So I guess what's happening here is that XMir is getting a null MirSurface* and calling mir_surface_is_valid on it.
[02:11] <AlbertA> kgunn_: so it turned out I was not updating the mir platform libraries on my device...:)
[02:11] <AlbertA> kgunn_: volume keys work just fine now
[02:11] <kgunn_> ah man!
[02:12] <duflu> RAOF: https://bugs.launchpad.net/mir/+bug/1248474
[02:12] <ubot5> Ubuntu bug 1248474 in Mir "mir_surface_is_valid(NULL) crashes instead of returning false" [Medium,Triaged]
[02:13] <RAOF> Another well-known cleanup bug!
[02:14] <kgunn_> this is the part where duflu throws me "that  look"
[02:15] <kgunn_> i don't mean to question the experts...but, i'm on a mac/intel w/ integ gfx...wouldn't think it would be a consistent prob
[02:15] <kgunn_> others would've complained ?
[02:16] <RAOF> I would have thought so, yes.
[02:21] <AlbertA> can anybody else download branches through bzr? Getting connection issues
[02:21] <RAOF> Also, how *can* we get a null MirSurface? The callback is called from Surface::created() thusly: callback(this, context);
[02:23] <kgunn_> AlbertA, fails here too
[02:31] <kgunn_> RAOF, so if its really a mir thing, then i should fail to launch a demo_server
[02:31] <kgunn_> right ?
[02:31] <RAOF> kgunn_: Probably, yes.
=== chihchun is now known as chihchun_afk
[03:13] <kgunn_> RAOF, hmmm...got majorly distracted, but ok, server seems to launch, but client does fail w a seg fault
[03:18] <kgunn_> and gdb backtrace showing same mir_surface_is_valid
[03:21] <kgunn_> ok...heading to bed, maybe some more tomorrow
=== chihchun_afk is now known as chihchun
[06:33] <RAOF> Bah! That's really annoying.
[06:34] <RAOF> Stupid race-condition testing!
=== chihchun is now known as chihchun_afk
[09:42] <alf_> greyback: Is this still needed? https://bugs.launchpad.net/mir/+bug/1226778
[09:42] <ubot5> Ubuntu bug 1226778 in Mir "[unity8 shell] mc::Compositor has no method to get running state" [High,Incomplete]
[09:43] <greyback> alf_: I think calling stop() twice doesn't cause a crash any more, so that bug is more a nice-to-have.
[09:44] <alf_> greyback: ok, marking as "wishlist" then
=== chihchun_afk is now known as chihchun
=== pete-woods is now known as pete-woods-lunch
=== pete-woods-lunch is now known as pete-woods
=== dandrader is now known as dandrader|afk
[14:56] <kgunn> alf_: AlbertA greyback ...ok, unity-mir, qtubuntu rebuilt...
[14:56] <alf_> kgunn: ok updating
[14:56]  * greyback too
[14:59] <alf_> kgunn: greyback: what do the updates fix/improve?
[14:59] <greyback> alf_: the qtubuntu change will have Qt client apps stop rendering as soon as they are off-screen (well, when they get lifecycle events)
[15:00] <alf_> greyback: ah, great
[15:00] <greyback> alf_: I have instructions in a comment in https://code.launchpad.net/~gerboland/qtubuntu/surface-visible-hidden-side-channel/+merge/215884 to show how you can test it
[15:00] <greyback> I'd appreciate a third party check...
=== dandrader|afk is now known as dandrader
[15:02] <kgunn> will update also ...(when/if i can stop the irc pinging)
[15:03] <alf_> kgunn: kdub: racarr_: stand up
[15:08] <alf_> greyback: confirmed that printDate.qml stop requesting buffers, but still keeps printing to stdout with latest silo builds
[15:08] <greyback> alf_: that's perfect
[15:09] <greyback> alf_: the printing is from the GUI thread, which can continue working unblocked
[15:09] <greyback> so the rendering thread has shut down cleanly
[15:09] <greyback> (sorry I always fall into the Qt terminology. GUI thread = even handling thread)
[15:10] <greyback> event
[15:10] <alf_> greyback: seems so, I am running with MIR_CLIENT_RPC_REPORT=log and see that the client stops requesting buffers
[15:11] <greyback> alf_: yes, sounds right
[15:11] <greyback> \o/
[15:11] <greyback> \o\
[15:11] <greyback>  /o/
[15:18] <alf_> greyback: exercising? ;)
[15:18] <alf_> _o_
[15:19] <alf_> \o/
[15:19] <alf_> _o_
[15:19] <alf_> \o/
[15:19] <greyback> lol
[15:19] <greyback> just happy this is working :)
[15:39] <alf_> greyback: kgunn: hmm, the falling-letters app freezes when you turn the screen of and back on again
[15:40] <alf_> greyback: kgunn: but other apps (e.g. sudoku) work fine, so perhaps that app is at fault?
[15:42] <greyback> alf_: confirmed. will investigate
=== dandrader is now known as dandrader|lunch
[15:45] <alf_> greyback: the camera-app freezes too, but the clock doesn't, perhaps it has to do with whether there is some animation/app update going on when the screen is turned off (just wild guess)
[15:46] <kgunn> kdub: if you do happen to try xmir...i'd be interested to hear your results...and _after_ confirming it works, if you could try the mir/usc in ppa:ci-train-ppa-service/landing-003
[15:46] <kgunn> that would be interesting
[15:47] <kdub> kgunn, i'm set up to try the demo server/shell pretty quickly, was that broken too?
[15:47] <kgunn> alf_: greyback ...is there a chance here the apps aren't expecting the expose event ?
[15:47] <greyback> alf_: that shouldn't be the case, most animations run on the unblocked thread. But yeah the render thread is blocked for dropping letters, need to figure out why
[15:47] <kgunn> kdub: demoshell/client was broken for me yes
[15:48] <kgunn> agian...it might be me
[15:48] <kdub> i'll try that out real quick.. a few minutes
[15:48] <kgunn> greyback: do you know if dropping letters and camera are pure qml ? (i would suspect dropping letters is for sure)
[15:49] <greyback> kgunn: it is pure qml
[15:49] <kgunn> mmm there goes that theory
[15:49] <greyback> so I must have something wrong in qtubuntu
[15:50] <kgunn> or bug in qt itself...
[15:50] <greyback> I'll assume I'm at fault first :)
[15:52] <racarr_> even if the expose event wasnt working apps should be rendering out of control and not blocking right?
[15:52] <racarr_> (maybe this has evolved since I briefly understood it in london ;))
[15:53] <greyback> indeed. But I've managed to do this in qtubuntu before, it sometimes managed to lie to the renderer and renderer gets locked up
[15:55] <racarr_> -.-
[15:57] <alf_> greyback: in case it is helpful, here is the client rpc log for mir when running dropping-letters: http://paste.ubuntu.com/7262240/
[15:57] <alf_> greyback: Result id:0 responses are events
[15:58] <AlbertA> kgunn: just checked mir/devel on my haswell laptop, demo server/client works well here
[16:00] <greyback> alf_: is definitely my problem, render thread not shutting down correctly, need to determine why...
[16:01] <kgunn> ta AlbertA
[16:25] <kgunn> so when you play video, it keeps playing for about 2 secs when you hit the power button....and then immediately restarts for ~1 second after unlock
[16:25] <kgunn> even tho, you cant see it, but stops again, until you bring it into focus
[16:26] <kgunn> oops...ok, browser locked up
[16:27] <kgunn> greyback: alf_ ^
[16:27] <kgunn> ...i abused it several times before lockup
[16:28] <kgunn> (and only the browser, shell & other apps still respond)
=== dandrader|lunch is now known as dandrader
[16:32] <greyback_> kgunn: I've something that I think will fix it. Have just pushed it to the qtubuntu branch. Am building package
[16:32] <greyback_> (locally)
[16:35] <kgunn> ack
[16:35] <kgunn> dude...watching the "i think we're alone now" trailer over and over is strarting to creep me out
[16:39] <racarr_> ...
[16:39] <racarr_> :p
[16:39] <greyback_> kgunn: could you please test http://people.canonical.com/~gerboland/qtubuntu-android_0.54+14.04.20140402-0ubuntu1_armhf.deb
[16:40] <greyback_> and see if it fixes the blocking issue
[16:42] <josharenson> Is there an easy way to change the background color of mir_server_demo_shell? I think I found a bug, and changing the color to, say red, would make identifying it a bit easier.
[16:42] <kgunn> greyback_: i will...stepping out for a quick bite
[16:42] <kdub> josharenson, search for glClearColor in the examples/ code... i beleive its set to grey there
[16:42] <josharenson> kdub: ack
[16:42] <greyback_> kgunn: ok. I'm heading out for dinner, so will be away a few hours. Please email with the verdict
[16:45] <kgunn> lunch date running late...lemme see if i can do quickly
[16:49] <greyback_> man the new browser is good
[16:49] <kgunn> greyback_: nope.....same experience
[16:50] <greyback_> kgunn: with dropping letters even?
[16:50] <kgunn> sorry...just video
[16:50] <kgunn> lemme check dropping letters
[16:51] <kgunn> cool!...time out worked on video...same little hiccups
[16:52] <greyback_> you play video from the video scope right? Why not working for me...
[16:52] <kgunn> yep, i'm playing the "i think we're alone now"
[16:52] <greyback_> ** (process:2021): WARNING **: Unable to dispatch url 'https://videosearch.ubuntu.com/v0/redirect?s=TPzN98RZt0eNHhrYvplj9d3_WtKAbOSC3wun2Q%3D%3D&u=http%3A%2F%2Fvodo.net%2Fitwan':GDBus.Error:com.canonical.URLDispatcher.BadURL: URL 'https://videosearch.ubuntu.com/v0/redirect?s=TPzN98RZt0eNHhrYvplj9d3_WtKAbOSC3wun2Q%3D%3D&u=http%3A%2F%2Fvodo.net%2Fitwan' is not handleable by the URL Dispatcher
[16:52] <kgunn> no hang on dropping letters....
[16:53] <greyback_> ok, improvement
[16:53] <greyback_> though I notice dropping letters not pausing when we switch away from it
[17:00]  * greyback_ has to go
=== alex_abreu is now known as alex-abreu
[17:09] <josharenson> if MIR_BYPASS is unset, then bypass is enabled?
[17:20] <kdub> 1) that's becoming MIR_SERVER_BYPASS very soon and 2 yes, default is on
[17:20] <kdub> its also becoming a --help option soon, so it will be clearer wh at the default is
[18:16] <dandrader> "what():  error during hwc prepare(). rc = ffffffff"
[18:16] <dandrader> is that known on the N4? ^
[18:28] <kdub> dandrader, not known
[18:30] <dandrader> oh, that's surprising
[18:31] <dandrader> happens when I turn off/on the display, pressing the power button
[18:31] <dandrader> backtrace is useless as usual
[18:47] <kgunn> camako: ^ might be an intersting one
[18:47] <kgunn> what josharenson found
[18:47] <kdub> dandrader, yeah, I know there's some synchronization issues with the compositor/display power on/off being worked on
[18:48] <josharenson> kgunn: ?
[18:48] <josharenson> kdub: that sounds like what I see... flickering/tearing when starting fullscreen app
[18:48] <camako> kgunn: abt bkgrnd color?
[18:48] <kgunn> sorry josharenson, meant dandrader
[18:49] <josharenson> ah
[18:49] <kgunn> camako: sorry, meant the hwc prepare issue
[18:49] <kdub> josharenson, well, bypass is only on the mesa platform, is that where you're seeing it?
[18:49] <kgunn> as far as digging in code
[18:49] <camako> kgunn: o i see
[18:49] <josharenson> kdub: nope
[18:49] <camako> kgunn: perfect.. right up my alley :-)
[18:49] <josharenson> kdub: reason I wanted to change bkgnd color is i see the flickering when unity is running... want to isloate unity/mir
[18:50] <camako> dandrader: does it happen every time?
[18:50] <josharenson> kdub: working on other things now, but will file a bug when i investigate in a bit (my guess is it will be a dupe of something filed already... I'll read up)
[18:51] <dandrader> camako, started happening consistently after I restarted unity8 manually.
[18:51] <kdub> greyback and alf_ , they might know something more than me
[18:52] <camako> dandrader: let me poke around a bit
[19:20] <dandrader> camako, btw, I was using the "qt as mir compositor" branch of unity8, if that makes any difference...
[19:21] <camako> dandrader: I see
[19:26] <AlbertA> we are hitting some sort of timeout issue in CI for landings
[19:27] <AlbertA> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1116/console
[19:27] <AlbertA> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1117/console
[19:34] <AlbertA> kdub: ^ just pinged CI channel they are checking
[19:34] <kdub> oh, I just was poking through that, and retriggered the landing
[19:35] <AlbertA> yeah me too :)
[19:35] <kdub> sometimes that's a transient problem, other times, its a permanent problem
[19:37] <AlbertA> kdub: I guess the lander is getting hit hard today
[19:39] <kdub> AlbertA, yeah, those 4mps have been waiting a while
[19:39] <kgunn> camako: i think dandrader means this... https://docs.google.com/a/canonical.com/document/d/163nyfh_G90nzQnRdI7IYgrMH_0VdmesBju5jpb4wse0/edit
[19:41] <camako> kgunn: Thanks for the doc... I am looking through code atm...
[19:41] <AlbertA> dandrader: and you sure unity8 is started in nested mode? sounds like it's not
[19:42] <dandrader> AlbertA, hmm, that could be it!
[19:43]  * dandrader tries
[19:46] <dandrader> AlbertA, you got it.
[19:49] <AlbertA> dandrader: cool
=== chihchun is now known as chihchun_afk
[20:47] <kdub> i'm being brave
[20:47] <kdub> and cleaning up GLRenderer test
[20:49] <racarr_> IN TO THE DEPTHS!
[20:49] <anpok> yeah thats an interesting bunch of tests
[20:51] <kdub> it was maybe the second test ever written
[20:54] <racarr_> Ok...mostly finished...new ozone-mir (lots of upstream changes, quite helpful ones...just...all the code has to change)
[20:54] <racarr_> feeling kind of exhausted though, so going to switch to fixing this bug I found in introduce-scene-observer (or think might exist, rather the first task is writing a test)
[20:54] <racarr_> and then fiddle with xinput for a while.
[20:55] <racarr_> actually first im going to eat ice cream. haha. brb.
[21:59] <kgunn> AlbertA: camako....good grief this took me too long....could you review https://wiki.ubuntu.com/Mir/NonBlockingSwapTesting#preview
[22:00] <camako> kgunn: sure... how soon do you need it?
[22:02] <kgunn> just look it over for 5 min...for any big idea that maybe i missed
[22:03] <kgunn> pretty sure the notes are good...its editable :) so we can fix if it strikes you in 10 minutes not 5
[22:10] <camako> kgunn: looks good to me
[22:11] <camako> kgunn: but what do I know...
[22:11] <kgunn> camako: thank you mir-expert :P
[22:12] <camako> kgunn: at least wording is good and I was able to follow the text... Dunno abt the commands mentioned therein..
[22:12] <camako> kgunn: mir-expert... :-)
[22:20] <kgunn> greyback: earlier you said dropping letters isn't stopping...but it is, i think you just witness that a few more letters drop before sigstop
[22:21] <greyback> kgunn: right, but there are times that it's not sigstopped, yet it is not in front. Leaving the spread open for instance.
[22:22] <greyback> kgunn: oh, would you please kick qtubuntu to build the latest revision
[22:22] <kgunn> greyback: you bet
[22:22] <greyback> thanks