[07:09] <test_> I'm in love with the unity UI..! great job guys! nicely well done!
[07:12]  * sil2100 sighs
[07:12] <sil2100> Hello
[07:12] <sil2100> My HUD-fixes branch didn't get merged because of jenkins issues
[07:14] <sil2100> Re-approving again, grrr
[07:14] <didrocks> sil2100: hey hey!
[07:14] <didrocks> sil2100: jibel is looking at the weird jenkins prepare job errors
[07:14] <didrocks> sil2100: I'll relaunch everything then
[07:43] <sil2100> pstolowski: hi! Officially, who should I thank for the 'double-click-to-run-app-from-the-dash' functionality ;p ?
[07:44] <hyperair> double click? seriously?!
[07:45] <sil2100> hyperair: I think there's some switch to disable this and make it work as it used to in the past
[07:45] <hyperair> heh okay
[07:45] <didrocks> sil2100: FYI, on the QA stack, the decision is to relax to 3 the number of failures we accept
[07:45] <hyperair> but double click to activate item in dash.. that sounds like a seriously bad idea.
[07:45] <didrocks> sil2100: that should do the trick for now and it's better than disabling tests
[07:45] <sil2100> didrocks: ok, checking the status - but did thomi do any fixes yesterday?
[07:46] <didrocks> sil2100: btw, is the double click merged? it doesn't fail autopilot jobs, they are adapted to it?
[07:46] <didrocks> sil2100: one, they can't reproduce the 3 others on amd64
[07:48] <sil2100> didrocks: that's better than nothing... yes, it's merged, as this was one of the things that had to land before it gets pushed to trunk, and I think some tests were fixed for it to work
[07:48] <sil2100> didrocks: I see jenkins will be shutting down
[07:49] <didrocks> sil2100: yeah, but we are blocked on the sru test kernel job
[07:49] <sil2100> didrocks: let's wait with re-running unity stack till when my branches get FINALLY merged
[07:49] <didrocks> sil2100: we will restart it
[07:49] <didrocks> and then, rerun everything
[07:49] <didrocks> as the prepare failed because of a bad environment when jenkins was started
[07:49] <didrocks> (all the jobs failed, even a trivial one)
[07:54] <sil2100> didrocks: are we cursed?
[07:54] <sil2100> ;/
[07:55] <dandrader> MacSlow, have you seem this error before? http://paste.ubuntu.com/5689613/
[07:55] <didrocks> sil2100: yeah, since the sprint, it seems we really are
[07:55] <dandrader> MacSlow, it happened in this test run: http://s-jenkins:8080/job/unity-phablet-qmluitests/958/console
[07:56] <sil2100> didrocks: btw. are the mergers on the same jenkins as cu2d ?
[07:56] <sil2100> didrocks: or is it on s-jenkins?
[07:57] <didrocks> sil2100: it's on s-jenkins
[07:57] <didrocks> sil2100: so different machines
[07:57] <sil2100> Phew, still, waiting 1 hour to get a merge in is strange
[07:57] <didrocks> sil2100: you think the job is blocked?
[07:58] <sil2100> didrocks: no idea, yesterday my autopilot branch was building for like an hour, and finally it got merged
[07:58] <sil2100> No idea why it was taking so long
[07:58] <didrocks> mmrazik: do you mind giving a look? ^ (hey!)
[07:58] <didrocks> sil2100: any url?
[07:58] <didrocks> sil2100: so, before restarting the QA stack, I should wait for an autopilot branch to get merged?
[07:58] <sil2100> mmrazik, didrocks: https://code.launchpad.net/~sil2100/unity/autopilot_hud_more_fixes/+merge/164880
[07:58] <didrocks> ah, on unity :)
[07:59] <didrocks> so I can restart the QA stack ASAP
[08:00] <sil2100> didrocks: QA yes, I wonder if it will be ok ;)
[08:01] <mmrazik> sil2100, didrocks: its building. the panda builds are taking ages :-/
[08:01] <mmrazik> sil2100: your branch is ~55% compile atm
[08:01] <didrocks> thanks mmrazik :)
[08:02]  * mmrazik is looking forward the new build servers
[08:02] <mmrazik> sil2100: looks like about 1h15 min to go :-/
[08:04] <sil2100> Arrrgh!
[08:04] <sil2100> mmrazik: thanks
[08:05] <sil2100> So it's the panda at fault again
[08:37] <MacSlow> dandrader, hm... that's new
[08:39] <dandrader> MacSlow, it doesn't happen when I run it locally. on the other hand jenkins doens't seem to be working reliably lately
[08:40] <MacSlow> dandrader, it was certainly working until yesterday (been in trunk for a week now) ... I can't tell what might introduce this failure
[08:41] <MacSlow> dandrader, the error-message doesn't even point to the qml-file this actually happens in
[08:42] <MacSlow> dandrader, I'll be running my own tests on jenkins later today and will keep an eye on this... should I run into it too (or find a solution/fix) I'll let you know
[08:47] <tsdgeos> Saviq: Mirv only copied the fixed  qtdeclarative-opensource-src  to daily-build-next but not to qt5-proper, meaning we don't get it on the desktop (since afair we are recommending to not install that on the desktop)
[08:47] <tsdgeos> shall we ask him to copy it there too?
[08:48] <Saviq> tsdgeos, yeah, I thought the target is qt5-proper for raring, Mirv?
[08:48] <tsdgeos> paulliu: you have a whitespace issue at https://code.launchpad.net/~paulliu/unity/phablet-fake-peoplepreviewdata/+merge/161514 can you fix?
[08:49] <dandrader> mzanetti, what do you think about making autopilot tests use only touch and not mouse. afterall so far we are testing only touch UIs (phone and tablet?
[08:49] <Mirv> tsdgeos / Saviq: nowadays any device related raring is targetted to daily-build-next, qt5-proper is not anymore used on the device. if you want the fix also to desktop users, I can copy it also to qt5-proper sure.
[08:50] <tsdgeos> Mirv: i think we do, yes
[08:50] <Saviq> Mirv, thanks
[08:50] <Mirv> ok, soon there
[08:52]  * dandrader recalls that mzanetti is out today
[08:52] <dandrader> Saviq,  what do you think about making autopilot tests use only touch and not mouse. afterall so far we are testing only touch UIs (phone and tablet)
[08:53] <MacSlow> dandrader, yeah... just figured that out too :)
[08:53] <Saviq> dandrader, yeah, sounds right
[09:06] <paulliu> tsdgeos: ok..
[09:06] <paulliu> tsdgeos: wait..
[09:12] <tsdgeos> Saviq: gave you the carousel blueprint since you've done the MR
[09:13] <Saviq> tsdgeos, sure, cheers
[09:20] <dandrader> Saviq, do you known who can help with unity jenkins problems during mzanetti's absence?
[09:20] <Saviq> dandrader, what kind of issues?
[09:20] <dandrader> Saviq, http://s-jenkins:8080/job/unity-phablet-qmluitests/962/console
[09:21] <Saviq> dandrader, uh, interesting
[09:23] <nic-doffay> tsdgeos, ping
[09:24] <dandrader> mmrazik, ping
[09:24] <tsdgeos> nic-doffay: hi
[09:24] <mmrazik> dandrader: pong
[09:24] <dandrader> mmrazik, can you help me with autopilot.input.Touch?
[09:25] <mmrazik> dandrader: I don't know much about it :-/ maybe mzanetti (^^^)?
[09:25] <mmrazik> dandrader: btw. there is also #ubuntu-autopilot
[09:25] <nic-doffay> tsdgeos, trying to build unity 7.0
[09:25] <tsdgeos> dandrader: just retrigger that build :D
[09:25] <nic-doffay> haveing issues.
[09:25] <nic-doffay> Mind looking at my pastebin?
[09:25] <dandrader> mmrazik, hmm, ok. mzanetti is offline today
[09:25] <mmrazik> dandrader: then sergiusens might be able to help too
[09:25] <Saviq> dandrader, the failure seemed temporary, I've restarted to see
[09:26] <tsdgeos> nic-doffay: sure, but not that i know much about unity7
[09:26] <dandrader> Saviq, it's already the second time I restart it
[09:27] <Saviq> dandrader, still, this ran fine http://s-jenkins:8080/job/unity-phablet-qmluitests/963/console
[09:27] <nic-doffay> tsdgeos, nm then
[09:28] <Saviq> dandrader, let's see
[09:29] <nic-doffay> Anyone tried building Unity 7.0 recently?
[09:29] <Saviq> dandrader, it seems to go fine now http://s-jenkins:8080/job/unity-phablet-qmluitests/964/console
[09:29] <sil2100> mmrazik: just to make sure - is every merge in lp:unity now taking around 1.5h to finish due to the armhf pandaboard slowness?
[09:29] <mmrazik> sil2100: yes
[09:29] <mmrazik> but I think its the case for quite some time already
[09:30] <tsdgeos> nic-doffay: i'd say bregma since it's his team work field afaik
[09:30] <nic-doffay> bregma, any tips on building 7.0?
[09:31] <Saviq> nic-doffay, he's in Canada, sleeping ;)
[09:31] <Saviq> nic-doffay, your pastebin?
[09:32] <nic-doffay> Saviq, https://pastebin.canonical.com/91423/
[09:39] <Saviq> nic-doffay, sil2100 should be able to help - you're probably missing a new libindicators
[09:40] <Saviq> nic-doffay, here's the commit introducing that http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3293
[09:42] <Saviq> nic-doffay, and here's the corresponding libindicator commit http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/libindicator/raring/revision/32
[09:43] <Saviq> nic-doffay, so that change seems to be there in raring-proposed at least - you should enable raring-proposed in your update settings, upgrade from there and you should be fine
[09:44] <nic-doffay> Saviq, where can I update that?
[09:44] <Saviq> nic-doffay, enable raring-proposed
[09:46] <dandrader> Saviq, those tests are consistently failing http://s-jenkins:8080/job/unity-phablet-qmluitests/964/?
[09:46] <Saviq> dandrader, yeah, saw that
[09:47] <dandrader> no idea why
[09:48] <Saviq> dandrader, what's even weirder is that it fails locally now, too
[09:48] <dandrader> Saviq, ah, that's excellent news! they are working for me locally
[09:48]  * dandrader tries again
[09:48] <nic-doffay> Saviq, I'm missing something. Still not sure how to enable this.
[09:49] <Saviq> nic-doffay, go to your software settings
[09:49] <Saviq> "Software and updates" in the dash or something
[09:49] <Saviq> and in "Updates" tab check the checkbox next to raring-proposed
=== dandrader is now known as dandrader|afk
[09:50] <nic-doffay> Saviq, got it, nice one.
[09:50] <Saviq> MacSlow, do the Notification tests pass for you?
[09:51] <Saviq> ah, I wonder if that's new Qt's fault
[09:52] <MacSlow> Saviq, locally not atm as I'm working on the additional action-buttons... but I've seen dandrader's trouble earlier
[09:52] <Saviq> tsdgeos, do you have the patched Qt installed?
[09:52] <tsdgeos> Saviq: yep, just landed in qt-proper
[09:52] <MacSlow> Saviq, since the renderer is in trunk for a week and worked sofar, I'm assuming it's the newer Qt
[09:52] <Saviq> tsdgeos, can you `make -C builddir testNotifications`?
[09:52] <tsdgeos> what's wrong?
[09:52]  * tsdgeos tries
[09:53] <MacSlow> tsdgeos, Saviq: http://paste.ubuntu.com/5689613
[09:53] <Saviq> tsdgeos, http://pastebin.ubuntu.com/5689863/
[09:53] <MacSlow> tsdgeos, Saviq: that's what dandrader ran into
[09:53] <Saviq> yup
[09:53] <Saviq> same thing
[09:53] <Saviq> so the new Qt is exposing some issues
[09:53] <MacSlow> tsdgeos, Saviq: I wonder if that's perhaps from the findChild() function
[09:54] <tsdgeos> that is weird, did we get anything in it other than my listview fixes?
[09:54] <Saviq> tsdgeos, http://s-jenkins:8080/job/unity-phablet-qmluitests/964/testReport/? there's one more test failing, too
[09:57] <Saviq> got a fix for notifications
[09:57] <MacSlow> Saviq, what's causing the issue?
[09:57] <Saviq> MacSlow, count is updated before the delegate is rendered
[09:58] <MacSlow> outch :)
[09:58] <tsdgeos> ah yes
[09:58] <Saviq> MacSlow, http://pastebin.ubuntu.com/5689872/
[09:58] <tsdgeos> you need the magical forceLayout
[09:58] <tsdgeos> or wathever crap was introduced
[09:59] <MacSlow> Saviq, tsdgeos: so that fix or forceLayout... what should we opt for?
[10:00] <MacSlow> Saviq, I can work that change into the current test-addition I'm doing
[10:00] <tsdgeos> well it depends
[10:00] <tsdgeos> is it needed only for the test or does the "real" code needs the forceLayout to be there?
[10:00] <tsdgeos> if it's only for the test Saviq's fix seems good enough
[10:00] <MacSlow> tsdgeos, I think it's only needed for the test
[10:01] <Saviq> tsdgeos, what's the forceLayout?
[10:01] <tsdgeos> Saviq: https://codereview.qt-project.org/#patch,all,55801,1
[10:02] <tsdgeos> basically if you expect things to be "uptodate" in javascript between view and model
[10:02] <tsdgeos> you need to ask the view to sync itself
[10:02] <tsdgeos> it's part of the fix for our crashers
[10:02] <tsdgeos> since they were basically recursion issues
[10:02] <Saviq> k
[10:03] <Saviq> sounds like it's a test-only issue for us, then
[10:03] <tsdgeos> Saviq: the commit http://paste.kde.org/~tsdgeos/748592/
[10:06] <Saviq> tsdgeos, MacSlow, dandrader|afk, https://code.launchpad.net/~saviq/unity/phablet.fix-listview-tests/+merge/165050
[10:06] <nic-doffay> Saviq, no dice with that setting.
=== dandrader|afk is now known as dandrader
[10:07] <Saviq> nic-doffay, $ grep context /usr/include/libindicator-0.4/libindicator/indicator-desktop-shortcuts.h ?
[10:08] <dandrader> Saviq, what's lp:unity/phablet-mods?
[10:08] <Saviq> dandrader, ugh
[10:08] <dandrader> Saviq, your merge proposal: " Merge into: 	lp:unity/phablet-mods"
[10:08] <Saviq> dandrader, https://code.launchpad.net/~saviq/unity/phablet.fix-listview-tests/+merge/165051
[10:09] <Saviq> dandrader, thanks for spotting that
[10:13] <Saviq> nic-doffay, something's wrong on your side, that function is there in libindicator-dev=12.10.2daily13.04.10-0ubuntu1
[10:14] <Saviq> nic-doffay, which is actually in raring main already
[10:15] <Saviq> biab
=== alan_g is now known as alan_g|tea
[10:30] <ritz_> sil2100, hi, busy ? any thoughts on bugs.launchpad.net/bugs/1125442 ?
[10:30] <ritz_> from the code, I see window on top always has the focus
[10:30] <ritz_> the same is seen with mutter/gnome-shell
[10:31] <ritz_> is this the default behaviour
[10:33] <ritz_> and the designed behaviour
=== ritz_ is now known as ritz|away
[10:42] <sil2100> ritz|away: hi! I'll take a look in a moment
=== alan_g|tea is now known as alan_g
[10:53] <dandrader> Saviq, how is a DirectionalDragArea help in the Panel. A simple tap is enough to open it.
[10:54] <dandrader> better use it on the Stage first
[10:56] <dandrader> tsdgeos, qmltestrunner.FilterGrids::test_clicked_signal is still randomly failing. better get to the old wait(1) workaround
[10:57] <dandrader> tsdgeos, http://s-jenkins:8080/job/unity-phablet-qmluitests/965/?
[11:01] <dandrader> Saviq, you could try adding a wait(1) to fix the Overview test
[11:01] <dandrader> things are getting desperate :)
=== pete-woods is now known as pete-woods-lunch
=== MacSlow is now known as MacSlow|lunch
[11:04] <tsdgeos> dandrader: it's a different failure, i think, probably needs some other waitForRendering around
[11:05] <tsdgeos> Saviq: you taking care of it?
[11:05] <dandrader> tsdgeos, ah, true
[11:12] <sil2100> ritz|away: let us pass this bug to JohnLea and the design team
[11:20] <Saviq> dandrader, you can also drag down from it to select an indicator straight away
[11:20] <Saviq> dandrader, and also in fullscreen you need to edge-drag from the top
[11:20] <Saviq> dandrader, try with media player or camera
[11:21] <Saviq> tsdgeos, yeah, I will
[11:21] <Saviq> ok so the waitForRendering didn't help for the overview
=== gusch is now known as gusch|away
=== dandrader is now known as dandrader|lunch
[11:53] <Saviq> Cimi, I like it how you gained sympathy to tests ;)
[11:56] <greyback> Saviq: speaking of tests, the WM bugs I'm fixing are due to interaction between Shell, Showable and Stage. How would you recommend me try to test them? I could try writing a mock Shell...
[11:56] <greyback> ...but it's actually code in Shell I need to test
[11:57] <Saviq> greyback, can't the behaviour be tested separately?
[11:58] <Saviq> greyback, right, if you load Shell.qml you'll just get the whole thing
[11:58] <greyback> Saviq: yeah, that's my main issue.
[11:58] <Saviq> greyback, maybe it'd make sense to abstract that part? we're going to have to drop Shell.qml at some point anyway
[11:58] <sil2100> mmrazik: hi, could you re-check if https://code.launchpad.net/~fginther/unity/autopilot_hud_button_label_fixes/+merge/164999 is still building?
[11:58] <sil2100> Since 2h is a bit much!
[11:59] <greyback> Saviq: abstract what exactly? The WM-logic parts of shell?
=== alan_g is now known as alan_g|lunch
[12:02] <mmrazik> sil2100:  its indeed not :-/ should be fixed/queued now
[12:04] <greyback> bbiab, need to eat.
=== greyback is now known as greyback|lunch
[12:05] <Saviq> greyback|lunch, we could just have both Stages in a separate component, with corresponding bindings and connections for WM, no?
[12:10] <Saviq> greyback|lunch, i.e. put the WM-relevant parts of Shell.qml in a separate component
=== MacSlow|lunch is now known as MacSlow
[12:14] <greyback|lunch> Saviq: probably yes. I'll do that with your go-ahead
[12:14] <Saviq> greyback|lunch, you have my go-ahead ;)
[12:14] <Saviq> greyback|lunch, and cheew
[12:14] <Saviq> ...
[12:15] <greyback|lunch> Saviq: I'm eating at my computer, it's raining outside so can't go out
[12:15] <Saviq> ;)
=== pete-woods-lunch is now known as pete-woods
=== _salem is now known as salem_
[12:23] <Kaleo> larsu: hi, do you some time to talk about GSettingsQt?
[12:24] <larsu> Kaleo: sure
[12:24] <Kaleo> larsu: mumble?
[12:24] <larsu> Kaleo: yup, give me a minute
[12:26] <larsu> Kaleo: which channel?
[12:27] <sil2100> cyphermox: ping
[12:28] <Saviq> Kaleo, can I lurk in?
[12:28] <Kaleo> Saviq: sure
[12:29] <Kaleo> larsu: can you hear anything?
[12:30] <larsu> Kaleo: no.
[12:31] <larsu> are you talking?!
[12:31] <Kaleo> larsu: yes
[12:31] <larsu> interesting. let me restart mumble
=== dandrader|lunch is now known as dandrader
=== greyback|lunch is now known as greyback
[12:49] <sil2100> JohnLea: hi! Could you take a look at LP: #1125442 when you have a moment?
[12:49] <ubot5> Launchpad bug 1125442 in unity (Ubuntu Raring) "Always Visible and On Top Windows Steal Focus on Workspace Switch" [Medium,Confirmed] https://launchpad.net/bugs/1125442
[12:50] <JohnLea> sil2100; that looks like a bug to me.  However the "Always on Top" functionality is depreciated, and won't be included in the first version of the MIR based Unity 8.
[12:51] <JohnLea> sil2100; would be nice to get that fixed if possible, but it is not high priority
[12:51] <paulliu> Saviq: hi. I just make the translation work. generating mo and install works. I see the Chinese translated messages. But the problem is I cannot just use Binding in shell.qml. I still have bindtextdomain() stuff in my main.cpp to make the whole thing work. Is there anything I missed?
[12:53] <Saviq> paulliu, can you show me the code?
[12:53] <paulliu> Saviq: yes. wait.
[12:54] <Saviq> paulliu, bindtextdomain() should only be needed for non-installed translations, no?
=== gusch|away is now known as gusc
[12:54] <paulliu> Saviq: it needs anyway. Need to map "unity" to "${INSTALLPATH}/locale"
[12:55] <paulliu> Saviq: and then textdomain("unity") to use it.
[12:55] <sil2100> JohnLea: could you leave a comment? I would also ask someone to decrease the Importance to Low then
[12:55] <paulliu> Saviq: binding only runs textdomain.
[12:55] <Saviq> paulliu, if it gets installed to a system-wide locale database (/usr/share/locale/...), it should get picked up, no?
[12:56] <andyrock> sil2100, review please? https://code.launchpad.net/~andyrock/unity/fix-crash-tests/+merge/165069 :)
[12:57] <sil2100> andyrock: sure thing!
[12:57] <andyrock> thx
[12:57] <paulliu> Saviq: yeah, should be.
=== alan_g|lunch is now known as alan_g
[12:58] <Saviq> paulliu, so we should only need bindtextdomain() when running uninstalled, right?
[12:58] <paulliu> Saviq: yes.
[13:00] <paulliu> Saviq: but the files are installed to builddir/install so we can use it?
[13:01] <Saviq> paulliu, yeah, it should be possible to use it from uninstalled, too (built-only)
[13:01] <Saviq> paulliu, but that's a separate issue
[13:02] <paulliu> Saviq: ok.
=== hikiko is now known as hikiko_lunch
[13:21] <Cimi> safe to upgrade to 13.10 with our ubuntu touch development?
[13:23] <Saviq> Cimi, should be, yes
[13:27]  * Cimi is upgrading
[13:31] <cyphermox> good morning!
[13:31] <cyphermox> sil2100: pong
[13:31] <sil2100> cyphermox: morning!
[13:32] <sil2100> cyphermox: I have been wondering... since you're maintaining the indicator stack, right? Do you know why there hasn't been a new indicator-appmenu in daily-build-next, even though there's one unreleased commit since a long time?
[13:32] <cyphermox> indicators are disabled
[13:33] <cyphermox> on request from ted and larsu, to give them time to do the updates to gmenumodel and phablet stuff, IIRC
[13:34] <sil2100> Ah, shit, right!
[13:34] <sil2100> My bad, forgot about that completely
[13:34] <sil2100> cyphermox: would it be possible to release manually a single package?
[13:34] <sil2100> Since indicator-appmenu has a commit that's needed for the proper working of unity-gtk-module
[13:35] <cyphermox> sure
[13:35] <sil2100> cyphermox: could you spin the wheel at least for indicator-appmenu then? I would be really grateful :)
[13:35] <sil2100> Thanks!
[13:37] <cyphermox> np
=== hikiko_lunch is now known as hikiko
[13:59] <cyphermox> sil2100: indicator-appmenu will publish soonish in daily-build; then I'll run the tests and we can see if it's all ready to publish
[14:00] <sil2100> cyphermox: thanks ;)
[14:13] <cyphermox> sil2100: I think the fuzzy search for hud is genuinely failing tests
[14:14] <paulliu> Saviq: help reviewing? https://code.launchpad.net/~paulliu/unity/i18n/+merge/165160
[14:15] <paulliu> Saviq: Just support the translations. I'll look into the UI and the code and add more strings for translation.
[14:15] <sil2100> cyphermox: it might, but well, wait with looking at HUD tests until we make a re-build of unity with all the unity branches merged in
[14:15] <paulliu> Saviq: And remove some strings not for translation.
[14:16] <sil2100> cyphermox: since me and fginther made some fixes to HUD AP tests
[14:16] <sil2100> But those did not get merged in time due to jenkins barfing
[14:17] <fginther> sil2100, my branch has now been merged
[14:17] <sil2100> fginther: YESS, finally!
[14:17] <sil2100> \o/
[14:17] <sil2100> didrocks: I think we can re-run unity stack
[14:18] <didrocks> sil2100: ok, will do that once QA had a chance to really debug the jenkins issue
[14:19] <cyphermox> sil2100: I see that at least some of them have landed already
[14:21] <dandrader> Saviq, can I have your "ok" here: https://code.launchpad.net/~dandrader/unity/phablet_mouseTouchAdaptor/+merge/164870
[14:23] <Saviq> dandrader, yeah, I'll do it today for sure
=== alan_g is now known as alan_g|tea
[14:26] <kgunn> greyback: telling you to help prompt my memory later
[14:26] <kgunn> one thing could be
[14:26] <greyback> kgunn: go on
[14:26] <kgunn> is that mir doesn't have "bypass composition"
[14:26] <kgunn> and possibly proper use of hwc to get overlay support
[14:26] <greyback> kgunn: can you explain what that is?
[14:27] <kgunn> its all about reads/writes of pixels
[14:27] <kgunn> basically when an app renders into an "offscreen buffer"
[14:27] <kgunn> he's gonna read textures & render his scene
[14:28] <kgunn> which then that buffer gets read in again as a texture & then render(writes) to the FB
[14:28] <kgunn> bypass comp smartly says, if there is a full screen render....skip the composition part
[14:28] <kgunn> let the app just render into the FB
[14:28] <greyback> ah I see
[14:29] <kgunn> and some HWC implementations provide overlays which are specialized hw which usually have caveats (fickle)
[14:29] <kgunn> but do composition really fast compared to going thru the gpu
[14:30] <kgunn> so when the gpu is doing composition...his load is effectively split between app render & composition
[14:30] <kgunn> so hwc overlays also help just in the nature of unloading the gpu & lowering the effective pixel thruput on the gpu
[14:30] <greyback> yep, makes sense, sounds very nice to ahve
[14:30] <kgunn> alan_g|tea: is working on bypass comp this week...
[14:31] <kgunn> but it might be the reason for an effective doubled frame rate
[14:31] <kgunn> once you miss a 16ms deadline on a video mode display...you automatically get bumped into 30 fps
[14:32]  * kgunn wonders if the displays on these devices are command mode or video mode
=== dandrader is now known as dandrader|afk
=== alan_g|tea is now known as alan_g
=== dandrader|afk is now known as dandrader
[14:52] <sil2100> pete-woods: hi! Regarding our yesterday's hud talk, I filled in a bug for the thing I noticed: LP: #1182900
[14:52] <ubot5> Launchpad bug 1182900 in Unity HUD "hud-service slowing down the whole system after using the HUD multiple times" [Undecided,New] https://launchpad.net/bugs/1182900
=== mmrazik is now known as mmrazik|afk
[15:23] <Saviq> dandrader, q: should we not enable the mouse touch adaptor by default?
[15:24] <dandrader> Saviq, I wouldn't like to have it when building for the device
[15:24] <Saviq> dandrader, we can make it false in run_on_device
[15:24] <dandrader> Saviq, but I would like to when building for autopilot
[15:25] <dandrader> Saviq, and it should also be disabled when building for the device
[15:25] <dandrader> building the deb I mean
[15:26] <Saviq> dandrader, yeah, it doesn't use the ./build script
[15:26] <Saviq> dandrader, but also, autopilot uses the debs, doesn't it?
[15:27] <dandrader> Saviq, I don't know
[15:27] <dandrader> Saviq, but it probably does...
[15:29] <dandrader> Saviq, don't autopilot use some special build rules to add the testability during compilation?
[15:30] <Saviq> dandrader, potentially yes, and that should help us
[15:30] <Saviq> dandrader, https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder/1928/consoleFull here's one of the build logs
[15:30] <Saviq> that build for mediumtests-runner (aka where autopilot runs
[15:31] <dandrader> Saviq, hmm, seems the testability lib is loaded at runtime in response to a command line argument
[15:31] <Saviq> dandrader, uh, right
[15:32] <Saviq> dandrader, that's why I'm leaning towards run-time option only
[15:32] <dandrader> Saviq, the drawback of this is that we will bring in the QTestLib dependency
[15:34] <tvoss> larsu, ping
[15:34] <Saviq> dandrader, yeah, so if we could get it so that we only build like this for autopilot
[15:35] <larsu> tvoss: hey
[15:35] <Saviq> dandrader, we could go with a build-time decision
=== gusc is now known as gusch
=== jhodapp is now known as jhodapp|brb
[15:42] <Saviq> dandrader, otherwise it's fine, but I'm just afraid of suddenly losing the ability to get the launcher in with your mouse
[15:42] <Saviq> dandrader, i.e. it should be enabled by default on desktop usage
[15:47] <dandrader> Saviq, ok, so we always build support for it (and therefore bring in the QtTest dependency). But should we enable it by default? (I would say a -mousetouch argument should be required)
[15:49] <Saviq> dandrader, yeah, but then ./run will have it by default
[15:50] <Saviq> dandrader, and autopilot will call it with that argument
[15:50] <Saviq> dandrader, and we can have ./run_on_device disable it
[15:50] <Saviq> via ./run --no-mousetouch
[15:50] <Saviq> or similar
=== ritz_ is now known as ritz|here
[15:52] <dandrader> Saviq, ok, I'll make the changes
[15:52] <Saviq> dandrader, cheers
[15:55] <ritz|here> sil2100++ thanks
=== gusch is now known as gusch|brb
=== jhodapp|brb is now known as jhodapp
[16:20] <dandrader> Saviq, done
=== salem_ is now known as _salem
=== gusch|brb is now known as gusch
=== jhodapp is now known as jhodapp|lunch
=== alan_g is now known as alan_g|life
[17:37]  * greyback eod
[17:38] <kgunn> greyback: see ya
=== _salem is now known as salem_
=== jhodapp|lunch is now known as jhodapp
=== marlinc is now known as Marlinc
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== racarr is now known as racarr|curry
=== racarr|curry is now known as racarr
=== salem_ is now known as _salem
=== _salem is now known as salem_