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