[06:55] <Saviq> ok, nobody touch any silos with unity8 or qtmir!
[07:12] <duflu> Saviq: Kay... http://www.lightningrodlabs.com/wp-content/uploads/2010/12/silo9-1024x576.jpg
[07:13] <duflu> Hence we have freezes and things
[07:33] <tsdgeos> mzanetti: Saviq: what about https://code.launchpad.net/~aacid/unity8/use_sdk12/+merge/273182 and https://code.launchpad.net/~aacid/unity8/use_sdk_12_quick_24/+merge/273185 ?
[07:40] <Saviq> tsdgeos, I think we'll go to 1.3 directly after all in the next landing
[07:40] <tsdgeos> Saviq: we can't, it has blocker bugs
[07:41] <Saviq> tsdgeos, got link?
[07:41] <tsdgeos> Saviq: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1495554
[07:41] <Saviq> tsdgeos, anyway, even if fixed, we'll need to coordinate with core apps to land before ota8
[07:41] <ubot5`> Ubuntu bug 1495554 in ubuntu-ui-toolkit (Ubuntu) "AbstractButton 1.3 pressAndHold breaks inside a Loader" [High,In progress]
[07:42] <Saviq> tsdgeos, ok, they'll need to release before us, then
[07:43]  * Saviq asks zsombi what's the plan there
[07:44] <tsdgeos> Saviq: he's on holidays?
[07:44] <Saviq> tsdgeos, right, asked Zoltan instead
[07:45] <Saviq> tsdgeos, any case, now that we know our target for 1.3 is OTA8, it needs to get fixed and we can skip 1.2/2.4 IMO
[07:45] <tsdgeos> ok
[07:46] <tsdgeos> i'll leave the branches just in case
[07:47] <Saviq> tsdgeos, actually that fix is released already
[07:47] <tsdgeos> Saviq: it's not
[07:47] <Mirv> Saviq: tsdgeos: so, right now you still can't use the citrain tool to upgrade to 012, at least until the audio role Unity 8 problem is fixed. just use the QtTesting instructions for time being.
[07:47] <tsdgeos> Saviq: the branch has been merged, true, the bug is not fixed
[07:47] <Saviq> tsdgeos, ok well that might be true
[07:47] <tsdgeos> Saviq: there's a very simple test case you can use if you want to check by yourself
[07:51] <Saviq> tsdgeos, yeah, works for me
[07:51] <Saviq> tsdgeos, see #sdk
[07:52] <Saviq> duflu, don't!
[07:53] <duflu> Saviq: OK... on that note, I noticed my branch is just one of 80-somthing pending so I'm not going to bug you about it now :)
[07:58] <Saviq> duflu, I'm landing it now (i.e. waiting for rebuild, testing etc.)
[07:58] <duflu> Saviq: Thanks. In other good news, I found a way to improve scrolling smoothness further (fix coming in Mir-0.18-ish)
[07:58]  * Saviq likes
[08:03]  * Saviq just realized bugs are not auto-closed because of overlay... let's see how many of them we missed...
[08:05] <Saviq> oh well, not that many, since we were releasing into wily, too
[08:05] <duflu> Saviq: It seems we're using Ubuntu tasks to represent the overlay fixes. But if you look in any actual Ubuntu project distro up to wily then said fixes don't exist. Seems like we're confusing ourselves and Launchpad. We need something new and unique to represent overlay
[08:06] <Saviq> duflu, agreed, the rtm archive was better in that regard, but the overlay approach is slightly nicer in that you don't need to sync things that land in archive all the time
[08:07] <duflu> Saviq: We probably don't need to compromise though. Just invent some nice kind of task for overlay (as opposed to Ubuntu which means wily)
[08:07] <duflu> Somehow
[08:07] <Saviq> duflu, well, those won't get auto-closed unless LP considers PPAs as release archives
[08:08] <Saviq> but yeah, something could be better
[08:08] <Saviq> duflu, but also, we'd need per-release overlay (because today we have overlay for both wily and vivid)
[08:08] <Saviq> and in theory you could release only to vivid overlay, not wily
[08:08] <Saviq> so not trivial
[08:09] <duflu> We probably have already (e.g. Mir 0.16.1 may never hit wily)
[08:09] <Saviq> duflu, it did hit wily overlay (I meant wily overlay)
[08:10] <Saviq> OMG silo 22 is actually building, we might even be able to release it some time
[08:10] <Saviq> 31 MPs total
[08:11] <Saviq> 8 projects
[08:11] <Saviq> only Mirv can top that!
[08:22] <Mirv> :) and I have less MP:s, just manual uploads all over
[09:00] <Saviq> greyback_, top-ack on https://code.launchpad.net/~aacid/qtmir/no_double_search/+merge/272707 ?
[09:00] <Saviq> greyback_, also https://code.launchpad.net/~unity-team/qtmir/surviveEmptyTexture/+merge/274510
[09:00] <Saviq> and https://code.launchpad.net/~nick-dedekind/qtmir/remove-dpkg-CMAK_INSTALL_PREFIX/+merge/274222
[09:01] <Saviq> greyback_, if you could look at https://code.launchpad.net/~lukas-kde/qtmir/wheelEvent/+merge/274313 too, don't wanna wait until Daniel comes online
[09:02] <greyback_> ok
[09:03] <Saviq> greyback_, Daniel gave it a +1 before a rebase https://code.launchpad.net/~lukas-kde/qtmir/wheelEvent/+merge/273150
[09:03] <Saviq> so just a sanity check
[09:04] <Saviq> that would be al
[09:04] <Saviq> l
[09:04] <greyback_> Saviq: it looks good. all approved
[09:04] <Saviq> tx
[09:05]  * Saviq spends the rest of the day testing silo 22...
[10:15] <Mirv> FWIW PPA 012 is again up-to-date regarding landings
[10:15] <Mirv> including the today's released unity8
[11:11] <ltinkl> greyback_, btw those Mir vs. Qt timestamps, worth a fix?
[11:14] <tsdgeos> Mirv: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1474775 is also fixed by 5.5.1
[11:14] <ubot5`> Ubuntu bug 1474775 in qtbase-opensource-src (Ubuntu) "ubuntu-ui-extras fails running a test on Qt 5.5" [Undecided,New]
[11:15] <greyback_> ltinkl: for input events?
[11:15] <ltinkl> greyback_, yes
[11:15] <ltinkl> greyback_, Qt timestamps are in milliseconds (if I'm not mistaken) so they need to be converted to nanoseconds (as expected by Mir)
[11:16] <greyback_> ltinkl: right. dednick had done work on that
[11:16] <ltinkl> greyback_, I fixed the one event in https://code.launchpad.net/~lukas-kde/qtmir/wheelEvent/+merge/274313
[11:16] <greyback_> I thought it landed
[11:16] <tsdgeos> Mirv: 5.5.1 released \o/
[11:16] <ltinkl> basically auto timestamp = std::chrono::duration_cast<std::chrono::nanoseconds>(std::chrono::milliseconds(qtEvent->timestamp()));
[11:18] <greyback_> ltinkl: yeah, that's good
[11:19] <greyback_> it's what we're doing for all mir events currently afaics
[11:19] <ltinkl> greyback_, still have to double-check the Qt timestamps are milliseconds, no docu on that
[11:19] <ltinkl> greyback_, nope, not the case currently
[11:20] <greyback_> ltinkl: what am I missing?
[11:20] <greyback_> yep, qt timestamps in miliseconds, are 32bit ints
[11:20] <greyback_> I believe std::chrono does implicit time conversions
[11:21] <greyback_> as in, the api looks for nanoseconds, but if we pass it miliseconds, it gets converted implicitly
[11:21] <ltinkl> greyback_, ah, there's some new code to compress them
[11:21] <greyback_> ltinkl: yes, that's dednick's work
[11:22] <ltinkl> greyback_, ye but it doesn't get converted back to milliseconds when being passed to Qt functions
[11:22] <ltinkl> greyback_, auto timestamp = qtmir::compressTimestamp<ulong>(std::chrono::nanoseconds(mir_input_event_get_event_time(event)));
[11:22] <ltinkl> greyback_,  qKeyEvent.setTimestamp(timestamp);
[11:22] <dednick> ltinkl: that does the conversion
[11:23]  * greyback_ hands off to the expert ;)
[11:24] <dednick> or it should be doing.
[11:24] <ltinkl> dednick, sorry I fail to see where it converts it to milli
[11:26] <dednick> ltinkl: hm. in fact it may not be doing that
[11:27] <dednick> it's just compressing down to a ulong, but keeping the precision.
[11:31] <ltinkl> dednick, I suggest passing a std::chrono::duration (and removing that template) and just convert the value inside
[11:33] <Mirv> tsdgeos: I noted that on #ubuntu-touch 1h ago, already building :)
[11:34] <Mirv> tsdgeos: I'll keep the 5.5.0 PPA intact and use a temporary PPA so that you or anyone can still use the 5.5.0 while 5.5.1 is being prepared (the internal version checks would otherwise break things)
[11:34] <tsdgeos> ok
[11:34] <tsdgeos> food!
[11:35] <ltinkl> Saviq, can't top-ack https://code.launchpad.net/~saviq/unity-notifications/fix-version/+merge/274513
[11:36] <ltinkl> Saviq, missing membership I guess
[11:36] <Saviq> ltinkl, lemme add you
[11:36] <Saviq> ETOOMANYGROUPS
[11:38] <Saviq> ltinkl, done
[11:39] <ltinkl> Saviq, yup, thx
[11:39] <Saviq> ltinkl, we got a problem though
[11:39] <Saviq> https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d#//screenshot20151015_115211980.png
[11:39] <Saviq> this is how the SIM things look like in silo 22
[11:39] <Saviq> not sure if notifications to blame yet
[11:40] <Saviq> or maybe... background resolver?
[11:40] <ltinkl> Saviq, hmm, dunno how it's supposed to look like
[11:40] <Saviq> ltinkl, it should have the backround behind
[11:41] <ltinkl> Saviq, like a wallpaper, and not the texts?
[11:41] <Saviq> that sounds likely, wdyt greyback_ ↑?
[11:41] <Saviq> ltinkl, yeah, the text behind is another bug, but usually it's covered by the wallpaper, yes
[11:41] <ltinkl> Saviq, the PIN lock screen is not a notification
[11:41] <Saviq> ltinkl, you'd think ;)
[11:41] <greyback_> Saviq: odd. unity8.log printing an error?
[11:41] <ltinkl> Saviq, rather a component in Components
[11:41] <ltinkl> Saviq, it really is? .)
[11:42] <Saviq> ltinkl, it made sense when we made it like that :P
[11:42] <Saviq> but yeah, we need a different plan
[11:42] <dednick> ltinkl, greyback_: are we sure timestamps are in ms? doesn't seem to say anywhere that i can see
[11:42] <ltinkl> dednick, in Qt? I think so
[11:42] <Saviq> greyback_, NotificationMenuItemFactory.qml:152:25: Unable to assign [undefined] to QUrl
[11:43] <Saviq> greyback_, on that note, shouldn't the wallpaper resolver be a singleton?
[11:43] <greyback_> indeed
[11:44] <Saviq> that might not work necessarily, as it takes width as input
[11:44] <Saviq> but I feel like it should always resolve to the same one, so...
[11:45] <ltinkl> dednick, xcb_timestamp_t time;          /* Time, in milliseconds the event took place in */
[11:46] <ltinkl> dednick, and that's what is used in the xcb Qt plugin, directly passed to Qt's functions
[11:46] <ltinkl> dednick, http://xcb.freedesktop.org/tutorial/events/
[11:46] <dednick> ltinkl: yeah, it's part of the stylehints for a theme.
[11:48] <greyback_> ltinkl: /qtbase/src/gui/kernel/qevent.h - ulong  QInputEvent::timestamp() const - Returns the window system's timestamp for this event. It will normally be in milliseconds since some arbitrary point in time, such as the time when the system was started.
[11:48] <ltinkl> so ye, milliseconds
[11:55] <ltinkl> Saviq, what about the wallpaper in the PIN dialog?
[11:56] <Saviq> ltinkl, I'll take care of it
[11:56] <ltinkl> Saviq, looks like your wallpaper in AS is broken
[11:56] <Saviq> ltinkl, nah, Daniel's externalMonitor branch refactored stuff
[11:56] <ltinkl> Saviq, right...
[11:56]  * ltinkl looking at wrong branch
[11:57] <Saviq> ltinkl, https://code.launchpad.net/~unity-team/unity8/externalMonitor/+merge/273829
[11:57] <Saviq> ltinkl, he refactored the wallpaper bits into a separate component
[11:57] <Saviq> but likely forgot to use it in the odd use case of notifications
[11:59] <ltinkl> Saviq, yup, there's no change there
[11:59] <Saviq> ltinkl, so yeah, I'll just fix it in that branch and file a bug about a test for it (and likely refactor into singleton)
[12:23] <mhall119> Saviq: having problems with the latest code:
[12:23] <mhall119> phablet@ubuntu-phablet:~$ unity8-dash
[12:23] <mhall119> Loading module: 'libubuntu_application_api_touch_mirclient.so.3.0.0'
[12:23] <mhall119> UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is
[12:23] <mhall119> running, and the correct socket is being used and is accessible. The shell may have
[12:23] <mhall119> rejected the incoming connection, so check its log file
[12:23] <Saviq> mhall119, can you paste /etc/apt/sources.list.d/extra-ppas.list ?
[12:25] <Saviq> oh dandrader, was just about to fix myself, but you showed up :) https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d#//screenshot20151015_115211980.png
[12:26] <mhall119> Saviq: http://paste.ubuntu.com/12788519/
[12:27] <Saviq> mhall119, replace stable-snapshot with stable-phone-overlay, update, dist-upgrade and you should be good
[12:27] <Saviq> mhall119, you should've noticed some broken dependencies
[12:27] <dandrader> Saviq, so that started happening out of nowhere?
[12:27] <Saviq> dandrader, not out of nowhere http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/qml/Notifications/NotificationMenuItemFactory.qml#L152
[12:27] <Saviq> dandrader, this needs BackgroundResolver, too
[12:27] <Saviq> s/Background/Wallpaper/
[12:28] <Saviq> we could use a test for that, too...
[12:28] <Saviq> dandrader, for later (I'll file a bug), as well as thinking if this shouldn't be a singleton
[12:33] <mhall119> Saviq: sorry, lost power for a second
[12:33] <mhall119> I'm back now
[12:34] <Saviq> mhall119, did you see what I wrote about overlay?
[12:35] <mhall119> no
 mhall119, replace stable-snapshot with stable-phone-overlay, update, dist-upgrade and you should be good
[12:35] <Saviq>  mhall119, you should've noticed some broken dependencies
[12:35] <mhall119> I didn't see anything after I posted my pastebin link
[12:36] <mhall119> hmmm, how did I get on stable-snapshot?
[12:36] <Saviq> mhall119, rc-proposed
[12:36] <Saviq> until ota7 is released
[12:36] <Saviq> sil2100, ↑ see
[12:36] <Saviq> ;)
[12:37] <Saviq> anyone else, but mhall119 keeps tabs on what we're doing, and even he didn't know ;)
[12:37] <mhall119> so wait, does stable-snapshot mean rc-proposed?
[12:37] <Saviq> mhall119, the other way, rc-proposed is on stable-snapshot since we spun the first OTA7 candidate, until OTA7 is released
[12:37] <Saviq> mhall119, it'll go back to overlay after that
[12:38] <mhall119> oh, ok, so I'm getting more stable images that I used to be getting
[12:38] <Saviq> kinda ;)
[12:38] <Saviq> mhall119, stable-snapshot is just a copy of overlay from the time when first OTA7 candidate was spun
[12:38] <Saviq> mhall119, and any fixes that happened for OTA7
[12:39] <sil2100> mhall119, Saviq: there was an announcement about that some time ago ;)
[12:39] <mhall119> ok, but for testing the latest silo stuff I want to be on stable-phone-overlay
[12:39] <Saviq> mhall119, yes
[12:39] <mhall119> sil2100: where?
[12:39] <sil2100> To phablet
[12:39] <Saviq> sil2100, I think it wasn't clear that rc-proposed switches to stable-snapshot is all
[12:40] <Saviq> sil2100, people probably thought since overlay is unblocked, rc-proposed will follow it
[12:40] <mhall119> is there any way we could prevent that switch from happening automatically on devices using citrain tools?
[12:40] <sil2100> Well, yeah, those are technical details, but the fact is that we're using rc-proposed for OTA-7 right now
[12:40] <Saviq> mhall119, we're on topic with robru about that
[12:40] <sil2100> No, I mentioned explicitly that rc-proposed is for OTA-7 and there are no daily builds
[12:41] <sil2100> Will make sure to be triple clear next time
[12:41] <Saviq> sil2100, yeah I remember something like that, just didn't understand probably
[12:41] <mhall119> oh, Mir 0.17 :)
[12:41] <Saviq> indeed ;)
[12:41] <Saviq> sil2100, and that's what you said about "overlay packages not having an image to be in"
[12:41] <Saviq> sil2100, it didn't sink in what it actually means
[12:42] <sil2100> Yeah... I should probably be a bit more clear
[12:42] <sil2100> I actually thought we'd be already enablind daily builds now
[12:42] <Saviq> estimate*3
[12:53] <dandrader> Saviq, how do I get to this screen? (the lockscreen that is shown by the noficitations thingy)
[12:54] <Saviq> dandrader, get a PIN-locked SIM, or there should be an example in unity-notifications
[12:54] <Saviq> checking
[12:54] <Saviq> dandrader, yup, http://bazaar.launchpad.net/~unity-api-team/unity-notifications/trunk/view/head:/examples/sd-example-simunlock.py
[12:55] <Saviq> dandrader, you'll need to install python and python-notify for those to work, though
[13:01] <kgunn> Saviq: do you need any help on silo22 ?
[13:01] <kgunn> unsure how much it changed since all the other testing/landings
[13:01] <Saviq> kgunn, well, Mir 0.17 landed
[13:01] <Saviq> kgunn, so moar multimonitor testing this time
[13:02] <kgunn> ah...right
[13:02] <Saviq> kgunn, so yeah, sure, the more eyes the better
[13:02] <Saviq> kgunn, it's 31 MPs in total across 8 projects
[13:02] <kgunn> ack...and silo 35 landed too, that was the other (unity-api)
[13:02] <Saviq> scopes, yes
[13:03] <Saviq> kgunn, note you'll need to replace stable-snapshot with stable-phone-overlay in /etc/apt/sources.list.d/extra-ppas.list before installing the silo
[13:03] <mhall119> Saviq: dash is much happer now, thanks :)
[13:03] <Saviq> kgunn, after that http://bazaar.launchpad.net/~robru/phablet-tools/make-useful-again/view/head:/citrain
[13:04] <Saviq> kgunn, that upcoming version of citrain tool will be smarter and install new dependencies etc.
[13:05] <kgunn> lol "make useful again"
[13:06] <sil2100> Sorry about that guys, will try to figure out a way next time not to taint rc-proposed during OTA testin
[13:06] <sil2100> But normally it would involve us creating 3 additional channel sets
[13:07] <sil2100> Maybe we should just change the process and copy the candidate images to rc instead
[13:07] <Saviq> sil2100, just wanted to ask what do we use rc for?
[13:07] <sil2100> Saviq: right now it's stupid, as we use it as a channel to share with manufacturers for testing
[13:08] <sil2100> Which is sad, since that's not how it should work
[13:08] <Saviq> sil2100, and would it be possible to build an image to rc with stable-snapshot and to rc-proposed with overlay (or rename that channel to something like "dev" or so)
[13:08] <sil2100> Yes, that's what I propose for the next OTA
[13:09] <sil2100> It involves some manual switching and copying, but it's better than creating 3 additional channels for no reason
[13:10] <Saviq> sil2100, we only build two-three rc images every OTA, right, so not a lot of manual labour there
[13:10] <sil2100> Yeah
[13:11] <sil2100> Well, now at least we know the stable-snapshot usage adds some problems for developers ;)
[13:12] <Saviq> tsdgeos, so vivid is fine here https://code.launchpad.net/~unity-team/unity8/use_sdk_13/+merge/271603/comments/693152
[13:12] <tsdgeos> yeah i just fixed it
[13:12] <Saviq> tsdgeos, fginther is looking into the wily part I believe
[13:17] <Saviq> kgunn, FYI there's an issue I found with the SIM unlock screen dandrader's fixing now, so there will be a unity8 rebuild for sure
[13:20] <kgunn> mk
[13:24] <sil2100> Saviq, kgunn: maybe hm, would it help you guys if we kicked off an overlay-based image to rc-proposed?
[13:24] <sil2100> Saviq, kgunn: I didn't want to do it earlier not to introduce any confusion to QA engineers, also, in case we do a re-spin of OTA-7, things would go backwards in rc-proposed
[13:25] <sil2100> But maybe if we announce it and make sure QA is aware, we could simply kick an image there
[13:26] <Saviq> sil2100, if you think now's a safe time to do it, sure
[13:27] <davmor2> sil2100: why not do it the easy way and just drop a snapshot into RC and then just use RC for testing the image we release? That frees up rc-proposed to keep spinning up images then?
[13:27] <sil2100> Saviq: just in that case you and other rc-proposed users would need to be prepared for ~2 images that will go back in time...
[13:27] <Saviq> sil2100, otherwise as long as citrain tool does whatever it needs to do to make stuff work, I'm fine with that
[13:27] <sil2100> davmor2: that's the proposition for the next cycle
[13:28] <sil2100> Anyway, even if we copy images to rc, we would still need to go backwards in rc-proposed for certain reasons
[13:29] <sil2100> davmor2: is the current candidate image 'green' regarding QA? Besides the newly popped up issue
[13:29] <sil2100> davmor2: if you guys give a +1 then I think I can just copy it there
[13:30] <sil2100> Or wait, hm, maybe it would be best to wait, as we might need to copy the OTA-6+ image there
[13:30] <davmor2> sil2100: no idea I'm in London at the desktop sprint not been paying much attention I think it is good but jibel would be the better person to ask
[13:33] <kgunn> sil2100: all anyone has to do is change to ppa overlay in the apt sources & update right? seems like a small price to pay to avoid image confusion
[13:35] <sil2100> kgunn: yeah, but still, I don't want devs and landers suffer too much
[13:37] <Saviq> sil2100, let's just make citrain tool useful again, that's really all we need
[13:37] <Saviq> sil2100, looks like there's just two small things (adb_onlock and adding overlay) still to be done there
[13:37] <Saviq> and we can then rely on citrain doing the right thing every time
[13:42] <Saviq> dandrader, sorry, should've mentioned that I resubmitted your branches this morning
[13:44] <dandrader> Saviq, is mir 0.17 released already?
[13:44] <Saviq> dandrader, yes, it's in the overlay
[13:45] <Saviq> for both wily and vivid
[13:56] <dandrader> Saviq, would it be easy for you to test the notification background fix?
[13:57] <Saviq> dandrader, sure
[13:58] <Saviq> dandrader, best gimme the diff I could apply on device
[13:59] <dandrader> Saviq, http://pastebin.ubuntu.com/12789218/
[14:01] <dandrader> Saviq, mir 0.17 is nowhere to be seem. neither in wily nor in vivid+overlay
[14:01] <Saviq> dandrader, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=mir&field.status_filter=published&field.series_filter=
[14:02] <Saviq> dandrader, note rc-proposed images have stable-snapshot, not stable-phone-overlay until OTA7 passes testing
[14:03] <Saviq> so you need to tweak /etc/apt/sources.list.d/extra-ppas.list for now (citrain tool update to do that is in the works)
[14:03] <dandrader> Saviq, how long should that take? if it's just a day or so I would rather wait
[14:07] <Saviq> dandrader, next week earliest
[14:07] <dandrader> Saviq, still it doesn't explain why I don't see it in wily
[14:07] <Saviq> dandrader, that's true
[14:07] <Saviq> I'm having trouble, too actually
[14:11] <dandrader> Saviq, and why is silo 22 wired to depend on mir 0.17?
[14:11] <Saviq> dandrader, because mir 0.17 is in overlay, that's where we release to
[14:12] <Saviq> dandrader, and mir 0.17 *is* in wily *overlay*
[14:12] <Saviq> if you want to build it locally, you need to add ppa:ci-train-ppa-service/stable-phone-overlay
[14:12] <dandrader> Saviq, should I use the overlay ppa on wily as well?
[14:12] <Saviq> dandrader, yes, if you want to build on your machine directly
[14:13] <dandrader> oh, so there's no escape from that ppa anymore :(
[14:15] <Saviq> dandrader, when w+1 opens, it's not gonna be needed there
[14:15] <Saviq> it's only temporary for wily, while it's frozen before release
[14:16] <ltinkl> Saviq, I'm not getting that Mir update on krillin either :/
[14:17] <ltinkl> Saviq, I have tweaked /etc/apt/sources.list.d/extra-ppas.list to include the overlay
[14:17] <Saviq> ltinkl, also tweak or drop /etc/apt/preferences.d/extra-ppas.pref
[14:18] <Saviq> @unity: rc-proposed is stuck on a different PPA than overlay (stable-snapshot) until OTA7 is released, that means you need to tweak /etc/apt/*/extra-ppas.* to use stable-phone-overlay
[14:19] <Saviq> @unity: also, if your desktop's on wily and you want to build qtmir, unity8 locally, you need the overlay as well (ppa:ci-train-ppa-service/stable-phone-overlay) since a week or two, because wily is frozen
[14:20] <mterry> ah, thanks for that
[14:21] <kgunn> Saviq: @wily you need overlay,  do you mean b/c of mir
[14:21] <kgunn> we asked for that to get punched through to wily archive
[14:21] <kgunn> seb128: sil2100 ^ that happened right ?
[14:21] <seb128> kgunn, yes
[14:21] <Saviq> kgunn, today b/c of mir, soon because of unity-api, UITK, there's no escape
[14:21] <kgunn> ah
[14:22] <mterry> Saviq, you make it sound so dire  :)
[14:22] <kgunn> Saviq: @adding overlay just don't tell ogra ;)
[14:22] <kgunn> mterry: i know lol...i thot the same
[14:22] <kgunn> "there's no escape"
[14:22] <mterry> libmircookie1!  I get free cookies with Mir now
[14:23] <Saviq> mterry, been fighting with ~that since this morning, so yeah not a happy camper with all this right now
[14:23] <mterry> Saviq, fair enough
[14:23] <Saviq> mterry, you missed "rc-proposed is stuck on a different PPA than overlay (stable-snapshot) until OTA7 is released, that means you need to tweak /etc/apt/*/extra-ppas.* to use stable-phone-overlay"
[14:24] <Saviq> which basically means we've no image built from overlay for over a week now
[14:24] <mterry> yeah  :-/
[14:25] <kgunn> but at least there's a way
[14:25] <kgunn> better than being completely froze
[14:26] <ltinkl> Saviq, dropped /etc/apt/preferences.d/extra-ppas.pref, still Mir &co. being "kept back"
[14:26] <ltinkl> 0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
[14:26] <Saviq> ltinkl, try -f
[14:26] <Saviq> ltinkl, needed that here for whatever reason
[14:27] <greyback_> I just added the ppa to my wily machine, is upgrading ok
[14:27] <Saviq> yeah, that's fine
[14:27] <ltinkl> Saviq, even -f doesn't help
[14:27] <Saviq> phones are a bit weird that way
[14:27] <ltinkl> refuses to upgrade them
[14:27] <Saviq> ltinkl, can you at least see the new mir? apt-cache policy libmirclient9?
[14:28] <ltinkl> libmirclient9:
[14:28] <ltinkl>   Installed: 0.16.1+15.04.20150930.1-0ubuntu1
[14:28] <ltinkl>   Candidate: 0.17.0+15.04.20151008.2-0ubuntu1
[14:28] <Saviq> ok so it's there
[14:28] <Saviq> ltinkl, might wanna try just passing the 8 non-upgraded packages with the right versions to apt-get install
[14:29] <Saviq> ltinkl, not sure what's going on yet
[14:29] <ltinkl> Saviq, ok, that works...
[14:31] <Saviq> dandrader, that wallpaper fix works
[14:33] <dandrader> Saviq, ok, will push. thanks
[14:58] <kgunn> Saviq: do you have any success with hdmi and silo 22 ?
[14:58]  * kgunn rechecks his packages
[14:58] <ltinkl> kgunn, gonna test that now (/me heads to the living room)
[14:59] <Saviq> kgunn, it's very likely your package set is screwed, there's something totally weird going on, I didn't try yet
[15:00] <kgunn> i'm just rebooting on hdmi connect
[15:00] <Saviq> that sounds like pre-multimonitor (i.e. you don't have new qtmir/unity8)
[15:01] <kgunn> dang it....now my adb is hosed
[15:04] <kgunn> toggling dev-mode in uss seemed to correct...weird
[15:08] <ltinkl> sidenote, having WiDi working instead of those messy cables, connectors and reductions would be a real kill pocket desktop feature
[15:09] <ltinkl> killer feature *
[15:10] <kgunn> no doubt
[15:11] <Saviq> ltinkl, airtame ftw, we only need a virtual Mir screen and feed that through the GPU hw encoder
[15:12] <Saviq> kgunn, so, I got output, but it's bad, half-way offscreen
[15:15] <Saviq> kgunn, dandrader, greyback_, https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d#//DSC09544.JPG
[15:15] <kgunn> Saviq: i'm pretty sure all my packages are correct...i get nothing, the billboard comes up but then it just reboot
[15:15]  * greyback_ shakes fist at USC
[15:16] <greyback_> it's USC's job to position surfaces, I think it has got it wrong
[15:17] <dandrader> maybe it's got to do with the mir upgrade (0.17). Don't think I've tested with that
[15:17] <ltinkl> Saviq, what is airtame?
[15:17] <Saviq> ltinkl, kickstarted HDMI dongle http://airtame.com/
[15:18] <Saviq> ltinkl, it's basically a RasPi in a ~HDMI plug
[15:18] <Saviq> with dual-band wifi
[15:18] <Saviq> and some smarts for sharing your screen over it
[15:20] <ltinkl> Saviq, yup, that would be a nice complement to the whole story
[15:22] <dandrader> Saviq, do we need that fixed before landing?
[15:23] <Saviq> dandrader, well, it was working before...
[15:23] <greyback_> Saviq: is this a 1 off, or always happens?
[15:23] <Saviq> greyback_, always
[15:23] <greyback_> bah
[15:23] <Saviq> dandrader, if it doesn't, we might as well pull it out from the silo
[15:24] <Saviq> greyback_, 2 screens, mako@wily, updating flo@vivid to see
[15:37] <greyback_> Saviq: could you edit /usr/share/ubuntu-touch-session/usc-wrapper to add "--display-config=sidebyside" to usc's flags?
[15:39] <Saviq> greyback_, trying
[15:39] <Saviq> greyback_, although not sure whatever the default config is then ;P
[15:39] <greyback_> Saviq: surfaces on top of eachother
[15:40] <greyback_> which I think is happening here
[15:40] <Saviq> sounds about wrong indeed
[15:41] <greyback_> mir just has 1 big virtual display
[15:41] <Saviq> flo just got blank when connected
[15:42] <Saviq> greyback_, hmm that's even weirder on flo (with sidebyside)
[15:44] <Saviq> greyback_, worked on mako after a reboot, though
[15:44] <greyback_> that doesn't sound right to me at all
[15:44] <Saviq> greyback_, so yeah, sidebyside helped mako
[15:44] <greyback_> am flashing, will be ~ hour to catch up
[15:45] <Saviq> greyback_, ok and helped flo, too, not sure what happened before
[15:45] <Saviq> greyback_, ok so that change looks like it will make things much better, can you MP?
[15:45] <greyback_> ok
[15:45]  * Saviq connects input
[15:46] <greyback_> Saviq: with sidebyside, was the visual change from the spinner to unity8 at startup ok?
[15:47] <Saviq> greyback_, seemed ok, stuff is really fragile still (crashes, reboots)
[15:48] <Saviq> kgunn, so yeah, I can get it to reboot, too
[15:48] <greyback_> ouch
[15:48] <Saviq> and I lost wifi on flo again, no idea what's going on there
[15:48] <greyback_> I get that occasionally too
[15:48] <Saviq> oh yeah, and no bluetooth on flo/wily, but that I think is not fixeded yet
[15:50] <Saviq> gah, no bluetooth on mako either, wth
[15:50] <Saviq> ah mako is wily, flo is vivid
[15:50] <Saviq> grr
[15:53] <dandrader> Saviq, at this point the sanest way to test is with a laptop. connecting it to an external monitor. Laptop setup seemed pretty stable
[15:54] <greyback_> Saviq: https://code.launchpad.net/~unity-team/ubuntu-touch-session/usc-sidebyside/+merge/274589
[16:05] <greyback_> Nexus4, vivid, first connection, everything was perfect. Disconnect & reconnect, now unity8 on external display wrongly placed (without sidebyside)
[16:05] <greyback_> and boom
[16:06] <greyback_> USC dead, unity8 spinning
[16:26] <greyback_> gone through several plug/unplug cycles on mako, only got 1 fail so far.
[16:27] <greyback_> maybe I'm being too kid-gloves
[16:29] <greyback_> trying with flo in a while
[16:39]  * Saviq off, got slightly too annoyed at all this today, tomorrow's another day
[16:47] <kgunn> fwiw, i only tried on flo....will try on n4 in a sec
[16:54] <kgunn> AlbertA: kdub ^ note, flo and mako may yield different experience in terms of reboot and ability to connect
[17:07] <Saviq> greyback_, I got it skewed with sidebystage, too, so doesn't really seem like it changes much
[17:25] <AlbertA> kgunn: greyback_: in flo, it seems unity8 just keeps restarting
[17:25] <AlbertA> with silo 22
[17:25] <AlbertA> when I connect the external display
[17:26] <AlbertA> USC does not crash and duplicates the spinner on both monitors.
[17:30] <AlbertA> http://pastebin.ubuntu.com/12792337/
[17:30] <AlbertA> greyback_: seen this before ? what():  Nested Mir Display Error: Failed to update EGL surface: EGL_BAD_ACCESS (0x3002)
[17:32] <AlbertA> kgunn: ^ I guess that's where you were getting too?
[17:33] <Saviq> AlbertA, you sure you got all of silo 22 and overlay? rc-proposed doesn't have overlay enabled these days
[17:34] <Saviq> waiting for OTA7 to release
[17:34] <AlbertA> Saviq: let me check...
[17:35] <kgunn> let me check, got distracted with snappy stuff for a bit
[17:36] <AlbertA> Savig: huh... for some reason qtmir was not upgraded...unity8 was though...
[17:37] <AlbertA> oh it depends on mir 0.17...
[17:42] <Saviq> AlbertA, yes, you need to drop /etc/apt/preferences.d/extra-ppas.pref
[17:43] <kgunn> AlbertA: so i was just double checking my pkgs, curious... why is libmirprotobuf0 installed ?
[17:43] <kgunn> alongside libmirprotobuf2
[17:43] <Saviq> AlbertA, and make sure /etc/apt/sources.list.d/extra-ppas.pref actually has stable-phone-overlay
[17:43] <Saviq> because on rc-proposed today it has stable-snapshot instead
[17:43] <kgunn> exuse me... 0 & 3
[17:45] <AlbertA> Saviq: ah ok, missed dropping the preferences.d/extra-ppas.pref
[17:46] <Saviq> kgunn, something's still pulling in libmirclient8
[17:47] <kgunn> ok, didn't realize protobuf0 went with mirclient8
[17:47] <Saviq> gtk3 still?
[17:48] <Saviq> ltinkl, we need some mergin'
[17:48] <ltinkl> Saviq, yea
[17:48] <Saviq> ltinkl, ~unity-team/unity8/mousePointer → ~lukas-kde/unity8/liveCaption → ~unity-team/unity8/externalMonitor → ~unity-team/unity8/externalMonitor
[17:49] <ltinkl> Saviq, the last 2 are the same?
[17:49]  * ltinkl is getting lost in that silo :)
[17:49] <Saviq> ltinkl, should be rotation
[17:50] <Saviq> ltinkl, please just merge mousePointer into liveCaption and I'l do the rest
[17:50] <ltinkl> Saviq, unity8, qtmir (and/or both?)
[17:51] <Saviq> ltinkl, just unity8
[17:51] <ltinkl> ok
[17:51] <ltinkl> Saviq, on it
[17:53] <kgunn> after every reboot, i have to toggle developer-mode in uss to get adb back
[17:53] <ltinkl> Saviq, ok pushed, want a new MP?
[17:53] <kgunn> on flo
[17:53] <kgunn> with silo22
[17:53] <ltinkl> Saviq, ah not needed, had been there before
[17:54] <ltinkl> Saviq, https://code.launchpad.net/~lukas-kde/unity8/liveCaption/+merge/273792 should be fine
[17:54] <Saviq> ltinkl, oh ok
[17:58] <Saviq> ltinkl, ah I can't merge rotateScreenshots, you own it
[17:58] <Saviq> ltinkl, there's a small conflict, please merge externalMonitor into it
[18:01] <ltinkl> Saviq, ~unity-team/unity8/externalMonitor -> rotate?
[18:01] <Saviq> ltinkl, yup
[18:01] <Saviq> ltinkl, basically, trying to merge anything else than the prerequisite has little chances of success
[18:02] <ltinkl> Saviq, https://code.launchpad.net/~lukas-kde/unity8/rotateScreenshots/+merge/274235 should be still good, too
[18:03] <ltinkl> Saviq, had the prereq before
[18:03] <Saviq> ltinkl, but there's new code in the prereq
[18:03] <Saviq> ltinkl, and that's conflicting
[18:03] <ltinkl> Saviq, yeah I merged it already, just sayin the MP's fine
[18:03] <Saviq> ah ok
[18:04]  * ltinkl EOD for now
[18:04] <ltinkl> bbl if anything needed, laterz
[18:04] <Saviq> o/
[18:07] <kgunn> AlbertA: greyback_ here's my unity8 log for multimon connect (i started fresh, and just connected 1 time, leading to a reboot)
[18:07] <kgunn> https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFRDV5M3NrTWd6bWs/view?usp=sharing
[18:08] <kgunn> kdub: ^
[18:10] <kdub> anything interesting in /proc/last_kmsg?
[18:10] <kgunn> and see some exception around line 363
[18:11] <kdub> the exception looks like its from a WM policy
[18:11]  * kgunn figures out the adb is locked out by the lockscreen
[18:13] <kgunn> kdub: if it rebooted will it have overwritten that proc/last_kmsg ?
[18:13] <kgunn> or does it simple append
[18:14] <kdub> iirc, it should be the kernel messages from the previous session
[18:16] <AlbertA> greyback_: damn it... I just saw an instance of this bug: https://bugs.launchpad.net/mir/+bug/1496069
[18:16] <ubot5`> Ubuntu bug 1496069 in mir (Ubuntu) "[usc] Mir gives up and shuts down due to input with multimonitor qtmir (std::exception::what: Failure sending input event)" [Undecided,Triaged]
[18:17] <AlbertA> kgunn: greyback_: Saviq: so the first time I plug in external monitor, everything goes fine in flo, second time, the surface in the external display is cropped...
[18:18] <kgunn> hmm, AlbertA you're luckier than me
[18:20] <kgunn> kdub: AlbertA if interested...last_kmsg
[18:20] <kgunn> https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFUXpkbXRkU1V6ZDA/view?usp=sharing
[18:21] <AlbertA> kgunn: what resolution is your monitor?
[18:21] <kgunn> hdmi
[18:21] <AlbertA> I'm connecting a 1080p display here
[18:23] <kgunn> 1920 x 1080
[18:24] <kgunn> specifically https://www.asus.com/us/Monitors/VE247H/
[18:24]  * greyback_ back
[18:25] <kgunn> ok i gotta go to a funeral :( back after a while
[18:26] <Saviq> AlbertA, so yeah, you're as lucky as me and greyback_, usc's --display-config= doesn't seem to help, at least not reliably
[18:26] <greyback_> right
[18:26] <greyback_> and yeah, I get occasional crash still
[18:27] <AlbertA> Saviq: yeah there's something funky in the coordinates of the second display I guess....
[18:28] <AlbertA> camako: did you find out what the issue was with the nested server where surface replicate on the other side of the screen. I'm wondering if it's related to ^
[19:20] <greyback_> ok, flo I think has combination of the USC surface positioning bug, plus the rotated shell is causing confusion
[19:21] <dandrader> greyback_, rotated shell?
[19:21] <camako> AlbertA, I got sidetracked with gtk-mir
[19:22] <greyback_> dandrader: you know how on flo, the shell is rotated 90 degrees to be landscape
[19:22] <greyback_> it rotates itself
[19:22] <dandrader> greyback_, but not when you connect it to an external display
[19:22] <dandrader> greyback_, and USC is oblivious to this rotation
[19:22] <dandrader> greyback_, when OrientedShell is moved to the external display, it's not longer rotated
[19:23] <greyback_> dandrader: what I'm seeing is the a portrait shell on my landscape display. I.e. it is not filling my display width-wise
[19:23] <greyback_> and is too tall
[19:23] <dandrader> greyback_, interesting... photo?
[19:24] <dandrader> greyback_, so it's different from Saviq's photo from earlier today
[19:24] <greyback_> dandrader: that was on mako
[19:24] <greyback_> similar. The surface positioning is still incorrect sometimes
[19:33] <greyback_> dandrader: https://chinstrap.canonical.com/~gerboland/mm.jpg
[19:34] <dandrader> greyback_, did you start unity8 with the external monitor already connected?
[19:35] <greyback_> dandrader: that time, yes. But the other time, no
[19:35] <dandrader> greyback_, I've seem that qt has trouble properly resizing the qml scene in this situation
[19:36] <greyback_> I added quick prints to Shell.qml, it is printing portrait width/heights which at least matches what we see
[19:36] <dandrader> greyback_, so QQuickWindow does get the new size (from built-in display to external monitor) but the qml items in it (notably Shell) does not resize
[19:37] <greyback_> that would mean resizing any qml window would be buggy
[19:37] <greyback_> which is not the case usually
[19:37] <dandrader> greyback_, it happens only if unity8 is started with the external monitor already connected
[19:38] <dandrader> greyback_, can reproduce it on a laptop
[19:38] <greyback_> dandrader: not true, I have reproed it here without connection at startup
[19:38] <dandrader> greyback_, well, that was my experience with my laptop at least
[19:40] <greyback_> dandrader: are we using Screen.orientation to decide the orientation when external display connected?
[19:43] <dandrader> greyback_, no
[19:44] <dandrader> greyback_, applicationArguments.deviceName
[19:44] <dandrader> greyback_, external monitor is "desktop"
[19:46] <greyback_> dandrader: ok, then shell in portrait when I connect a mouse (no external monitor connected)
[19:47] <greyback_> hmm, not not that time
[19:48] <dandrader> greyback_, when OrientedShell is in the built-in screen applicationArguments.deviceName gonna be "flo"
[19:48] <greyback_> dandrader: have you manage to reproduce this yourself?
[19:49] <greyback_> am finding flo a bit more crashy than mako
[19:50] <dandrader> greyback_, haven't tried yet
[19:52] <greyback_> dandrader: please try, else we'll never get this landed
[20:46] <dandrader> greyback_, ok, got the shifted desktop on the second connect monitor/disconnect monitor  cycle
[20:52] <greyback_> dandrader: ok. I guess it's your eod, but I'll be looking into it tomorrow morning
[20:52] <dandrader> greyback_, still one hour to go
[20:58] <dandrader> greyback_, it looks like shell, when it's shifted, is at (0,0) instead of at (1200,0)
[20:59] <dandrader> and since the external monitor is at (1200,0), you see only ~ right half of Shell on it
[20:59] <dandrader> greyback_, at least the amount of Shell displayed there matches with the theory (~ 37%)
[21:05] <kgunn> dandrader: so you don't reboot at all ?
[21:06] <dandrader> kgunn, no
[21:06] <dandrader> kgunn, that's on flo
[21:06] <kgunn> huh
[21:06] <kgunn> man i am consistent no that
[21:06] <kgunn> wonder if it's specific to my monitor somehow
[21:06] <kgunn> s/no/on
[21:07] <dandrader> kgunn, it shouldn't matter but I'm not using silo 22, I've built qtmir/multimonitorNext and untiy8/externalMonitor myself
[21:07] <dandrader> kgunn, on top of stable-phone-overlay
[21:09]  * kgunn is gonna try his tv
[21:09] <kgunn> dandrader: curious, are you "already in windowed mode" when you plug in to the monitor ?
[21:10] <dandrader> kgunn, no
[21:10] <kgunn> ok, i just did it, and it didn't crash...but got nothing on monitor
[21:10] <kgunn> going for tv now
[21:12] <greyback_> dandrader|afk: note,  I believe USC is not placing the surface for the external monitor correctly
[21:13] <greyback_> hence the shifting
[21:13] <kgunn> ok, my tv is actually almost perfect
[21:14] <kgunn> no weird offset
[21:15] <kgunn> only the top few pixels consumed
[21:19] <kgunn> https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFYVRxdlVSQ21yWjAtSzhuWmxnZlBWd1dFRTU4/view?usp=sharing
[21:48] <greyback_> kgunn: can you check if your tv has an overscan setting and turn it off. Some have a "monitor" mode which does that
[21:49] <greyback_> would explain the lost pixels at top/bottom
[21:49] <kgunn> will investigate
[21:52] <greyback_> but it's good to see it work *sometimes* - just need to figure out the errors
[22:00] <kgunn> played around with settings, nothing called overscan...but maybe it's doing on it's own
[22:01] <Saviq> kgunn, yeah that's almost certainly overscan, look for something like 1:1 in the aspect ratio selection
[22:02] <Saviq> not all tvs allow disabling it, though
[22:03] <Saviq> anyhoo... o/
[22:22] <greyback_> kgunn: http://www.manualslib.com/manual/405738/Asus-Ve278h.html?page=18 <- how about "Aspect control"
[22:23] <kgunn> :)
[22:24] <kgunn> greyback_: shouldn't you be thinking about winding down for the evening :-P
[22:25] <greyback_> kgunn: I'm doing positively non-work related stuff right now
[22:26] <kgunn> ok, that was weird...reboot, while connect, now i get something on the screen
[22:26] <kgunn> u-s-c was full screen
[22:26] <kgunn> u8 greeter reshapes to the fill the left 1/2 of screen
[22:26] <kgunn> (btw, overscan issue was thot to be with the sony tv, but will now tinker with asus monitor)
[22:27] <kgunn> huh asus overscan was already off
[22:28] <greyback_> u8 greeter in phone mode (i.e. no username/password thingy) ?
[22:30] <kgunn> uh, well it's flow, and looks like it's in portrait but username/password thingy just left of infographic (like tablet)
[22:32] <greyback_> my theory is that u8 got confused and is drawing in portrait mode there. So there's stuff on top/bottom chopped off
[22:32] <kgunn> https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFVkVLcy1ldFBua25FREgtamVSQjA1UVRDdHZB/view?usp=sharing
[22:37] <greyback_> yep, matches my theory
[22:39] <ltinkl> evening :)
[22:40] <ltinkl> greyback_, you know what I noticed while fixing the rotated screenshots bug? (qml) Screen.orientation didn't change that way I'd expected
[22:41] <greyback_> ltinkl: yeah?
[22:41] <greyback_> suspect related?
[22:41] <ltinkl> maybe
[22:41] <ltinkl> greyback_, is it getting it thru qtmir?
[22:42] <greyback_> ltinkl: yep
[22:43] <greyback_> there has always been something about how we deal with {primary,native,}orientation in QML that I've been suspicious of
[22:43] <greyback_> I'd love to hear your thoughts
[22:45] <ltinkl> greyback_, well the weird thing is actually Screen.orientationUpdateMask, you have to set it to non 0 to get updates
[22:45] <ltinkl> greyback_, my quick grep over unity8 sources shows 0 hits
[22:46] <ltinkl> greyback_, aaah!
[22:47] <ltinkl> greyback_, QPlatformScreen::setOrientationUpdateMask(Qt::ScreenOrientations mask);
[22:47] <ltinkl> greyback_, we never set it/override it
[22:48] <ltinkl> greyback_, http://code.woboq.org/qt5/qtwayland/src/client/qwaylandscreen.cpp.html#_ZN15QtWaylandClient14QWaylandScreen24setOrientationUpdateMaskE6QFlagsIN2Qt17ScreenOrientationEE
[22:48] <ltinkl> greyback_, the default impl does nothing
[22:49] <greyback_> ltinkl: which I thought meant every orientation event was passed through
[22:49] <greyback_> worth checking
[22:49] <ltinkl> greyback_, Screen.orientationUpdateMask : Qt::ScreenOrientations
[22:49] <ltinkl> greyback_, This contains the update mask for the orientation. Screen::orientation only emits changes for the screen orientations matching this mask.
[22:50] <greyback_> but shell is rotating. So is it we're (mis)using primaryOrientation?
[22:54] <ltinkl> greyback_, looking at the code
[22:57] <ltinkl> greyback_, we seem to solely rely on DeviceConfiguration
[22:57] <ltinkl> greyback_, where only flo has a primaryOrientation
[22:59] <ltinkl> greyback_, and then we track this: property int physicalOrientation: Screen.orientation
[23:01] <greyback_> ltinkl: Screen.orientation is coming straight from QPlatformScreen
[23:02] <ltinkl> greyback_, from qtmir, Screen::orientation()
[23:02] <ltinkl> Qt::ScreenOrientation orientation() const override { return m_currentOrientation; }
[23:02] <ltinkl> aha
[23:02] <ltinkl> / If it's a landscape device (i.e. some tablets), start in landscape, otherwise portrait
[23:02] <ltinkl>     m_currentOrientation = (m_nativeOrientation == Qt::LandscapeOrientation)
[23:02] <ltinkl>             ? Qt::LandscapeOrientation : Qt::PortraitOrientation;
[23:03] <greyback_> whiskey time!
[23:03] <ltinkl> greyback_, send me some
[23:03] <greyback_> actually went for some Zubrowka
[23:04] <greyback_> out of the cheap whiskey
[23:05] <ltinkl> greyback_, in Screen::readMirDisplayConfiguration(), we seem to ignore the mir orientation, being passed in mir::graphics::DisplayConfigurationOutput
[23:06] <greyback_> ltinkl: right, that's deliberate for now
[23:06] <greyback_> instead we just listen for the orientation sensor
[23:06] <ltinkl> greyback_, so we set the orientation based on width/height
[23:08] <greyback_> ltinkl: well that's a guess at the device "native orientation" - i.e. the orientation of the logo on hte back of the device. Or you looking at other code
[23:08] <ltinkl> greyback_, nope, that's the one
[23:08] <greyback_> on the Flo, that's incorrect, as Flo has a hardware portrait screen
[23:09] <greyback_> so we use the DeviceConfiguration thingy to force shell to rotate itself to landscape
[23:12] <ltinkl> greyback_, ye exactly, so you connect your portrait oriented device (phone) to a screen (whose native orientation is landscape) and then try to match the HW sensor with the external screen orientation?
[23:12] <ltinkl> greyback_, this is a bit puzzling
[23:13] <ltinkl> greyback_, I tried it a bit with an Android phone, it never rotates the content on the external screen
[23:14] <greyback_> ltinkl: ah, once we plug in extetnal screen, it should stop listening to the orientation sensor.
[23:14] <ltinkl> greyback_, if you have your phone in portrait (inverted or not), it will show a portrait picture on the external screen
[23:14] <greyback_> dandrader has it so that applicationArguments.something is set to "desktop" when external monitor plugged in
[23:14] <ltinkl> greyback_, if your phone is in landscape (inverted or not), it will show a fullscreen landscape picture on the TV/monitor
[23:15] <ltinkl> greyback_, but it shouldn't stop listening to the sensor, no
[23:15] <ltinkl> greyback_, so that you can still rotate your phone's screen
[23:16] <greyback_> ltinkl: if you've plugged in your phone to an external monitor, you want the picture on the external monitor to always be landscape
[23:16] <ltinkl> greyback_, really?
[23:16] <greyback_> and currently, we make the phone screen useless
[23:16] <greyback_> why would you want portrait desktop on a landscape monitor?
[23:16] <ltinkl> greyback_, ye I know, as I said, this is my experience with an Android
[23:16] <greyback_> well we can what we like :)
[23:16] <ltinkl> sure
[23:17] <greyback_> in qml, it's just a window per screen
[23:17] <ltinkl> greyback_, heh and we didn't even start thinking about external monitors that can rotate themselves ;)
[23:17] <ltinkl> I used to have one like that
[23:18] <ltinkl> greyback_, then your phone sensor is really useless
[23:18] <greyback_> hah, let's leave that for 2.0 release ;)
[23:18] <ltinkl> greyback_, because it's the monitor's orientation that matters
[23:19] <greyback_> yep, for now.
[23:24] <ltinkl> greyback_, so my thoughts are, we don't set the nativeOrientation correctly in OrientedShell.qml when going into an external screen
[23:24] <ltinkl> greyback_, as in, we don't read the data from qtmir::Screen
[23:25] <greyback_> I share a similar theory yes
[23:25] <ltinkl> greyback_, because we set that property when the shell starts, so the initial value matches the phone
[23:25] <greyback_> or something isn't being updated on monitor plugin, causing a wrong state
[23:25] <ltinkl> greyback_, btu when we change, we don't reset it
[23:26] <ltinkl> greyback_, we only get changes from the sensor
[23:26] <greyback_> fair point
[23:26] <ltinkl> greyback_, which is fine for the phone, we rotate the shell on the phone according to the sensor changes and relative to the phone's nativeOrientation
[23:27] <ltinkl> greyback_, but when going external, it's not the HW orientation that matters, it's the native (monitor) orientation that changes and we don't notice
[23:28] <ltinkl> greyback_, the info is there in Screen::nativeOrientation() in qtmir
[23:28] <ltinkl> / NB: native and primary orientations here don't map exactly to their QScreen counterparts
[23:28] <ltinkl>     readonly property int nativeOrientation: width > height ? Qt.LandscapeOrientation : Qt.PortraitOrientation
[23:28] <ltinkl> but in QML, we don't read it
[23:29] <greyback_> I'm told the param that actually changes on monitor plug in is "applicationArguments.deviceName" - it it set to "desktop"
[23:29] <greyback_> which supposedly overrides any orientation sensor reading, and forces landscape
[23:30] <greyback_> you'll see it in OrientatedShell, being passed into DeviceConfiguration
[23:32] <ltinkl> greyback_, ye that changes the primary orientation
[23:32] <ltinkl> greyback_, not the native
[23:33] <ltinkl> greyback_, so flo is broken right?
[23:33] <greyback_> ltinkl: sometimes :)
[23:33] <greyback_> sometimes it's good, other times not
[23:33] <ltinkl> greyback_, and I see why
[23:34] <ltinkl> greyback_, only flo has a primaryOrientation set
[23:34] <ltinkl> greyback_, and then readonly property int primaryOrientation:
[23:34] <ltinkl>             deviceConfiguration.primaryOrientation == deviceConfiguration.useNativeOrientation
[23:34] <ltinkl>                    ? nativeOrientation : deviceConfiguration.primaryOrientation
[23:35] <greyback_> it's the only one needing to override the default
[23:35] <ltinkl> greyback_, which is fine for its own screen but not for an external one
[23:35] <ltinkl> greyback_, so flo, from the code ^^, falls back to its deviceConfiguration.primaryOrientation
[23:36] <greyback_> ltinkl: have you the equipment to try it out?
[23:36] <ltinkl> greyback_, which is primaryOrientation: Qt.InvertedLandscapeOrientation
[23:36] <ltinkl> greyback_, nope :/
[23:36] <greyback_> Saviq: ^ why not?
[23:37] <greyback_> ltinkl: well we've got somewhere to start in the morning :)
[23:37] <greyback_> ltinkl: dude, go to bed!
[23:37] <ltinkl> greyback_, ok :)
[23:37] <greyback_> I thought I was bad
[23:37] <greyback_> :D
[23:39] <ltinkl> ok, cya :)