[06:40] <duflu> RAOF: Just installed a new vivid touch image and there's a little bit on 0.9 with the new 0.10
[06:40] <duflu> Looks like another dependencies fix?
[06:41] <duflu> little bit *of* 0.9
[09:27] <Saviq> duflu, FYI, I bumped changelog in the 0.8 backport, too (to be able to depend on it)
[09:27] <duflu> Saviq: Thanks. I think there are one or two other fixes in 0.8.1, did you notice?
[09:27] <Saviq> duflu, did not
[09:28] <duflu> Saviq: Yeah one landed already and others we should consider: https://launchpad.net/mir/+milestone/0.8.1
[09:29] <Saviq> duflu, that might be a problem for the rtm release, we only want very targeted fixes in there (unless all of those are supposed to go into rtm?)
[09:29] <duflu> Saviq: Yeah, ask the higher powers that be
[09:30] <duflu> They look important
[09:30] <Saviq> duflu, they should have a https://launchpad.net/canonical-devices-system-image/ then
[09:30] <Saviq> task
[09:31] <duflu> Saviq: Sure, but camako/kgunn would prefer to be the deciders
[09:32] <duflu> So long as someone tells them... or else they're likely to not notice the other bugs
[09:34] <Saviq> yeah, ok, I'll continue as if the one bug landed and the new one are accepted, will talk to them when their timezone gets up
[09:35] <alan_g> alf_: happy & healthy new year
[10:20] <alf_> alan_g: thanks, you too!
[10:31] <mlankhorst> do we have the es2 manual somewhere?
[12:12] <alf_> mlankhorst: (In case you haven't found it yet) https://www.khronos.org/registry/gles/
[12:15] <mlankhorst> yeah i think i found something like that, and found what i was looking for, thanks ;)
[12:16] <mlankhorst> was curious why glamor with the ES2 backend was disabling GL_ALPHA for alpha pictures. I re-enabled it again and things now owrk..
[12:18] <mlankhorst> oh
[12:18] <mlankhorst>     Disable A8 texture format for GLES2.
[12:18] <mlankhorst>     
[12:18] <mlankhorst>     As PVR's GLES2 implementation doesn't support A8 texture as
[12:18] <mlankhorst>     rendering target, we disable it for now.
[12:18] <mlankhorst> figures
[12:42] <Saviq> folks, we're getting a build failure of the prompt session backports, any idea what's wrong http://paste.ubuntu.com/9718106/ ?
[12:42] <Saviq> the silo is http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-018
[12:45] <alan_g> Saviq: looks like a Mir API update to PromptSessionListener needs corresponding changes to PromptSessionListener
[12:45] <alan_g> in qtmir I presume
[12:46] <Saviq> alan_g, well, yeah, that's what https://code.launchpad.net/~mir-team/qtmir/rtm-14.09-staging/+merge/244580 does - and that's what fails the build...
[12:46] <Saviq> ah hmm
[12:47] <Saviq> alan_g, I see now
[12:47] <Saviq> alan_g, the relevant changes were split between two MPs on our side, sorry for the noise
[12:47] <alan_g> np
[14:38] <alan_g> I know it illustrates we're not where we want to be but does anyone have a reason why landing this first and then improving the API would be a bad idea? https://code.launchpad.net/~mir-team/mir/improved-tiling-window-mamagement/+merge/245994
[15:59] <kdub> alf_, anpok  welcome back!
[15:59] <kdub> alf_, in mgm::Display we register_fd_handler(), but I don't see the unregistration... is that something to be added?
[16:00]  * kdub is trying to figure out if android is okay not to unregister the display change handler as well
[16:06] <alf_> kdub: Hi! Yes, we could/should add this. It's not there because it was not needed under normal usage (both display and ML are torn down).
[16:09] <kgunn> alf \o/ welcome back!
[16:09] <kgunn> anpok:  \o/ welcome back!
[16:12] <alf_> kgunn: \o Hi!
[16:12] <alf_> kgunn: HNY + 12!
[16:13] <kgunn> ;)
[17:17] <racarr_> Good morning
[17:18] <alan_g> Good evening
[17:33] <kdub> can we just rm proving_server?
[17:35] <racarr_> :) I still support that....
[17:36] <racarr_> I kind of want to guess the outcome of the MP
[17:36] <racarr_> and put it in a sealed envelope
[17:36] <racarr_> :p
[17:37] <racarr_> kdub: I think there is a pretty strong argument that its a negtive because it pulls on the interfaces but not realistically
[17:37] <racarr_> but then we have to take on the burden of not breaking it
[17:37] <racarr_> updating it
[17:37] <racarr_> reviewing changes to it
[17:37] <racarr_> manually testing it
[17:38] <kdub> right, exactly... maybe in a bit
[17:38] <racarr_> yeah its easier once example-window-management is a little more complete I guess
[19:08] <kgunn> camako: is citrain device-upgrade still busted? (packaging)
[19:09] <kgunn> just checkin' before i try...(flashing atm)
[20:20] <camako> kgunn, I haven't tried but it probably is
[20:21] <camako> kgunn, dist-upgrade works
[20:21] <kgunn> camako: i didn't bother...just dist-upgraded
[20:21] <camako> kgunn, RAOF didn't agree with Robru's analysis
[20:21] <camako> that anything is broken
[20:21] <camako> on mir side
[20:21] <camako> kgunn, let's talk about it tonight
[20:21] <camako> with the aussies
[20:21] <kgunn> ack
[20:22] <kgunn> camako: would you be utterly disappointed if i missed tonight?
[20:23] <camako> kgunn, I'd be devastated
[20:23] <camako> :-)
[20:37] <mhall119> I've found that after a day of heavy use, especially loading a lot of images in my app (uReadIt) that screen movement gets choppy, predominately in the lower half of the screen
[20:37] <mhall119> is there a known bug for graphical glitches/tearing on the Nexus 4?
[20:37] <mhall119> kgunn: ^^
[20:37] <kgunn> kdub: you ever see this? ^
[20:37] <mhall119> I haven't tried screen-recording it yet, since it may not show up in a recording if it's a driver issue
[20:38] <kgunn> mhall119: actually just recording with another camera might give clues...
[20:38] <kdub> kgunn, I haven't seen that issue
[20:38] <kgunn> mhall119: some people say "tearing" which may or may not fit a typical graphics dude's definition
[20:39] <mhall119> ok, I just rebooted (new revision!) so I'll have to wait until it starts acting up again, usually does it at least once a day
[20:39] <kgunn> mhall119: do you ever see it with anything else ? i mean if it tears via the app....if you switch to another app
[20:39] <kgunn> does the tearing continue ?
[20:39] <greyback_> there was a report of such visual glitching during the sprint in Washington
[20:39] <mhall119> kgunn: yeah, I don't know the proper terms, it looks like random rectangles of screen are being re-painted a fraction of a second behind others
[20:40] <greyback_> yep, exactly that. I've seen that
[20:40] <mhall119> kgunn: once it starts it does it on everything, apps, shell, etc
[20:40] <mhall119> I can't recall if it does it on the lock/welcome screen
[20:40] <mhall119> lock screen doesn't really move enough to notice if it did
[20:40] <greyback_> https://bugs.launchpad.net/mir/+bug/1383745 <- this bug was reported
[20:41] <greyback_> Andrew (community guy who reported it) showed it to me on his N4.
[20:41] <greyback_> I've never noticed it with my N4 however
[20:41] <kgunn> mhall119: does that uReadIt seem to help make it happen ?
[20:41] <mhall119> greyback_: that's exactly it!
[20:41] <mhall119> kgunn: I don't know, but it's one of my most heavily used apps
[20:42] <mhall119> it's also loading/unloading/moving a lot of images, which is part of the reason I suspect it triggersis
[20:42] <mhall119> triggers it
[20:43] <kgunn> mhall119: does anything make it "recover" ? or once it starts tearing continues thru reboot ?
[20:43] <kgunn> or rather reboot i assume fixes it, but it will continue until you reboot ?
[20:44] <kgunn> ..geeze my grammar is awful
[20:44] <greyback_> I recall the Mir team suspecting it was a GPU driver bug, or Mir not using fences quite correctly. You see the tiles that the GPU memory is broken up into
[20:44] <greyback_> as if buffer swap is only half done
[20:44] <kgunn> right...i do recall the fellow showing us
[20:44] <mhall119> kgunn: only a reboot seems to help
[20:44] <kgunn> of course kdub was on baby-watch 2014 :)
[20:44] <mhall119> kgunn: I've tried closing all apps, locking, unlocking, etc, nothing helps
[20:45] <kdub> restarting lightdm?
[20:45] <mhall119> haven't tried that yet, just sudo restart lightdm?
[20:45] <kdub> should work
[20:46] <kgunn> kdub: but won't that reset the gl context anyway ?
[20:46] <kgunn> or what would lightdm restart tell you? or separate out ?
[20:46] <kdub> sure, but if its a kernel driver leak, then it'll come back
[20:47] <kgunn> ah
[20:47] <kdub> if its a userspace driver leak or a mir leak, it won't have glitches on restart
[20:47] <kdub> sounds like a resource problem at the moment
[20:47] <kgunn> userspace== all the proprietary gpu mapping stuff...
[20:47] <kgunn> yeah
[20:49] <mhall119> kdub: I'll try that if it happens again
[20:58] <ahayzen> mhall119, i used to have that screen tearing alot around the DC sprint...but i haven't seen it recently on my device, it was usually triggered/noticed when i entered the spread for me
[20:58] <ahayzen> mhall119, but i could just be restarting my device too often to see it
[20:59] <mhall119> ahayzen: what channel do you use?
[20:59] <ahayzen> mhall119, rtm proposed
[20:59] <ahayzen> mhall119, so i'm a bit infront of you