=== xiinotulp is now known as plutoniix === tizbac_ is now known as tizbac === Cimi_ is now known as cimi === _fortis_ is now known as _fortis === timchen1` is now known as timchen119 [03:54] like to try out the newer version of mir [03:54] can I just installed related debs? [03:55] such as https://launchpad.net/~mir-team/+archive/ubuntu/staging/+build/7842048 [04:27] QOpenGLShader::link: "--From Vertex Shader: Error: Symbol textured defined with different precision in vertex and fragment shaders. [04:27] any idea what could cause this in unity log? [04:27] icons not showing in dash and app scope [04:41] Hawk_: That's a GL error; specifically, it seems that QOpenGLShader is constructing a with mismatching precision on one of its shaders. [04:42] Since it seems you've got this problem after a driver update, it might be that the driver is now being more picky, or that QOpenGLShader isn't specifying the precisions and the driver has changed defaults. [04:47] i am try a port on xperia L [04:48] its not an update issue [04:48] can a particular fussy app cause this? [04:50] Hawk_: It's not an app being fussy; it's your graphics drivers. [05:25] http://linux.softpedia.com/blog/libreoffice-viewer-for-ubuntu-touch-making-great-progress-491039.shtml === chihchun_afk is now known as chihchun [05:47] RAOF, i see. guess it out of my league === chihchun is now known as chihchun_afk === kissiel-afk is now known as kissiel [06:58] good day everyone [06:58] I want to find out if anyone here tried ubuntu touch on the Huawei ascend p1? [07:04] mj-meo-dmt: you mean this one? https://wiki.ubuntu.com/Touch/Devices/u9200 [07:04] mj-meo-dmt: last edit 2013, I'm not sure if anything new, but the current page look not so good [07:15] good morning [07:18] Hi Stanley00 sorry was afk, ahh okay i see uhhmm missed that page.. Damn thats pretty sad because im pretty fed up with this 4.0.3 now... === slangase` is now known as slangasek [07:21] yeah that sure doesnt look good. [07:22] mj-meo-dmt: well, you can try contact the maintainer, I see that he have some recent update on his launchpad account, there may have many good update there [07:24] Sure thing thanks ill try to get hold of him, Thanks === davmor2_HOLS is now known as davmor2 [08:28] Good morning all; happy Monday, and happy Buy a Book Day! 😃 [08:54] Did we recently release changes to touch/gesture logic? [08:54] Or is just my mako broken? === danilos` is now known as danilos [08:57] greyback, Saviq: Did we just change anything to do with gesture recognition? My mako is suddenly quite erratic. Can't notice edge swipes properly even [08:58] duflu, did not, but there's a bug about mako, its input area manages to grow outside of the phone somehow [08:58] bug #1408263 [08:58] bug 1408263 in android (Ubuntu) "Edge gestures still get lost (mako)" [High,Confirmed] https://launchpad.net/bugs/1408263 [08:58] any chance that's that? [08:59] Saviq: A bit different. I need to rule out pure Mir first... [09:00] duflu, you guys working on wily, right? [09:00] Saviq: yes [09:00] there's likely not enough attention being paid to wily [09:00] vivid+overlay is still our main target [09:02] Saviq: Nevermind. My touchscreen is screwed. Even with pure Mir demos. [09:02] kk [09:02] It works slightly and intermittently [09:02] Saviq: while testing silo-014 I experienced some odd stuff in camera [09:02] -app. [09:02] anpok_, oh? [09:03] photos looked fine, but video at first did not take up the whole screen [09:04] it first seemed like it would leave an area untouched for the small preferences tool bar.. [09:04] Why must there still be so many variables? [09:04] but it also made a low resolution video.. [09:04] So many different bugs need fixing simultaneously [09:04] after a restart of camera-app it worked normally.. [09:05] anpok_, doesn't seem like anything we (mir or unity8) have control over [09:05] other than that mako / silo-014 on image 232 worked fine [09:06] anpok_, I just tried on mako/wily and indeed the video played back had maybe some 2-3% blank edge [09:06] more on the longer edges than the short edge [09:06] it seems to depend on the system rotation during start.. [09:06] oh, that might be indeed [09:07] * Saviq tries [09:07] but i cannot reproduce the issue anymore.. the space just seemed to match the difference height/width between === diplo_ is now known as diplo [09:11] anpok_, everything seems fine here, too, I can only notice some margins in the camera app, video is HD [09:12] Goodbye mako. [09:12] anpok_, maybe you somehow got into a lower res recording mdoe [09:12] duflu, that bad? [09:12] Saviq: It's low level, maybe kernel or hardware. I need to try reflashing [09:13] Touches go missing a lot (visible in fingerpaint and target too) [09:13] The same device has been fine for quite a while. I only updated over the air today === chriadam is now known as chriadam|away [09:14] anpok_, I can easily get the camera app confused by changing video resolution and toggling between front/back camera, there's a lot of stretched images and such [09:15] but it's all the app doing that === ndec_ is now known as ndec [09:38] greyback, Saviq: I've noticed (especially on wily) that the welcome wizard is exhibiting Apple/Lollipop level scrolling smoothness (when selecting language). What's so different about the wizard that makes it fantastically smooth? [09:39] duflu: it runs as part of the shell [09:39] greyback: Ah, yes. [09:40] duflu: am looking forward to your qtmir smoothness patch! :) [09:40] me2 [09:40] greyback: Annoyingly I'm losing count of the number of fixes that have to all work together [09:40] But we're getting there [09:41] duflu: is there an obvious way we can measure the improvement, aside from fps? [09:41] greyback: Try flashing a device with wily. The welcome wizard's responsiveness really is far ahead of everything else [09:41] buffer acquire/release times [09:42] greyback: The Mir client perf report also mentions number of unique buffers (and the queue cycle latency) [09:43] greyback: Also, just landed: Mir's latency acceptance test now works and gives proper latency numbers [09:43] (coming in 0.16) [09:43] duflu: ok. I would like to aim towards gathering numbers on these things, with the goal to ensure we don't regress [09:44] greyback: It's actually enforced in CI now. Latency must be in a strict range or failure [09:44] That's not really new, but the test now works as of today [09:45] duflu: in mir's perhaps :) I wants me the same in qtmir! [09:46] greyback: You know what I was working on in QtMir was actually just smoothness. If it goes well, that will allow Mir's latency improvements but I fear we're also waiting on some GL optimizations (like making the dash consistently quicker to render) [09:56] greyback: When do you use wakelocks, btw? Do you have any numbers on their benefit? [09:57] duflu: wavelock only grabbed when app running and in foreground [09:58] greyback: For the duration of the app? [09:59] I thought wakelocks automatically expire so have to be acquired for only short, or regular periods. But could be wrong [09:59] duflu: no, they're acquired and released by qtmir. they don't time out [10:00] greyback: In that case they're either ineffectual or we're holding them wrong... https://bugs.launchpad.net/qtmir/+bug/1488386 [10:00] Ubuntu bug 1488386 in qtmir (Ubuntu) "[performance] Double buffering is only smooth while you're touching it" [Undecided,New] [10:01] duflu: then it's not related to wakelocks. Wakelock is held while app running and in the foreground. [10:02] use "power-cli list" to check [10:02] powerd-cli [10:02] greyback: Right, we may well be using them correctly, but they're still not helping us [10:03] duflu: they do prevent cpu dropping to low power mode, keeping system a bit more responsive [10:05] greyback: Hmm, OK, I guess it could always be worse. My observations are that the scaling and frequency governors are not affected by them then... [10:05] At least not sufficiently. Not as much as just touching the screen [10:05] must be something else at work so === alan_g is now known as alan_g|lunch [12:07] hello everyone! I'm still loving my Ubuntu phone [12:07] :) [12:10] :) [12:10] zzarr: \o/ === MacSlow is now known as MacSlow|lunch [12:18] :) [12:28] I did it. I ordered an Ubuntu phone. [12:28] :) [12:28] Was too pissed about Google in general and especially about my Android phone. [12:29] BTW: Does sshunnel run on Ubuntu touch? [12:32] gratz undertasker, I think you should be able to run an ssh tunnel [12:33] ssh server and client are preinstalled (server is disabled by default and only allows login via key auth once you enabled it) [12:34] Is it so that backgrounded apps will loose network access? [12:35] I tested quicly and as soon as I change app, ssh connection dies. [12:35] backgrounded apps recieve a SIGSTOP signal [12:35] and once they go back into foreground a SIGCONT [12:35] so it depends how the timeout of the server is set ... [12:36] (for keepalive) [12:36] also if the terminal gets locked, unlocking wipes existing session. [12:37] sounds like a terminal bug to me [12:40] Can I run services? [12:41] without making the system writable you can only run session services for the user (by storing upstart jobs in ~/.init/) === alan_g|lunch is now known as alan_g === MacSlow|lunch is now known as MacSlow [14:04] greyback_: yo. you mentioned last week that silo0 was all janky and was being moved away from, is there now some way to install latest unity/mir and it be usable? [14:05] popey: by "usable" you're asking specifically about multimonitor/docking phone to monitor? [14:05] ya [14:06] popey: we've still work to do before silo0 can go away entirely unfortunately. [14:06] greyback_: okay, but silo0 was broken in such a way that it doesn't work / isn't installable right now? [14:06] silo0 just kept for demos really - it is installable on top of the stable image [14:06] ok [14:06] i misunderstood [14:08] popey: there are instructions at the end of https://docs.google.com/document/d/1EtDf3MXVrTaW3xfPNUALYmKTNmTHxBAAtTmgnpRX-E4/edit# if you'd like to give it a whirl [14:08] ta [14:08] works best on N7 [14:08] greyback_: magic, thanks. [14:08] np [14:27] Are SD storages a bottleneck compared to traditional HD's? Let's say I create a new partition on a Windows laptop with Ubu desktop installation for dual boot. Or my Android device has little native disk space so I add more storage and put part of Ubuntu Touch there. Or whatever. Is this going to severely affect performance? [14:29] Thaurwylth: I used to do this with my old Nexus One. It was slower, and was at the borderline of annoyance. [14:35] jdstrand: hi! When you have some time: https://code.launchpad.net/~mardy/click-reviewers-tools/new-account-hook/+merge/268445 [14:36] interesting glitch on arale and RC proposed [14:36] if you have the screen always on [14:36] and it dims [14:37] the music stutters right after it dims [14:37] :D [14:37] Augh, OK. So you'd say it was a serious bottleneck? [14:37] Mcphail [14:38] Thaurwylth: it was noticeable on that device [14:38] OK, I'll take your word for it. Are there in general benchmarks for SD speed somewhere? I guess traditional HDD speeds are pretty well behaved. [14:40] Thaurwylth: no idea, I'm afraid [15:06] dhbiker, can you file that? [15:07] i would but i don't know where yet :D [15:07] still fairly new ~3 weeks with the device [15:18] Still getting frequent lags on current OTA, with "top" showing dbus-daemon consuming up to 99% of CPU. dbus-monitor has lots of entries with "INTERFACE=org.freedesktop.NetworkManager/AccessPoint/variousnumbers". Most lags happen at work, and may be related to poor 3G signal, I suppose. Any way I can debug this further without access to a decent computer with adb etc? [15:18] are there lots of networks near you? [15:18] popey: half a dozen [15:18] are there a small number of network SSIDs with lots of access points? [15:19] popey: I suspect that would be right. I work in a biggish building [15:19] known bug [15:20] aah. Workaround? [15:21] bug 1480877 [15:21] bug 1480877 in Canonical System Image "Access points' "PropertiesChanged" dbus signals freeze UI on mobile devices" [High,Confirmed] https://launchpad.net/bugs/1480877 [15:21] * popey pokes john-mcaleely ^ [15:21] We all saw this in the Canonical office a couple of weeks ago [15:22] Looks like Tony is on it [15:22] popey: that looks like the culprit. Cheers. Has been driving me mental [15:22] ditto === alan_g is now known as alan_g|EOD [19:01] Hi. I asked myself why there is (to my knowledge) no application on mako that uses the compass. Looking at /sys, I can't find the magnetometer, which is, according to the Nexus 4 spec, an AK8964, nor the gyroscope/accelerometer, which is a MPU-6050. Looking at the code source of vivid-mako, I see that it contains a code for the magnetometer for AK8975, and not AK8963. Why ? And why the compass seems not to be accessible for applica [19:01] tions ? Any idea ? [19:03] jgdx, where do i report that ? [19:04] dhbiker, it sounds like pulse, but I'm not 100% sure. Maybe file it against canonical-system-image? https://bugs.launchpad.net/canonical-devices-system-image/+filebug [19:12] coin: does the sensor status app not have a compass entry? [19:15] Question on app review: How long show I expect to wait for a manual review of an app that failed the automated review? [19:17] ty jgdx [19:18] rschroll: let me take a look. [19:18] popey, yes, that is the point: It says that no datas are available for gyroscope and compass (and all others, except GPS and accelerometer). [19:18] But the nexus 4 seems to have a gyroscope and an accelerometer. [19:18] popey: click app #3405, if you want to see why I'm asking. [19:18] rschroll: ah, one for jdstrand who is on vacation today I suspect. [19:18] it has according to the harware specs [19:19] hardware [19:19] coin: ah sorry, I don't know why, maybe we don't expose that some how, I would file a bug at the link jgdx provided though [19:19] * popey checks on his bq e4.5 [19:21] popey: Should I try him tomorrow? [19:21] rschroll: I would. [19:21] Will do. Thanks! [19:21] coin: yeah, no data on e4.5 [19:21] np rschroll [19:26] popey, thanks ! Hope that all the sensors will be exposed ! [19:28] coin: that's because there is no QCompass backend in the ubuntu QtSensors plugin [19:28] me too! [19:29] https://bugs.launchpad.net/qtubuntu-sensors/+bug/1398809 [19:29] Ubuntu bug 1398809 in qtubuntu-sensors "Compass isn't supported" [Undecided,New] [19:31] lpotter, thanks ! That explains why there is no Qt application using some sensors. But they should be exposed on /sys, at least. [19:31] yes. but apparmour will not grant access, I believe [19:32] I could be wrong though [19:34] Ah, yes, you must be right. That's another pb. [19:37] So I understand that the policy is to expose only the strict necessary (for lib and priviledged procs) on /sys ? [19:42] * coin thinks that he should be able to write a priviledged app using the compass [19:48] well, lpotter popey thanks [19:49] * coin has to leave === kissiel is now known as kissiel-zZz === JanC_ is now known as JanC