[01:31] <duflu> robert_ancell_: Thank you again. I should have made up my mind before I asked you the first time
[01:31] <robert_ancell_> duflu, :)
[01:31] <duflu> Interestingly it means that feature isn't blocked by the two bugs that we just fixed, but also one or two new bugs not yet reported
[01:32] <duflu> I may have to redesign the frame scheduling in Xmir to better deal with it. And/or (hopefully not) finish implementing GLX swap control
[01:38] <duflu> Weird one of the issues was noticeably lower smoothness in Unity8 vs Mir demo shells. That might be the QtMir issue already in my name
[03:29] <duflu> RAOF: The latest gcc for xenial got linking of mir_unit_tests from 3 minutes back down to 15.9 seconds. Is gold still faster?
[03:30] <duflu> or binutils... something fixed it
[03:31] <duflu> Impressive given bin/mir_unit_tests.bin is 241MB
[03:34] <duflu> Sigh. If we stripped symbols after building and use the unstripped DSOs for the tests, that could be 100 times smaller still
[03:34] <duflu> Although symbol versions makes that very hard to do
[03:37] <RAOF> ??
[03:38] <RAOF> We *do* strip the symbols after building the packages. Why would we build two sets of DSOs, one stripped one not?
[03:56] <duflu> RAOF: I mean build one with everything (so mir tests don't need to use object libraries) and then copy and strip the unwanted bits for release DSOs
[03:57] <duflu> One set of DSOs built, but two variants of that build released.
[04:00] <RAOF> But we don't *have* any superfluous symbols in the released DSOs?
[04:01] <RAOF> Ah, no, I think I understand what you mean.
[04:02] <RAOF> I don't see why we'd bother, but I think I see what you mean :)
[04:03] <duflu> RAOF: In the least you get one shared copy of the test DSOs between mir*tests, instead of each getting its own
[04:03] <duflu> Quicker build and less disk space
[04:03] <duflu> Might be fun to try some day
[04:03] <duflu> Again.. (I have tried similar in the past)
[07:32] <anpok> alf_: could your workaround fix RAOFs enable-lto branch?
[08:13] <duflu> Funny thing about mice being relative devices - you can have multiple plugged in and use any/all of them
[08:24] <anpok> yay and use them to have multiple cursors on screen..
[08:34] <alf_> anpok: I don't know, let me take a look
[08:37] <anpok> i wanted to rebuild his branch as soon as yours lands.. it seems to not link pthread on armhf vivid
[08:42] <alf_> anpok: looking at the error message you pasted, it's the same thing my MP fixes (just for mir_demo_server). Given that RAOF's branch doesn't use ld.gold, it's a good chance that the problem is in fact in g++/libstdc++-4.0
[08:42] <alf_> anpok: -4.9
[08:48] <anpok> duflu: on touchpad scrolling.. there is another thing blocking us.. we still do report ticks even on touchpads... which are scaled (/15.0f) touchpad gestures..
[08:48] <anpok> if there is an integer conversion downstream.. we loose the accuracy
[08:49] <duflu> anpok: Yet nautilus and Gnome apps have one-pixel accurate touch scrolling... some other way
[08:49] <anpok> on top of mir too?
[08:49] <duflu> anpok: I'm only talking about Unity7
[08:49] <anpok> ok
[08:50] <anpok> just curious if we need to offer both assumed ticks and the unscaled scroll moves too..
[08:50] <duflu> anpok: Both are required yes. You never know which the app is able to use
[08:51] <duflu> anpok: I did notice libinput synthesises a mouse wheel with two finger touches... Can now zoom with Super+two fingers :)
[08:51] <duflu> Although it's super-sensitive
[10:07] <Saviq> alf_, looks like jenkins defeated your python foo after all :/ https://code.launchpad.net/~gerboland/qtmir/fix-orientation-after-unplug/+merge/286065/comments/728945
[10:08] <Saviq> I'm not sure what happened there
[10:09] <Saviq> alf_, OTOH it might actually be the fault of the -ci job, it passed the wrong build number
[10:09] <greyback> Saviq: it reports test fail
[10:10] <alf_> Saviq: greyback: What's the problem with the output?
[10:10] <Saviq> greyback, but that's the correct run https://unity8-jenkins.ubuntu.com/view/Launchpad/job/lp-qtmir-1-ci/77/
[10:10] <Saviq> greyback, and that one's passed
[10:11] <Saviq> alf_, PASSED, but all builds FAILED ;)
[10:11] <greyback> I dunno, just sawing what I see in the failed log
[10:11] <Saviq> alf_, someohow ${BUILD_URL} pointed at the previous run (again, rebuilds)
[10:11] <alf_> Saviq: ...
[10:12] <Saviq> greyback, yeah, I know why the builds failed, but notice it's the same run https://code.launchpad.net/~gerboland/qtmir/fix-orientation-after-unplug/+merge/286065/comments/728908
[10:12] <Saviq> while it should be 77, which passed
[10:13] <Saviq> alf_, it's dumb, see https://unity8-jenkins.ubuntu.com/view/Launchpad/job/lp-qtmir-1-ci/77/console
[10:13] <Saviq> alf_, and then parameters for https://unity8-jenkins.ubuntu.com/job/lp-generic-2-update-mp/475/parameters/
[10:13] <Saviq> ¿?
[10:13] <Saviq> rebuilds seem to confuse jenkins these days a lot
[10:17] <alf_> Saviq: so when rebuilding ${BUILD_URL} contains the URL of the original build?
[10:18] <Saviq> alf_, seems so
[10:18] <Saviq> alf_, I'll have a few tries to see what's in env
[12:50] <Mirv> anpok: any news on a Mir input info API to use from Qt Systems? you've reportedly mentioned it being in progress on Feb 4th
[12:50] <zsombi> anpok: ping
[12:50] <zsombi> Mirv: :D
[12:50] <Mirv> :D
[12:50] <zsombi> anpok: my ping is for teh same as Mirv's :D
[12:51] <Mirv> anpok: we're just trying to figure out if we can get a Mir backend coding started for qtsystems
[13:03] <pax55> anpok, ^^
[13:20] <anpok> Mirv: still in progress.. the last two or three weeks other things were  more important
[13:25] <Mirv> zsombi: ^
[13:25] <Mirv> anpok: ok, thanks for the update
[16:16] <anpok> kdub: yes i agree .. seems like a lot of stuff
[16:17] <anpok> i was thinking about the resize handling.. which is probably the usual case for having different sized buffers in the presentation chain
[16:17] <anpok> is the idea there to create the whole surface setup.. create a new chain.. submit buffer and then apply spec?
[16:18] <anpok> hm or would resize only change the buffer size but not the the other parameters of presentation chain?
[16:19] <anpok> s/would resizse only change/would resize only require a change of/
[16:51] <kdub> anpok, the spec can be applied before the surface creation as well
[16:51] <kdub> and which "resize"?
[16:52] <kdub> a resize message, initiated by the shell/server would be a notification, and then in the case of MirPresentationChains, let the client-user figure it out, and in the case of MirBufferStreams, libmirclient will auto-manage the size transition
[17:19] <anpok> hm the resize as in the client decides to follow a resize event and submit the next buffer in a different size