[02:34] <kenvandine> racarr, pong
[03:44] <duflu_> racarr: ubuntu-device-flash touch --help
[03:58] <duflu> The non-obvious bit is that --help gives a different answer according to context
[04:02] <racarr> duflu: I guess that was the one that I found not to work actually
[04:02] <racarr> --recovery-image (which I copied from the PES wiki)
[04:03] <racarr> I still dont end up with adb in recovery
[04:03] <racarr> and have to fastboot flash
[04:03] <racarr> I dunno
[04:03] <racarr> the USB issues make it hard to understand
[04:03] <racarr> what really happened
[04:03] <racarr> I have a cable/port combo that seems steayd now though
[05:07] <anpok> RAOF: hrhr
[05:08] <RAOF> anpok: Yeah, rad isn't it?
[05:08]  * RAOF just had to finish it over the weekend.
[05:09] <anpok> havent grasped it yet
[05:11] <anpok> i spent this weekend restarting the compile time widget tree thing.. and even uploaded it..
[05:36] <RAOF> Oooh, InputSender. That's what I'm after!
[05:37] <tjaalton> hm no ancell? wonder if the xmir patch is going upstream soon, 1.18 is finally about to freeze
[05:37] <tjaalton> xserver
[09:13] <duflu> greyback: Does unity8 always have GL_BLEND on (regardless of surface pixel format)?
[09:18] <greyback_> duflu: sorry, wifi dropped
[09:20] <greyback_> duflu: it doesn't always have blending enabled. It first draws opaques front to back with blending disabled but depth masking enabled. Then non-opaques are drawn back to front with blending enabled
[09:20] <duflu> greyback_: So "opaque" is XRGB as opposed to ARGB
[09:20] <duflu> ?
[09:20] <duflu> Depending on the surface pixel format
[09:21] <greyback_> duflu: anything in the qml not needing an alpha channel
[09:21] <greyback_> the surface format for mir, we've probably chosen XRGB
[09:22] <greyback_> mainly because it'll always work. But we're working on more intelligently selecting the mir surface format, to improve perf
[09:22] <duflu> greyback_: I've got hints that Unity8 might be blending XRGB as if it was ARGB. Admittedly Mir demo servers have the same bug. I was just wondering if we're all affected
[09:22] <greyback_> duflu: is possible, unity8 does the same thing as mir in that respect
[09:36] <duflu> alf_: Feel like chatting today?
[09:37] <alf_> duflu: coming
[10:22] <mcphail> greyback_: do you think the blending contributes to this bug? : https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1460149
[10:28] <greyback_> mcphail: not directly, but I suspect the sdl's surface may be using a mir surface format with an alpha channel, making unity8 blend it. Would have to dig to learn more
[10:28] <mcphail> greyback_: just interested as to why the aberrant blending clears when you swipe the app away
[12:44] <greyback_> /usr/lib/gcc-cross/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld: ../../gmock/libs/gtest/libgtest.a(gtest-all.cc.o): relocation R_ARM_THM_MOVW_ABS_NC against `__stack_chk_guard' can not be used when making a shared object; recompile with -fPIC
[12:44] <greyback_> ../../gmock/libs/gtest/libgtest.a: error adding symbols: Bad value
[12:45] <greyback_> ^^ I get that building mir in my arm Xcompile chroot. Would libgtest.a not be compiled with -fPIC?
[13:39] <kdub> greyback_, libgtest.a seems to be compiled with fPIC from the mir build system
[13:40] <kdub> alf_, was curious, is it the mg::DisplayBuffer/mg::Display system that has the gl stuff baked in the most? or is there somewhere else
[13:40] <greyback_> kdub: yeah. Am still confused
[13:41] <kdub> greyback_, using sbuild?
[13:41] <greyback_> kdub: yes
[13:41]  * kdub did that a day or two ago, seemed okay, after updating with -udacr
[13:42] <alf_> kdub: Excellent timing :) I have started a document with a tentative plan about removing gl dependencies (including where these dependencies are in the code). Will post a link of a first draft before EOD today.
[13:47] <kdub> alf_, cool, I just felt compelled to point out that mg::DisplayBuffer::post_renderables_if_optimizable is really not posting anymore
[13:48] <kdub> and mg::DisplayBuffer is mostly about content, which seems good for abstracting the gl bits out
[17:21] <kenvandine> racarr, you pinged me last night?
[17:57] <racarr> kenvandine: Oh hey sorry yeah I think I've since resolved my question
[17:57] <racarr> I was trying to narrow down what may be triggering the text input failure...because
[17:58] <racarr> just uh
[17:58] <racarr> Like making an autopilot keyboard object from python
[17:58] <racarr> typing
[17:58] <racarr> doing stuff
[17:58] <racarr> typing doing stuff
[17:58] <racarr> seemingly infinitely never triggers it
[17:58] <racarr> s/seemingly infinitely/for a few minutes/
[17:58] <racarr> So I was trying to find a collection of tests to trigger it but I have a few now...
[17:58] <racarr> its hard to find the common element the
[17:58] <racarr> lol
[17:58] <kenvandine> yeah
[17:58] <kenvandine> sucks
[17:58] <racarr> the autopilot tests aren't easy to read
[17:58] <kenvandine> nope
[17:58] <racarr> because theres so much inheritance of implementation
[17:59] <racarr> Its like
[17:59] <racarr> I dunno
[17:59] <racarr> I tried tracing base classes up and
[17:59] <racarr> butttt
[17:59] <racarr> hard to isolate anything
[17:59] <racarr> so my new strategy is instrument USC :)
[17:59] <kenvandine> i don't think it has anything to do with the system-settings autopilot tests
[17:59] <kenvandine> well
[17:59] <racarr> well...it may have something to do with autopilot though
[17:59] <kenvandine> we're using the keyboard input provided from the uitk i think
[18:00] <kenvandine> yeah
[18:00] <racarr> like I said with just the fake uinput thing
[18:00] <racarr> I can't trigger it
[18:00] <kenvandine> it's triggered by something autopilot is doing
[18:00] <kenvandine> also... i think it's more than just the fake keyboard
[18:00] <kenvandine> there is a fake mouse too for touch events
[18:00] <kenvandine> also uinput
[18:00] <racarr> that stops working?
[18:00] <racarr> yes so I thought
[18:00] <kenvandine> yes
[18:00] <racarr> this was all related
[18:00] <racarr> to uinput
[18:00] <racarr> which according to the bug is what is being used in autopilot now
[18:01] <racarr> and it seems that the problem is
[18:01] <kenvandine> yeah
[18:01] <racarr> the unity8 session loses focus
[18:01] <kenvandine> and mir starts discarding the events
[18:01] <racarr> loses keyboard focus
[18:01] <racarr> mm
[18:01] <kenvandine> from what dandrader said
[18:01] <racarr> Yeah I confirmed that unless im only seeing part of the bug
[18:02] <racarr> I haven't seen any unity8 crashes for example so far
[18:02] <racarr> and don't understand where that comes in
[18:02] <kenvandine> yeah...
[18:02] <kenvandine> that wasn't related
[18:02] <kenvandine> i don't think
[18:02] <racarr> ok :)
[18:02] <kenvandine> well, we saw the same unity8 crash everytime we had run into this
[18:02] <racarr> yeah that was my other question.
[18:02] <racarr> ah
[18:02] <kenvandine> but the crash stopped
[18:02] <kenvandine> and this kept happening :)
[18:02] <kenvandine> so unrelated
[18:02] <kenvandine> it was a distraction from the real problem
[18:03] <kenvandine> racarr, it affects at least webbrowser-app and ubuntu-system-settings
[18:03] <kenvandine> but likely more too
[18:03] <kenvandine> we just have long autopilot tests
[18:04] <kenvandine> i think we've had the problem intermittently for a while, we used to have random failures where it seemed to stop getting the uinput events
[18:04] <kenvandine> touch stuff
[18:04] <greyback> crazy idea: could there be a test pressing down a meta key, and crashing before that key is released?
[18:04] <kenvandine> but re-running it would pass
[18:04] <kenvandine> now it's consistent
[18:04] <kenvandine> i haven't had a passing CI run in settings in 2 weeks
[18:05] <kenvandine> greyback, i don't think so
[18:05] <greyback> worth a shot :)
[18:05] <kenvandine> i'm pretty sure i've hit it when tests that didn't even use the keyboard
[18:05] <racarr> greyback: That's a good idea but I think it wouldn't explain the focus behavior
[18:05] <kenvandine> just the fake mouse events stop
[18:05] <racarr> which im 99% sure isn't a red herring
[18:06] <racarr> wait the fake mouse events stop oO
[18:06] <kenvandine> makes sense though
[18:06] <kenvandine> because of focus
[19:32] <racarr|lunch> yay just catching up on MLs...anpoks libinput changes are landing :)
[19:36] <anpok> hum .. time to say goodbye
[19:37] <anpok> .. to those hp/webos usb cables
[19:54] <racarr> kenvandine: After upgrading arale to r50 from
[19:54] <racarr> ubuntu-touch/rc-proposed/meizu.en
[19:55] <racarr> The test I was using autopilot3 run ubuntu_system_settings.tests.test_search.SearchTestCases.test_search_filter_results
[19:55] <racarr> doesnt fail anymore after like 25 times
[19:55] <kenvandine> oh?
[19:55] <racarr> I was on either 48 or 49 yesterday
[19:55] <kenvandine> any idea what change fixed it?
[19:55] <racarr> I Was wondering 1. Could you suggest some other tests. 2. Can you try upgrading as well?
[19:56] <racarr> No...lol...
[19:56] <kenvandine> i mostly care about wily, since that's what CI runs on
[19:57] <kenvandine> racarr, try running the full suite
[19:58] <racarr> kenvandine: Running :)
[19:58] <racarr> I don't think I've ever put wily on my uh
[19:58] <racarr> arale...is it
[19:58] <racarr> ubuntu-touch/devel/meizu.en?
[19:58] <kenvandine> not sure off hand, i have it on my mako
[19:59]  * kenvandine checks channel
[19:59] <kenvandine> ubuntu-touch/devel-proposed/ubuntu
[19:59] <kenvandine> racarr, that's the channel i have on my mako
[20:00] <racarr> ok thanks :) anyway full suite running now
[20:00] <kenvandine> racarr, ubuntu-touch/devel-proposed/meizu.en
[20:00] <racarr> changing laundry...uh
[20:00] <kenvandine> is for arale
[20:00] <kenvandine> racarr, thx
[20:00] <racarr> then I guess I can switch to latest wily
[20:00] <racarr> and see whats going on
[20:00] <racarr> I was just trying to test with an
[20:00] <racarr> instrumented USC to try and understand
[20:00] <racarr> but then before I was like ok first
[20:00] <racarr> clean image and reproduce
[20:00] <racarr> and now I can't reprouce anymore lol
[20:01] <kenvandine> might be a good sign :)
[20:01] <racarr> probably but not understanding is frustrating...
[20:03] <kenvandine> i'm updating my mako and will try the tests too
[20:16] <racarr> kenvandine: Aghhh I managed to trigger it...
[20:16] <racarr> I guess it was just being elusive
[20:16] <racarr> :/
[20:16] <kenvandine> ok
[20:34] <racarr> is there a way to work with the citrain on vivid + overlay without
[20:34] <racarr> writing apt pins, etc...?
[20:36] <anpok> i think you no longer have to
[20:37] <anpok> racarr: the current phablet tools should already do that
[20:37] <anpok> at least after i used an unbroken cable.. a current image from the right channel.. it finally worked
[20:46] <kgunn> yeah robru said you shouldn't have to pin with overlay
[20:46] <racarr> hmm
[20:55] <racarr> I have a plausible theory about the text input bug now!
[20:55] <racarr> 1. An autopilot test eventually fails because that happens with the timeouts and stuff causing mirscreencast to be invoked
[20:56] <racarr> 2. Bug in surfaceless session management with mirscreencast
[20:56] <racarr> connecting and disconnecting
[20:56] <racarr> causes
[20:56] <racarr> focus to be cleared when
[20:56] <racarr> mirscreencast closes
[20:56] <racarr> instead of
[20:57] <racarr> unity8
[20:57] <racarr> I kind of see a plausible path in the code but its hard to tell whats happening because
[20:57] <racarr> um
[20:57] <racarr> as far as I can tell there are two window managers in USC
[20:57] <racarr> lol
[20:58] <racarr> WindowManager seems to take care of like focusing sessions when sessions are removed and stuff like that
[20:58] <racarr> but then so does SessionSwitcher oO
[20:58] <racarr> anyway...I feel good about this theory but I'm still struglging to test anything
[20:58] <racarr> I needed to install the mir 0.14 ppa to build USC trunk with my instrumentation on vivid+overlay of course
[20:58] <racarr> but mir 0.14 ppa did not work on vivid+overlay for me
[20:58] <racarr> (u8 crashes after 3-4 seconds)
[20:58] <racarr> so now I'm trying to test with wily...
[21:00] <racarr> in particular usc::WindowManager l115 auto const next_session = session_coordinator->successor_of({});
[21:00] <racarr> I can't see why that would be the right value...
[21:02] <racarr> hmm and this code is in mir now in system_compositor_window_manager
[21:02] <racarr> with some modifications
[21:02] <racarr> too bad about no Alan...
[21:03] <racarr> Interesting ok
[21:03] <racarr> I guess the SurfaceReadyObserver
[21:03] <racarr> may be bale to prevent screencast from stealing focus...
[21:03] <racarr> (a new introduction to the logic when it was imported)
[21:34] <racarr> um so both vivid and wily+overlay
[21:34] <racarr> the mir 0.14 ppa
[21:34] <racarr> unity8 crashes within seconds on arale
[21:34] <racarr> has anyone else tested it?
[21:35] <anpok> the ppa is incomplete.
[21:35] <anpok> i was waiting for platform api and qtubuntu to land
[21:36] <racarr> oh
[21:37] <racarr> anpok: When is that expected?
[21:38] <anpok> it just happened for wily
[21:39] <anpok> it now needs to be synced to vivid+overlay... but at least the lp branches are updated.. so I guess I can build it..
[21:39] <racarr> anpok: :D That would help me
[22:32] <kenvandine> Ran 135 tests in 2750.871s
[22:32] <kenvandine> OK
[22:32] <kenvandine> racarr, ^^ on my mako with wily
[22:32] <kenvandine> that hasn't happened in 2 weeks
[22:33] <kenvandine> maybe it was a fluke... or maybe something's been fixed?
[22:40] <racarr> kenvandine: So uh...yeah I also got
[22:40] <racarr> well right I ran that one test like 30 times and
[22:40] <racarr> then saw dozens in the test suite complete
[22:40] <racarr> before failing
[22:40] <racarr> so its possible the race has just gotten
[22:40] <racarr> way tinier lol...
[22:41] <racarr> though, right I still haven't tested wily! my result was from vivid + overlay
[23:53] <RAOF> racarr: With your input sending reworkything, were you thinking of having mf::Surface have a send_event method?