[00:06] <racarr> ricmm: Got screen blanking working, an early version (needs some cleanup before proposable) is at lp:~robertcarr/mir/test-android-screen-blanking
[00:06] <racarr> you can see how it works in examples/demo-shell/window_manager.cpp
[00:06] <racarr> can test (hasnt been tested on gnex) by running mir demo server shell and using any hardware button
[00:06] <racarr> which will turn the display on and off
[00:14] <RAOF> racarr: Hey, is there a way to get libmirclient to dump a bunch of debug info via an environment variable?
[00:31] <racarr> RAOF: I think there is MIR_CLIENT_RPC_REPORT=log
[00:36] <RAOF> racarr: Ta.
[00:37] <RAOF> That might have less of a timing impact than gdb breakpoints, which is what I'm currently using.
[00:55] <ricmm> racarr: nice, any chance it can be proposed today?
[00:59] <tvoss> RAOF, http://unity.ubuntu.com/mir/component_reports.html
[01:01] <RAOF> tvoss: Ah, thanks.
[01:26] <rsalveti> kdub: that's fine, mind just opening a bug against libhybris?
[01:26] <rsalveti> will take care of it tomorrow morning
[01:30] <duflu> RAOF: Do you have sufficient hardware to prove bug 1216472 is indeed intel-specific?
[01:32] <RAOF> duflu: I think I have a counterexample in my radeon system, to which I've managed to attach my partially broken second LCD.
[01:32] <duflu> RAOF: "Counter" as in radeon with two outputs works fine?
[01:33] <RAOF> No, as in radeon with two outputs suffers a similar problem.
[01:33] <duflu> Ugh
[01:33] <duflu> RAOF: I've been trying to avoid a simple and ugly workaround (if damage for any output is empty give it one pixel's worth)
[01:33] <RAOF> Although that's somewhat masked by what appears to be “mir with fails to send buffers to radeon with two monitors”
[01:36] <RAOF> A bug which is apparently timing related, as when I dump logs and attach gdb it no longer appears.
[01:38] <duflu> RAOF: Without bypass? :)
[01:38] <RAOF> duflu: Works, but exhibits the frame ordering issue.
[01:39] <duflu> RAOF: Is it possible the breaking-up of the root window is similarly incompatible with multiple DDXen?
[01:40] <RAOF> Possibly?
[01:43] <RAOF> Hm.
[01:43] <RAOF> Not a huge fan of the bug where closing a window will sometimes kill X.
[01:50] <duflu> Doesn't Unity8 solve that? (no way to close apps) ;)
[01:55] <RAOF> Bah. Stupid lttng.
[01:55]  * RAOF lunches
[03:34] <jrr> yay heisenbug
[04:50] <alf|xmir-devel> RAOF: duflu: Could some of our problems be caused by xmir creating a mir surface for each output, which for "clone" mode end up at the same area in our virtual space (e.g. both have top-left at 0,0)?
[04:50] <RAOF> alf|xmir-devel: That's possible (and I'm pretty sure there's at least one damage-tracking bug in there), but this occurs with non-overlapping outputs, too.
[05:03] <alf|xmir-devel> RAOF: btw, thanks to Marteen's investigation, we believe that the egl image problems for nested mir are caused by having different dri2 screens for egl and gbm. At least for the nested mir case (i.e. optionally), we need to pass the used gbm_device to platform mir and initialize the egl dri2 using the gbm dri2 setup (liked platform_drm does). Do you see any possible blockers with this approach?
[05:33] <RAOF> robert_ancell: DEB_BUILD_OPTIONS="notest" bzr bd -- -us -uc
[05:33] <RAOF> robert_ancell: DEB_BUILD_OPTIONS="notest parallel=9 nostrip noopt" bzr bd -- -us -uc
[05:39] <duflu> alf|xmir-devel: I can't yet imagine how it would cause functional problems, but sounds like bug 1216748
[05:57] <RAOF> alf|xmir-devel: You mean that the nested server's EGL needs to use the same drm fd as the nested server's mir platorm?
[06:27] <alf|xmir-devel> RAOF: no, it must use the same dri2 screen/implementation as the gbm_device the nested server is using, so that it can share resources proprely (e.g. like the bo image).
[06:29] <RAOF> alf|xmir-devel: Can we do that?
[06:33] <alf|xmir-devel> RAOF: platform_drm seems to be doing exactly that, so it seems possible... although we won't know for sure until we try.
[06:50] <duflu> RAOF: This looks related to out of order frames... The DDX is accessing the MirBufferPackage after free(); bug 1224296
[06:50] <RAOF> Thanks for the pointer.
[06:50] <RAOF> (Bam, ching!)
[06:53] <duflu> RAOF: Does X build with symbols by default? I did not expect "??"
[06:53] <RAOF> You'd need to install xserver-xorg-core-dbg
[06:53] <RAOF> And the corresponding intel -dbg, too.
[07:09] <hikiko> duflu, are you still getting the crash with the drm permission message? in a fresh installation I got it once and then I upgraded and since then I've restarted lightdm more than 20 times and I dont get it
[07:09] <duflu> hikiko: Yeah occasionally. As many people do. Seems to be the most popular Mir bug :(
[07:11] <hikiko> ouf :/ what might happened and I cant reproduce it anymore :S unity compositor + mir are running for sure and I was getting it until 1 hr ago when I upgraded :S :S
[07:12] <duflu> RAOF: OK, got full debug symbols. Now doesn't look related to frame order... bug 1224296
[07:12] <duflu> Also bug 1221616
[07:14] <RAOF> duflu: Aha. Thanks.
[07:29] <duflu> As it happens, both bugs now look like things ickle was very vaguely referring to a while ago, but failed to explain or pinpoint
[07:39]  * RAOF fixes it, and goes to see if it magically fixes everything
[07:46] <RAOF> Oh, right.
[07:46] <duflu> RAOF: I expect it will *only* make mode setting more stable... ?
[07:46] <RAOF> Yes, that's a bit silly
[07:47] <mlankhorst> or is it?
[08:14] <RAOF> mlankhorst: Me DestroyPixmap()ing a Pixmap that I didn't allocate *is* a bit silly, yes :)
[08:16] <mlankhorst> depends, were you allowed to do so?
[08:19] <RAOF> ...maybe.
[09:19] <robert_ancell> bye all, see you in Boston
[09:24] <alan_g> alf|xmir-devel: Update pushed to https://code.launchpad.net/~alan-griffiths/mir/combine-nested-gbm-and-android/+merge/185054
[09:26] <alf|xmir-devel> alan_g: thanks, I will check in a bit, my experiments have broken XMir currently :)
[09:27] <alan_g> alf|xmir-devel: I expect you to learn from your experiments. ;)
[09:43] <mpt> Is it possible to open a surface without specifying what size it is? (If not, there's no point remembering the size of a surface to restore it next time, like we would for position.)
[09:43] <smspillaz> mpt: you need to specify the size
[09:43] <mpt> ta
[09:44] <smspillaz> mpt: also nonzero positions aren't supported (yet) iirc
[09:44] <mpt> smspillaz, okay, so Mir has complete control of (absolute) position, while the app has complete control of size.
[09:45] <mpt> (Unless it requests a size larger than any display, I guess.)
[09:46] <smspillaz> mpt: it technically has complete control of both
[09:46] <smspillaz> (mir)
[09:46] <mpt> yeah, hence the brackets :-)
[09:46] <smspillaz> part of the reason for using server side buffer allocation was so that we could limit the memory usage of applications
[09:47] <smspillaz> so its theoretically possible that you could be denied certain sizes
[09:47] <smspillaz> however, I don't know any good reasons other than memory pressure as to why that would be done in practise
[09:48] <duflu> smspillaz: I'm /told/ much because that's the way Android does it ... (?)
[09:49] <duflu> mpt: Clients (apps) have no control over position. Although there is a hint for what monitor to appear on (used by XMir)
[09:50]  * duflu migrates to the laptop
[09:50] <mpt> smspillaz, if you close a document that was open on a Cinema Display, then reopen it when the only display is a tiny ThinkPad, Mir shouldn't let it open at its previous size.
[09:52] <smspillaz> mpt: it doesn't matter, the application makes the request for the buffer size
[09:53] <smspillaz> the point I was trying to make is that you may (as an application) request a size of M x N
[09:53] <smspillaz> but if you're under memory pressure then you might get something smaller
[09:53] <smspillaz> I wouldn't imagine there'd be any policy implemented on the display server side to prevent applications from creating big windows otherwise
[09:54] <smspillaz> generally as a display server you should probably just respect what the client wants unless it creates a security or performance problem
[09:54] <mpt> smspillaz, I'm writing up the policy right now ... I guess it's window manager level rather than display server level, though.
[09:55] <smspillaz> *shrug* I'm not involved with mir's development so I don't care that much
[09:55] <mpt> Thanks for the answers. :-)
[09:55] <smspillaz> though I will say that trying to have the window manager control application sizes is a bad idea for multiple reasons
[09:56] <smspillaz> mostly because the edge cases end up in the window manager and not the individual applications
[09:57] <mpt> smspillaz, what I have currently is that the only case, where the window manager will force a smaller size, is where there is no display available large enough to show it at the requested size
[09:58] <smspillaz> makes sense
[09:58] <smspillaz> mpt: it might be worth discussing that with the developers directly though :)
[09:59] <mpt> For sure, I only asked the channel in general because tvoss wasn't here. :-)
[10:01] <alan_g> mpt: The general answer is that the Mir library provides hooks for the shell to intercept and tailor the requests. And it is the shell that sets the strategy.
[10:06] <mpt> ta
[10:20] <mpt> tvoss_, have you given any thought to how toolkits will place tooltips close to the screen edge, when they don't know how close the window is to the screen edge?
[10:20] <mpt> how close the parent surface is, I mean
[10:21] <tvoss_> mpt, not yet, but the idea I have in mind is like: apps provide an anchor point in surface relative coordinates, and unity decides where to put the surface depending on closeness to the edge
[10:23] <mpt> tvoss_, makes sense.
[10:24] <tvoss_> mpt, cool
[14:27] <hikiko> question: in /etc/init.d/ there's a lightdm script that should print some messages, where are these messages printed? I cant see them at syslog + I inserted some echo "foo" >> /tmp/foo but there's no /tmp/foo when I restart lightdm... I didnt find any relevant info in the upstart documentation so far any idea?
[14:29] <alf|xmir-devel> hikiko: /var/log/lightdm/*
[14:30] <hikiko> no alf|xmir-devel
[14:30] <hikiko> I dont want to get the lightdm log
[14:30] <hikiko> I want to get the output of the script that starts the lightdm
[14:30] <hikiko> in /etc/init.d
[14:30] <hikiko> to see if a signal is send twice
[15:40] <kgunn> kdub: ping
[15:40] <kdub> kgunn, pong
[15:40] <kgunn> kdub: hey...gotta request...can you flash the pending image http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/
[15:40] <kgunn> this contains mir, but not on by default
[15:41] <kdub> okay, will try
[15:41] <kgunn> to turn on....just modify the /etc/environment file...for QT_QPA_PLATFORM=ubuntumirclient
[15:41] <kgunn> then, rename/delete SF
[15:41] <kgunn> on nexus4
[15:41] <kgunn> and see what you see :)
[15:42] <kgunn> team in lexington is claiming its flickering very very bad...but want to know what you see
[15:42] <kgunn> kdub: greyback says he does not see this flicker on galaxynexus
[15:42] <kgunn> kdub: guys in lexington said they saw it on nexus4
[15:43] <kgunn> racarr: ^ ...in case you're awake & on :)
[15:44] <kgunn> kdub: racarr ... i am trying here....but fear messing something up...(first time i did this...it was stuck at google splash)
[15:47] <kgunn> on my second attempt
[15:48] <greyback> kgunn: I'm having same problem actually. It's like upstart isn't starting hte user session any more. Did mterry's stuff change that?
[16:03] <kgunn> greyback: hmm...so i'm using pending, adb pull etc/environment, modify to QT_QPA_PLATFORM=ubuntumirclient, then adb push, then adb remount, rm /etc/bin/surfaceflinger, reboot
[16:03] <kgunn> i get stuck at splash every time
[16:04] <greyback> kgunn: perfect. I'm getting the same. unity8 isn't being started
[16:05] <greyback> kgunn: if you adb in, can run it manually with "GRID_UNIT_PX=18 QT_QPA_PLATFORM=ubuntumirserver unity8"
[16:05] <greyback> but the lenses and indicators are not running either
[16:06] <greyback> so it's kinda blank
[16:06] <kgunn> greyback: couldn't decipher mterry's response...so is it related ?
[16:06] <kgunn> do we need to go whine to asac to get that last piece in?
[16:06] <greyback> kgunn: I don't think so. But something has changed, and I've no idea what
[16:07] <kgunn> greyback: did you ever get past the splash (....thot you said you saw flicker at some point)
[16:07] <greyback> kgunn: well I need someone who understand the upstart situation to help out
[16:07] <kgunn> greyback: oh duh...you manually launched
[16:07] <greyback> kgunn: I ran it manually with that command. And can launch and switch apps when
[16:07] <greyback> s/when/then/
[16:08] <kdub> i get 'Library unity-mir not found/loaded "
[16:10] <kgunn> kdub: what the what? ^ greyback
[16:11] <greyback> kgunn: aha, that was fixed in trunk. As workaround, please install "libunity-mir-dev"
[16:11] <greyback> kdub: ^^
[16:11] <dandrader> where mir log goes by default?
[16:11] <kdub> /tmp/
[16:12] <dandrader> ok, thanks
[16:14] <kdub> dandrader, --glog-log-dir can change the directory
[16:14] <kdub> greyback, how do you normally compile unity8 for the phone?
[16:15] <kdub> i've been trying in an armhf chroot on and off, never seem to have much luck with that method
[16:15] <dandrader> kdub, does logging work as usual even when you run those examples like mir_demo_standalone_input_filter?
[16:15] <greyback> kdub: on the device itself. I've also not got chroot working
[16:16] <kdub> dandrader, i think it should, haven't tried with that specific example though
[16:16] <greyback> kdub: this is closest I've got: https://wiki.ubuntu.com/SimpleSbuild
[16:16] <greyback> but I'm stuck on older kernel without aufs (don't ask), and I need to compile it myself. Never got around to it
[16:18] <kdub> greyback, thanks, i guess i'll try on the phone
[16:19] <kdub> greyback, now i get "ASSERT: "!isEmpty()" in file /usr/include/qt5/QtCore/qlist.h, line 288
[16:19] <kdub> "
[16:20] <greyback> kdub: no idea how you got that. Please apt-get update everything, then check QT_QPA_PLATFORM=ubuntumirclient in your env
[16:21] <alan_g> kdub: re problem I'm seeing with multiwin under nested. If I increase the alpha (to, say, 0xe0) then it works - does that suggest anything to you?
[16:22] <kdub> alan_g, that the alpha is being mis-set somewhere
[16:23] <kdub> alan_g, it could just be that the alpha in the example has to be turned to opaque
[16:24] <alan_g> kdub: I do get show through - so it isn't just treating as opaque
[16:28] <kdub> greyback, still getting that isEmpty() error after the upgrade :/
[16:30] <kdub> alan_g, perhaps the example is picking the wrong pixel format?
[16:31] <kdub> greyback, maybe there's a ppa i haven't installed?
[16:31] <greyback> kdub: what device are you using? No ppa is necessary
[16:32] <kdub> mako
[16:32] <alan_g> kdub: It looks right. (And why the different behavior in nested - it ought to be nested code that causes problems).
[16:33] <kdub> alan_g, perhaps the incorrect egl configuration is chosen
[16:34] <kdub> let me check...
[18:30] <kgunn> kdub: new image...http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/
[18:30] <kgunn> greyback: ^
[18:30] <kgunn> racarr: ^
[18:31] <kdub> kgunn, is it important to test the image? i was just going to see if i can compile it myself to see the flicker
[18:31] <greyback> kgunn: yay
[18:31] <kgunn> kdub: nah...keep compiling
[18:32] <kgunn> i was just pointing it out....it only _might_ be interesting
[18:32] <kgunn> it could also be a mess
[18:32] <greyback> I'll downloading it now, will let oyu know
[18:32]  * greyback decided not to bother about correct English any more
[18:33] <kgunn> dude...aren't you irish ??....you're worse than american :)
[18:33] <kdub> me fail english? that's unpossible!
[18:34] <kgunn> only american's allowed to butcher english....and not speak any other languages to boot :)
[18:41] <racarr> *clinks red white and blue power rings with kgunn and kdub*
[18:41] <racarr> America!
[18:43] <kgunn> racarr: ....its wonder twins power activate
[18:43] <racarr> lol
[18:44] <racarr> ill test the image
[18:46] <kgunn> racarr: http://www.youtube.com/watch?v=ktUx57i63e0
[18:46] <kgunn> explains alot about my inner workings ^
[18:50] <kgunn> ...oh... racarr i just got it... note america.... 'merica!
[18:51] <greyback> oh for the love of all that's holy
[18:52] <kgunn> hmmm...im still stuck at splash (w.o command line)
[18:52] <greyback> me too :(
[18:52] <greyback> kdub: and now I get your failure too
[18:53] <kgunn> hmmm...it complains on command line for me
[18:53] <kgunn> seg fault
[18:55] <greyback> and has weird backtrace. http://pastebin.ubuntu.com/6098316/
[18:55] <greyback> wtf is happening?!
[18:57] <racarr> How to use bzr
[18:57] <racarr> I can't merge trunk int o dpms-support-api without it...removing all of dpms
[18:57] <kdub> racarr, that's happened to me before, shortcoming of bzr
[18:58] <kdub> i usually just make a patchfile and apply on top :)
[18:59] <racarr> :( yeah
[18:59] <racarr> or you can do reverts
[18:59] <kdub> well, might be a shortcoming of bzr, or a shortcoming of my knowledge of how to use bzr
[19:00] <greyback> kdub: try "export QT_SELECT=qt5" and then try shell
[19:01] <greyback> no actually, no good either
[19:04]  * greyback needs to EOD
[19:06] <kdub> mmk
[19:16] <kgunn> kdub: gonna step out for a very late lunch (read as errands)
[19:16] <kgunn> let me know how your build effort concludes
[20:21] <racarr> Lunch
[21:21] <kgunn> kdub: curious how your build is going ?...went ?
[21:24] <kdub> kgunn, still going :) arm compiles
[21:25] <kdub> tinkering with the mali604 in the meantime
[21:26] <kgunn> ooo you must be native compiling
[21:26] <kdub> yeah, i had some issues with a qemu/chroot compile (which greyback said he had too)
[21:49] <kdub> kgunn, i still get that isEmpty() error from qlist.h with the version i compiled
[21:58] <kgunn> :-/
[22:44] <kdub> the mali driver is a bit weird... but got just got a client frame to render!
[23:51] <kgunn> kdub: \o/