=== chihchun_afk is now known as chihchun [05:33] On the plus side, I'm maybe a third of the way into making QtMir handle multiple bufferstreams. === chihchun is now known as chihchun_afk [05:49] Oh, yeah. [05:49] Lots of QSimulcrumOfStl, but it's all slightly worse. [05:50] Although I guess CoW is pretty cool. [05:54] simulcrum? [05:59] Sumulcrum? [05:59] Simulcrum? [05:59] Q? [05:59] My standard misspelling of simulacrum. [05:59] https://www.wikiwand.com/en/Simulacrum [06:00] For those not familiar with the obscure brand of English I sometimes spout. [06:00] oh I thought of something like simula cruft.. [06:00] which didnt really fit [06:11] RAOF: Recently discovered Qt logging doesn't understand std::string, but instead requires construction of QString from std::string first. That was odd [06:41] test === marcusto_ is now known as marcustomlinson === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:00] greyback: does the CI failure mean anything to you? It doesn't seem related and I've not reproduced (but not tried to set up identical environment yet). https://code.launchpad.net/~alan-griffiths/qtmir/test-harness-for-MirWindowManager/+merge/267369 [10:01] alan_g: looks unrelated yes. Something else is broken in CI === chihchun is now known as chihchun_afk [11:24] hey guys, there's an email thread on phone ML, someone's having issues with DPI not being reported by QScreen, so likely it's not set by... and now the question - by what? graphics driver? [11:25] (the subject is "help with touchscreen configuration...") [11:27] tvoss, you might know ↑ [11:28] Saviq: qtmir/qtubuntu supply it if they can, but they don't currently. Qt will calculate it from physical and logical screen size [11:28] which again may not be accurate [11:29] I think I may have improved the situation in the multimonitor work actually [11:29] ah no, it was there before [11:29] greyback, still, those values should come from the graphics driver, if they're bad, not much we can do (other than saying: ok, these are dumb, we'll just invent some values that make more sense) [11:30] greyback, can you please reply on the ML? [11:30] sure === alan_g is now known as alan_g|lunch [11:34] * guest42315 EWWWW mailing lists [11:57] oh [11:59] but we dont calculate the physical size through the touchscreen.. === alan_g|lunch is now known as alan_g [12:02] how would you "calculate" that ? [12:03] i believe we get that info from hwc.. [12:03] you dont know how physically big a pixel actually is [12:03] could be 0.01mm or could be 3cm ... [12:06] well as already said hwc provies dpi in both directions .. I thought the above was related to touch screens. [12:07] .. and so far I havent found a single touch screen driver that provides that info.. [12:15] right [12:15] usually you get the resolution boundaries only [12:15] (for touch) [12:15] and if you are lucky an offset === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [13:48] is anyone looking at landing mir 0.16.1 to wily to fix the current build issue? [13:54] uuu mir 0.18 [13:55] seb128: I thought 0.16.1 landed a while ago. What is "the current build issue"? [13:55] alan_g, it landed in vivid-overlay, not wily [13:56] alan_g, and the build issue is basically what is described in the fix, http://bazaar.launchpad.net/~mir-team/mir/0.16/revision/2951 [13:56] Oh, I thought that was duel landed (before FF). [13:56] CI team changed dual landing to go to the ppa for wily rather than the archive [13:57] so maybe that's where it went [13:57] in which case somebody need to copy it over to wily [13:58] I though 0.16.1 was before that, but I expect you're right that it didn't. [14:00] vogons: can anyone clarify^^? [14:02] alan_g: seb128 is this the mesa build fix ? [14:02] kgunn, yes [14:02] that was actually 16.2 i thot [14:02] which didn't quite make it [14:02] i bet [14:02] on the hairy edge [14:02] * alan_g wonders if https://bazaar.launchpad.net/~mir-team/mir/0.17/revision/3005 would be useful too? [14:03] kgunn: we haven't done a 16.2 (yet) [14:03] kgunn, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5473299/+listing-archive-extra [14:03] kgunn, that suggests it's 0.16.1 [14:04] "Copied from ubuntu wily" [14:05] https://launchpad.net/ubuntu/+source/mir [14:14] seb128: so in answer to your original question: no. ;) [14:14] k [14:14] can we get something assigned to sort that out? ;-) [14:15] seb128: do you need it in a rush ? [14:15] kgunn, no, but this week or next I guess [14:15] before wily is out [14:16] eh [14:16] seb128: do you want a fix for lp:1503450 too? [14:16] Or is 16.1 enough? [14:17] alan_g: yeah, wondering, should we just punch mir0.17 in as the final for wily ? [14:18] bug #:1503450 [14:18] kgunn: if someone can get us a FFE [14:18] bug #1503450 [14:18] bug 1503450 in Mir "mesa FTBFS due to missing Requires in mirclient" [High,Fix committed] https://launchpad.net/bugs/1503450 [14:18] I think that would be worth including [14:21] So we either cherry pick -c 3005 to make 16.2 or add wily to the current "duel" release of 0.17 [14:22] dual landing don't land to the distro anymore though [14:22] but you can probably pocket copy over [14:23] seb128: ack. [14:25] yep, doubles testing altho vs risk of mir0.17 hitting some bumps and taking longer [14:33] alf: opinion? ^^ [14:38] kgunn: alan_g: Can we release to wily independently? That is land in overlay (v+w) first, then try for wily, and if we have problem we can think about 0.16.2? [14:40] alf: we should do dual landing regardless...yes, and then try to poke the whole thing into wily with FFE [14:41] alf: so mzanetti currently has his phone in the state where is will not screen blank [14:41] with the ota7 candidate [14:41] is there any debug to be had ? [14:42] basically this bug https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1502145 [14:42] Ubuntu bug 1502145 in unity-system-compositor (Ubuntu) "rc-proposed r140, krillin: screen does not blank after timeout expires" [Undecided,Confirmed] [14:43] kgunn: not really, I guess we could get a backtrace, but previous backtraces in this situation didn't provide any info (everything seemed normal). I need to find a way to reproduce this, so I can run with a special USC build with extra logging to figure out what's going on (e.g. if some other process has asked USC to keep the screen on, or there is some strange bug in USC) [14:45] alf: do you have a special usc available ? since mzanetti is trying to repro he may as well load it [14:45] mzanetti: ^^ Any information about how you got into this state? Any other apps open etc [14:46] kgunn: No, I wanted to build one but was too busy with the release [14:46] alf, no... just doesn't turn off any more ever since I did an OTA last night [14:46] mzanetti: so it doesn't turn off consistently or is this a one-off? [14:46] something like powerd-cli list/stats.. [14:46] and for faenil that seems to be the case too since monday (I didn't do the update earlier because I was travelling) [14:47] alf, consistently, sometimes it even turns itself on and doesn't go off any more [14:47] mzanetti: ok, which device is this? [14:47] mzanetti: I guess pressing the power button turns the screen off, right? [14:48] alf, krillin, yes power button works [14:49] mzanetti: how do I flash OTA7 on the phone? [14:50] mzanetti: I mean to which revision in the stable channel does it correspond? The latest stable? [14:51] alf: latest rc-proposed [14:51] well.... [14:51] landings are open (but damn close) [14:51] mzanetti: kgunn: I wonder if there is a difference in flashing clean vs updating... perhaps there could be an incompatibility in settings when updating [14:52] mzanetti: ah, one thing to try... [14:53] mzanetti: gsettings get com.ubuntu.touch.system activity-timeout [14:53] mzanetti: and gsettings get com.ubuntu.touch.system dim-timeout [14:53] alf, this is the OTA-7 channel ubuntu-touch/rc/bq-aquaris.en [14:53] alf, it will become stable when we finally release it [14:54] mzanetti: ack [14:54] alf, should be *very* similar to rc-proposed atm, but that is opened for new landings again [14:54] so rc-proposed might have additional stuff on top already [14:55] yeah but nothing landing frmo us [15:00] mzanetti: when you get the chance please get the gsettings mentioned above [15:01] mzanetti: I want to check if we are ok on the settings side of things [15:01] oops. missed that... getting it now [15:01] alf, uint32 60 [15:02] and uint32 45 [15:03] mzanetti: ok, these look sensible [15:03] so far can't repro on mako === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === alan_g is now known as alan_g|EOD [18:12] does Mir recognize mouse-wheel scrolling and pass it on to Unity 8? [18:12] I have a bluetooth mouse connected to my N4, and it all works except the scroll wheel === dandrader is now known as dandrader|afk === \b is now known as benonsoftware [19:48] mhall119: it should [19:51] mhall119: https://code.launchpad.net/~lukas-kde/qtmir/wheelEvent/+merge/273150 [19:53] anpok: ok, so it's not landed yet, but the implementation has been done === dandrader|afk is now known as dandrader