| 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:31 |
| 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:32 |
| 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 | 01:38 |
| 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:29 |
| duflu | or binutils... something fixed it | 03:30 |
| duflu | Impressive given bin/mir_unit_tests.bin is 241MB | 03:31 |
| 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:34 |
| RAOF | ?? | 03:37 |
| RAOF | We *do* strip the symbols after building the packages. Why would we build two sets of DSOs, one stripped one not? | 03:38 |
| 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:56 |
| duflu | One set of DSOs built, but two variants of that build released. | 03:57 |
| RAOF | But we don't *have* any superfluous symbols in the released DSOs? | 04:00 |
| RAOF | Ah, no, I think I understand what you mean. | 04:01 |
| RAOF | I don't see why we'd bother, but I think I see what you mean :) | 04:02 |
| 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) | 04:03 |
| anpok | alf_: could your workaround fix RAOFs enable-lto branch? | 07:32 |
| duflu | Funny thing about mice being relative devices - you can have multiple plugged in and use any/all of them | 08:13 |
| === faenil_ is now known as faenil | ||
| anpok | yay and use them to have multiple cursors on screen.. | 08:24 |
| alf_ | anpok: I don't know, let me take a look | 08:34 |
| anpok | i wanted to rebuild his branch as soon as yours lands.. it seems to not link pthread on armhf vivid | 08:37 |
| 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:42 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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 | 08:51 |
| === chihchun_afk is now known as chihchun | ||
| === faenil is now known as faenil_ | ||
| === faenil_ is now known as faenil | ||
| === HobGoblin is now known as UukGoblin | ||
| 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:07 |
| Saviq | I'm not sure what happened there | 10:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| alf_ | Saviq: so when rebuilding ${BUILD_URL} contains the URL of the original build? | 10:17 |
| Saviq | alf_, seems so | 10:18 |
| Saviq | alf_, I'll have a few tries to see what's in env | 10:18 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| 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:50 |
| Mirv | anpok: we're just trying to figure out if we can get a Mir backend coding started for qtsystems | 12:51 |
| pax55 | anpok, ^^ | 13:03 |
| === dandrader is now known as dandrader|afk | ||
| anpok | Mirv: still in progress.. the last two or three weeks other things were more important | 13:20 |
| Mirv | zsombi: ^ | 13:25 |
| Mirv | anpok: ok, thanks for the update | 13:25 |
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| anpok | kdub: yes i agree .. seems like a lot of stuff | 16:16 |
| 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:17 |
| anpok | hm or would resize only change the buffer size but not the the other parameters of presentation chain? | 16:18 |
| anpok | s/would resizse only change/would resize only require a change of/ | 16:19 |
| === dandrader|afk is now known as dandrader | ||
| kdub | anpok, the spec can be applied before the surface creation as well | 16:51 |
| kdub | and which "resize"? | 16:51 |
| 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 | 16:52 |
| anpok | hm the resize as in the client decides to follow a resize event and submit the next buffer in a different size | 17:19 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| === dandrader_ is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === chihchun is now known as chihchun_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!