[00:17] <Sarvatt> RAOF: also laptop only
[00:21] <RAOF> Sarvatt: Doesn't appear to be explicitly laptop-only?
[00:21] <RAOF> Or, rather, there doesn't seem to be any reason external displays couldn't implement the same thing.
[00:22] <Sarvatt> http://techreport.com/news/25878/nvidia-responds-to-amd-free-sync-demo
[00:22] <Sarvatt> it'd need a new scaler in the monitor which is what gsync is
[00:25]  * RAOF is not entirely sure why external displays have scalers in them anyway.
[00:26] <RAOF> So that could be pretty simply solved :P
[00:29] <RAOF> New question: why does Intel allocate the root window differently, in a way that fails, when I pass -rootless? To the gdbatron!
[01:47] <RAOF> Oh, right.
[01:47] <RAOF> Because it turns out that Intel doesn't allocate 0x0 pixmaps in VRAM.
[01:47] <RAOF> Who knew?!
[05:41] <RAOF> Dear X damage: WTF?
[05:45] <duflu> RAOF: Inaccurate damage reports?
[05:45] <duflu> Racey?
[05:45] <RAOF> Curiously offset.
[05:45] <duflu> Oh, fun
[05:45] <RAOF> Apparrently by screen_x, screen_y.
[05:46] <RAOF> So the damage region comes out as (-230, ...) → (214, ...)
[05:46] <duflu> RAOF: Cos Mir has your screens at different locations to where X thinks? :)
[05:49] <RAOF> No; apparently because COMPOSITE interacts strangely with damage.
[06:02] <duflu> I do recall thinking I had Compiz damage handling theoretically water tight, and then seeing bugs on random occasions
[06:05] <RAOF> Well, that would have been asynchronous.
[06:05] <RAOF> Making everything significantly more difficult.
[06:19] <duflu> Yes, being outside the server did pose the biggest hurdles
[06:20] <duflu> But my Ubuntu desktop doesn't look /too/ broken right now :)
[06:23] <RAOF> Hm. Am I using a version of Mir that's unable to service requests from two windows at the same time?
[06:29] <RAOF> Grr. Is it just me, or is the msg-processor-report roughly useless?
[06:35]  * duflu hasn't used it
[06:45] <RAOF> Bah! It *is* Mir failing to send me buffers again.
[06:48] <RAOF> I mean, I'm also doing things wrong, but Mir is definitely doing them wrong as well. Bah.
[06:53] <didrocks> RAOF: shared guilt? :)
[06:53] <didrocks> hey RAOF ;)
[06:53] <RAOF> didrocks: Yo!
[06:53] <RAOF> Well, I'm merely crashing the X server when I try and start xterm. Mir is failing to let me draw anything!
[06:54] <didrocks> ah, annoying right :)
[07:59] <duflu> Dear gcc, You still suck at C++ error messages
[10:24] <janimo> is this spec uptodate? https://wiki.ubuntu.com/Mir/Spec
[10:25] <janimo> I see it links to QMir in LP which is marked as deprecated  https://launchpad.net/qmir
[10:44] <alan_g> janimo: I'm not sure what's happening with qmir - sorry. I know kgunn was checking our docs were current recently he may know more. (But is on Texas time)
[10:45] <janimo> alan_g, thanks. I am trying to learn more about mir/xmir/unity8 and try as much of it as possible out on a regular x86 desktop
[10:46] <janimo> the unity compositor/xmir part seems to be ok so far (as others have found) on integrated intel GPUs
[10:46] <alan_g> janimo: AFAIK unity8 uses unity-mir for Qt bindings
[10:46] <janimo> alan_g, seeing whether I can run unity8  was the next step :)
[10:47] <anpok> and qt itself uses platform api
[10:48] <anpok> qt-ubuntu that is
[10:49] <janimo> I just saw an old (May 2013) video with Unity8 running on a laptop, and was wondering whether that is still possible or it was mostly amockup that has been abandoned
[10:50] <alan_g> Right. I guess that platform api is preferred over qmir. I'll ask kgunn to confirm before changing the Wiki.
[10:52] <alan_g> janimo: you're probably better asking on #ubuntu-unity. But my understanding is that it should be possible to get it to work (but it won't, for example, adapt properly to the screen size.)
[10:53] <janimo> alan_g, just basic working UI without sensor support or other niceties would be enough for now, I'll ask there thanks
[11:36] <alf__> janimo: The high level picture is unity8 -> qt -> qt-ubuntu -> platform-api -> mir, and also unity8 -> unity-mir -> mir
[11:36] <alf__> greyback: ^^ please correct me if I am wrong
[11:37] <greyback> alf__: correct
[11:37] <janimo> alf__, the former for Android the latter for desktop?
[11:38] <alf__> janimo: no, both for both
[11:39] <janimo> alf__, which package provides qt_ubuntu ?
[11:39] <janimo> the latter sequence is not using qt at all? I am not sure what the two separate path are then (apps vs shell?)
[11:40] <greyback> janimo: qtubuntu-android I think
[11:41] <janimo> greyback, does it need some more work for desktop or is it misnamed (android)
[11:41] <greyback> janimo: the second path exists because unity8 is a mir server. That code path starts up Mir, and exports mir info to unity8 (via unity-mir) allowing unity8 to read window lists and change window placement/management
[11:43] <greyback> janimo: but unity8 also wants to draw a shell, the dash, launcher, etc. So for that, unity8 also acts just like any other mir client - that's the 1st code path
[11:45] <greyback> janimo: largely misnamed. It works on desktop - only annoyance is it depends on libhybris which does misconfigure your desktop. I think a patch just landed to qtubuntu to fix that, so there will be a "qtubuntu-desktop" package soon
[11:45] <janimo> greyback, by mir at the end of both code paths do we mean the unity-system-compositor ?
[11:46] <janimo> unclear at first site which of those are libraires/daemons or even protocols :)
[11:47] <greyback> janimo: no, unity8 is an instance of a mir server. It is meant to run with user permissions, only when user logs into their account. U-S-C is another Mir instance, which runs asap at startup, as root user, and is resposible for the login greeter, startup animations and user switching
[11:47] <janimo> since I understood mir is two libraries (server and client) to build higher level components from, it confuses me when I see a role attributed to Mir
[11:48] <alf__> janimo: for these paths s/mir/libmirserver/
[11:48] <janimo> ack
[11:48] <greyback> mir supports nested servers, so unity8 mir server will be a client of the USC mir server
[11:49] <janimo> and xmir is only a transitional step, but otherwise it won't be needed on unity8 desktop?
[11:51] <greyback> yes  - though will be needed for compatibility for exotic toolkits which do not have native support for mir, only X
[11:59] <alf__> janimo: also note that xmir is moving towards rootless support (being able to run x apps as windows in unity8) instead of the current state which is running a whole X session under mir.
[12:00] <janimo> alf__, I noticed that. I first ran xmir today, and mostly read docs so far
[12:00] <janimo> I am more interested in running unity8/mir without the android bits and using mesa, rather than desktop use cases/convergence
[12:01] <janimo> so tablet like use case but on the free stack
[12:01] <janimo> this is a subset of the full converge work AFAIK
[12:02] <ogra_> note that the nested U-S.C and Mir stuff will land on the phone next week (or so... still waiting for a hybris patch to land it)
[12:03] <alf__> alan_g: anpok: Do you have any (links to) notes from our discussion about hardware layer and related APIs? I was looking at lp:~kdub/mir/db-optimize but I get the feeling that we discussed something slightly different in terms of API (execute-around-method?), but perhaps that was at a higher level?
[12:04] <alan_g> alf__: someone took photos but I've not got a link
[12:05] <alf__> alan_g: I think it was kdub :)
[12:26] <anpok> alf__: we discussed various variants
[12:26] <anpok> to which one did we settle?
[12:28] <alf__> anpok: that's what I don't remember :)
[12:28] <anpok> alf__: there was the topic of locking planes between the start of drawing and the final post
[12:28] <anpok> i.e. to cover things like, somebody plugs in a monitor and the scan out engine has not enough overlays/planes left ..
[12:32] <anpok> (provided thats possible at all)
[12:33] <anpok> i wonder if the interface shouldnt be just: draw(list<buffers_with_transformation>) .
[12:40] <alan_g> alf__: anpok we settled on Mir being told "draw these" - no holding locks across interactions
[12:41] <anpok> so it would fallback on its own when necessary
[12:43] <alan_g> "fallback" being gl compositing? Yes
[12:44] <alf__> alan_g: anpok: What triggered my concerns was that lp:~kdub/mir/db-optimize introduces the optimize() call which means that we may need to keep state between optimize() and post(). I think I remember some related discussion, but it could be that the discussions were for a higher level, or that my memory is failing me.
[12:44] <anpok> is display_buffer the interface level
[12:44] <anpok> yes
[12:45] <anpok> is that the interface level were that would happen or is there a more higher level interface the shell would ues..
[12:45] <anpok> it is now in display_buffer::optimize
[12:53] <alan_g> I don't believe we have a migration path thought out - this is still a couple of items down the backlog. But surely "optimize" and "post" are both part of the "draw these" processing.
[13:04] <anpok> looking at the interfaces there again, i think display_info should be the place to add draw_these
[13:41] <anpok> alf__: will make another MP - I would then also eradicate the k-constants. if there is no futher objection
[13:42] <alf__> anpok: sure
[13:42] <anpok> I was reluctant because I found two forms of constants.. with the normal variable nameing style, and ALL_CAPS
[14:09] <davmor2> just had my first lockup on maguro since the new mir landed so I don't know what it changed but it isn't dying anywhere near as often on maguro now well done team :)
[14:12] <dandrader> alf__, hey, got some spare time to help a mostly clueless guy with "OpenGL in Qt vs EGL in Mir" issues (on the "qml as mir compositor" task)?
[14:14] <dandrader> my qml compositor is notified about the creation of a client surface. so I create the corresponding qt scene graph and qml item for it, to that is gets displayed on the qml scene
[14:14] <alf__> dandrader: sure
[14:14] <alan_g> anpok: ALL_CAPS should be reserved for preprocessing macros
[14:14] <dandrader> but when I call bind_to_texture
[14:14] <anpok> alan_g: i agree
[14:14] <anpok> will include that way then ..
[14:14] <dandrader> the texture displaying the client surface is there being shown and updating nicely on the qml scene
[14:15] <dandrader> but all other gl textures used by Qt get borked
[14:15] <dandrader> the one used to hold fonts is blanked
[14:15] <dandrader> and the other used to hold an image starts showing the contents of that client mir surface as well
[14:16] <anpok> is that GL vs GLESv2?
[14:17] <dandrader> alf__, I could make a video if that would help understanding the situation
[14:18] <alf__> dandrader: no need, do you have some code I can read/try out?
[14:19] <dandrader> alf__, I do, but is not so convenient as you need to build and install a couple of repos (a qpa, a specific mir version, install qt 5.2..)
[14:19] <dandrader> ah, and a specific platform-api as well
[14:19] <dandrader> alf__, want to try it still? :)
[14:21] <alf__> dandrader: I would at least like to just quickly check what it is doing :)
[14:21] <alf__> dandrader: so perhaps not run it yet
[14:27] <dandrader> alf__, 1- so, install qt 5.2 from that "canonical edgers" qpa, 2- that mir lp:~unity-team/mir/mir-for-qpamirserver, 3- that platform-api lp:~dandrader/platform-api/set_window_dimensions and 4- that qpa lp:~unity-team/mir/mir-for-qpamirserver
[14:28] <dandrader> alf__, sorry, the qpa is this one: lp:~unity-team/+junk/qpa-mirserver
[14:29] <dandrader> alf__, then follow the instructions in the README in this qpa-mirserver on how to run the demo shell and client
[14:29] <alf__> dandrader: ok, I will start by just reading the code and see if I actually built this :)
[14:30] <dandrader> alf__, ah, and that's on a nexus 10
[14:31] <alf__> dandrader: btw, how does your work overlap with what greyback is doing?
[14:32] <dandrader> alf__, its the same code base
[14:32] <dandrader> alf__, I'm just trying to help him out while he's busy with other work (e.g. side stage, etc)
[14:36] <alf__> dandrader: ok, mir::graphics::Buffer::bind_to_texture() needs an existing texture to bind the contents of the buffer to, i.e. it doesn't create a texture itself.
[14:40] <alf__> dandrader: my guess is that in MirBufferSGTexture you need to create a texture (whose id you can then return in textureId()) and bind to that
[14:41] <alf__> dandrader: so, more or less: glGenTexture() once, and glBindTexture(), Buffer::bind_to_texture()] in MirBufferSGTexture::bind()
[14:42] <alf__> dandrader: (unless qt provides a better way to deal with raw gl objects)
[14:43] <alf__> dandrader: see src/server/compositor/gl_renderer.cpp:199
[14:45] <dandrader> alf__, excelent. makes sense. thanks, I will try it! For me the interaction between EGL and the current OpenGL context in Qt is a really gray area
[14:47] <dandrader> alf__, so glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image) acts on the GL_TEXTURE_2D of the currently active texture unit in the current Openg GL context. is that it?
[14:48] <greyback> alf__: aaahhh, dammit that makes sense
[14:48]  * greyback kicks himself hard
[14:50] <alf__> dandrader: yes, on the target the currently active texture unit (i.e. what was last bound with glBindTexture() on that unit)
[14:51] <alf__> dandrader: don't forget to set attributes of the texture as in gl_renderer.cpp
[14:51] <dandrader> alf__, ok, thanks!
[14:53] <alf__> dandrader: hmm, although I see some qt calls in MirBufferSGTexture::MirBufferSGTexture that indicate that perhaps qt can do that for you, provided it somehow gets the texture id from you?
[14:55] <dandrader> alf__, from my current understanding I think qt expects a QSGTexture (which MirBufferSGTexture extends) to do the texture creation itself. although it might have some kind convenience wrapper, which use should be optional
[15:05] <alf__> dandrader: I am wondering whether the setFiltering(...) ... updateBindOptions() etc calls in the constructor will have any effect, since the texture is not bound yet at that point...
[15:08] <dandrader> alf__, AFAIU, they just fill up the internal variables of QSGTexture
[15:08] <dandrader> like in a simple POD struct
[15:09] <dandrader> alf__, so that the scene graph might query them later one
[15:09] <dandrader> s/one/on
[15:10] <alf__> dandrader: right, but I guess that updateBindOptions() actually applies these values, which will need a bound texture?
[15:10]  * dandrader checks
[15:11] <dandrader> alf__, you're right
[15:11] <dandrader> alf__, thanks for pointing that out!
[15:12] <alf__> dandrader: np
[15:24] <ogra_> mterry, FYI, maguro tested and running fine with nested mode, now we just need to get ricmm_ to commit that hybris fix for grouper
[15:25] <mterry> ogra_, awesome.  I was able to revive my grouper device from what I thought was certain death, so I can test that when it's available
[15:25]  * mterry gets excited for nested mode to land
[15:26] <ogra_> good, i can test too ... we just need to clone ricmm_ somehow ... he is swamped i think
[15:26] <ogra_> or get asac to announce that we drop grouper :P
[15:28] <ogra_> mterry, bah, spoke to soon, seems i cant wake it up from suspend
[15:28] <mterry> ogra_, oh no
[15:29]  * ogra_ reboots 
[15:31] <ogra_> hmm, now it wakes up but takes nearly 10sec to do so after pressing the button
[15:31] <dandrader> alf__, problem solved! thanks a lot!!!
[15:31] <dandrader> greyback, \o/
[15:31] <ogra_> ... and works immediately on all subsequent presses
[15:31] <ogra_> this is weird
[15:31] <greyback> dandrader: woo! thanks alf__ !!
[15:33] <alf__> dandrader: greyback: great!
[15:34] <alan_g> alf__: got time to comment on https://code.launchpad.net/~alan-griffiths/mir/expose-rpc-infrastructure/+merge/200879?
[15:35] <alf__> alan_g: sure, will look in 5'
[15:39] <ogra_> mterry, hmm, looking with dbus-monitor it seems like the display stays off until there is dbus feedback from NM o_O ...
[15:40] <ogra_> i reliably see it turning on if the NM response to the resume shows up
[15:40] <mterry> ogra_, well this branch does move the dbus service that powerd talks to from unity8 to unity-system-compositor...
[15:40]  * ogra_ wonders how that can be connected 
[15:42] <ogra_> mterry, well, it looks like the screen only turns on when indicator-network activation happens
[15:42] <ogra_> which is pretty strange
[15:43] <mterry> let me see if I see anything similar on manta
[15:43] <ogra_> might be a coincidence, but it is pretty reproducable
[15:43] <ogra_> (running dbus-monitor as the phablet user indeed)
[15:47] <mterry> ogra_, I don't see similar behavior on mako or manta
[15:47] <ogra_> this is good ...
[15:47] <ogra_> but on maguro it will bite us in the tests
[15:47] <mterry> yup
[15:47] <mterry> :(
[15:47] <ogra_> (since they fail if unlocking doesnt happen in time)
[15:48] <ogra_> we had such a thing before (i guess davmor2 remembers) ... but it was fixed inbetween
[15:48]  * ogra_ tries to find the old bug
[15:48] <mterry> kdub, are you still well versed in nesting mode concerns?  We're seeing a weird behavior on maguro where the screen doesn't wake up in a timely fashion  ^
[15:49] <ogra_> bug 1255045
[15:50] <davmor2> ogra_: if you drop grouper and maguro what the hell do I test on
[15:50] <ogra_> davmor2, the new flo and mako your manager has sent you before we dropped them ;)
[15:51] <davmor2> ogra_: but these are both mine that I bought to play with Ubuntu on :'(
[15:52] <ogra_> mterry, so it seems this patch from duflu fixed it http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/154 ... i wonder if u-s-c needs a similar patch if the screen is now handled through it
[15:52] <ogra_> davmor2, so you can still do community testing with them
[15:52] <davmor2> ogra_: When! :D
[15:54] <mterry> ogra_, yup.  That patch didn't make it to u-s-c
[15:54]  * mterry whips up a branch
[15:55] <ogra_> awesome !
[15:55] <ogra_> that was quick :)
[15:57] <davmor2> ogra_: what is usc to you? It is Ubuntu Software Center to me :)
[15:57] <ogra_> not in this channel ;)
[15:57] <ogra_> unity-system-compositor
[15:57] <davmor2> ah
[15:57] <ogra_> everywhere else it is ubuntu-software-center ;)
[15:58] <davmor2> you can understand my confusion now though right we really need to start thinking more about initials and if the already exist :D
[16:02] <mterry> ogra_, do you mind giving lp:~mterry/unity-system-compositor/dbus-screen-fix a test?  I'll test on my other devices to confirm no regressions
[16:05] <janimo> kgunn, hi, which are the new mir integration tests in trusty-proposed? What package?
[16:05] <ogra_> mterry, will do will take a bit (meeting run for the next 2h now and i have no active arm build env atm)
[16:05] <mterry> ogra_, OK, will mark it for merge review so jenkins makes a deb
[16:05] <ogra_> ++
[16:05] <kgunn> janimo: hey!...yeah...yesterday they were in the devel-proposed image
[16:05] <janimo> kgunn, I have 121 installe don the n4
[16:06] <kgunn> janimo: to double check apt-cache policy libmirserver* if you have libmirserver12 installed tests should be there
[16:06] <kgunn> janimo: well...actually
[16:06] <kgunn> janimo: you'll need to apt-get install mir-test-tools
[16:06] <janimo> mir-test-tools itself is not, indeed
[16:07] <janimo> kgunn, any chance of adding it by default in the image? The use case is network not being available while doing graphics bringup and testing is
[16:07] <mterry> ogra_, hopefully when you're ready, https://code.launchpad.net/~mterry/unity-system-compositor/dbus-screen-fix/+merge/201211 will have debs
[16:08] <ogra_> perfect !
[16:08] <janimo> kgunn, not sure whose call is adding packages to the build. ogra?
[16:08] <ogra_> janimo, i just add them on request to the seeds (if they actually need seeding, ususally deps just pull things in)
[16:09] <janimo> ogra_, well I can request adding mir-test-tools but someone else needs to approve such requests I guess
[16:09] <janimo> and ask for a reasone (which I provided above for this particular request)
[16:09] <ogra_> kgunn, do they install any upstart job or anything that would make a binary start etc ?
[16:09] <ogra_> or would thesy just add some extra binaries that arent used by anything
[16:10] <janimo> ogra_, well they have 5 deps (lttng, libumockdev, liburcu1) so may not be very straighforward from seedin PoV
[16:11] <janimo> ogra_, but other than that they are a couple of binaries to test Mir client and server
[16:13] <janimo> ogra_, but it is those deps that make it desirable by default in the image, to avoid installing many debs by hand
[16:14] <ogra_> janimo, hmm, not sure what the mock pieces might do
[16:14] <janimo> especially when the image being tested is no longer the very latest and there are newer versions of libmirserver and libmirclient
[16:14] <ogra_> was long as system behavior doesnt change due to a seed change i'm all fine
[16:15] <ogra_> read: someone needs to a) run the whole testsuite with them installed and make sure nothing fails
[16:15] <janimo> ogra_, I'll do that and let you know
[16:15] <ogra_> b) give me an MP against the ubuntu-touch seed branch
[16:15] <ogra_> (and c) some manual smoketesting would be nice but not mandatory)
[16:16] <janimo> ogra_, well the mir tests set up fake DRM devices or various other udev driven environment bits
[16:16] <janimo> hence umockdev -
[16:16] <ogra_> right
[16:16]  * janimo has just grepped the sources
[16:16] <ogra_> as long as they only do that when invoked by a test and not in the general system thats fine
[16:17] <ogra_> if they modify (install udev rules) the system in a permanent way we cant just ship it
[16:17] <ogra_> janimo, given pitti is the umockdev upstream, he can probably shed some light on if it makes sense to ship that stuff by default
[16:18] <ogra_> he should know the impact
[16:20] <janimo> ogra_, it's only libumockdev that is depended upon , not the umockdev binary
[16:21]  * janimo wonders whether a custom build channel devel-devel would make sense
[16:21] <janimo> devel version of ubuntu with development/testing  related packages added in the image
[16:22] <janimo> targetting bringup and porting work mostly
[16:22] <janimo> or even automated hw test setups
[16:25] <ogra_> janimo, well, i would expect a bringup to be done on a rw image in any case
[16:26] <ogra_> so the channels wouldnt really help here
[16:26] <mterry> ogra_, hrm.  With my patch, u-s-c crashes with the "could not activate surface with eglMakeCurrent" error
[16:26] <ogra_> mterry, i guess we need duflu ... he wrote the original
[16:28] <mterry> kdub, you around?
[16:30] <kdub> mterry, otp
[16:31] <mterry> kdub, ok, no worries.  when you're done, I'd like some talk-through help
[16:35] <kgunn> janimo: sorry...i am otp to...lost context...you ok? or got other questions ?
[16:36] <kdub> mterry, ok, done with the call, whats up?
[16:36] <kgunn> mterry: that looks like the annoying "unity8 took long to shut down..and powerd switched blank on..now mir can't get screen"
[16:36] <kgunn> mterry: if you do "powerd-cli display on bright" from root on device
[16:36] <mterry> kdub, so.  For nested mode, I've moved the dbus interface that powerd talks to from unity-mir to unity-system-compositor
[16:36] <kgunn> it should hold the display on for testing...
[16:37] <kgunn> obviously....if its not just testing....then yeah, we have a problem
[16:37] <mterry> kgunn, yeah not just for testing  :(
[16:37] <mterry> kdub, but a fix went in in the meantime to fix a screen blanking issue on maguro.  I've ported that patch over to u-s-c too, but now I get an error "could not activate surface with eglMakeCurrent".  Here's my branch: https://code.launchpad.net/~mterry/unity-system-compositor/dbus-screen-fix/+merge/201211
[16:37] <janimo> kgunn, I am ok, just wanted to know what your team thinks of adding mir-test-tools to the default images
[16:37] <mterry> kdub, now...  can starting a compositor twice be bad?  Should I be guarding those calls to start/stop?
[16:38] <kgunn> janimo: i'm fine with that idea...kdub ? you ok if mir-test-tools shows up in images ?
[16:38] <kdub> kgunn, sure, works for me
[16:39] <kgunn> mterry: kdub ( ricmm_ & greyback to a degree)....i think we need to have a sequence diagram of screen blanking...
[16:39] <kdub> mterry, with the way mir code is now, start() shouldn't be called twice, i can patch that though
[16:39] <kdub> kgunn, i agree
[16:39] <kgunn> we keep suffering either bugs in the product...or annoyances in testing...
[16:40] <kgunn> kdub: i know you're busy on hwc stuff....
[16:40] <mterry> kdub, I'm not certain I'm calling it twice right now...  But it just seemed possible
[16:40] <mterry> kdub, there doesn't seem to be a call to see 'isStarted' or something to even guard the call
[16:40] <mterry> kdub, if I did call it twice, would that explain the crash I'm seeing?
[16:41] <kdub> i think it could, but i have to poke around to be sure
[16:41] <mterry> kdub, OK.  I will also test on my end with my own guard variable
[16:42] <kdub> i'll fix it in mir, shouldn't take too long
[16:43] <kdub> the call to blank/unblank though is guarded against double on's
[16:48] <mterry> Guh!  Now I can't reproduce
[16:49] <kdub> now that you added the guard?
[16:49] <mterry> ogra_, ^ can't reproduce anymore, so I'd still like to see your testing results when you can get to them.  No rush
[16:49] <mterry> kdub, no, just at all
[16:50] <mterry> I reproduced it several times in a row...  Now nothing
[16:50] <ogra_> it seems unreliable ... even on my maguro i have it sometimes react immediately (most of the time it takes >10sec to wake up though)
[16:51] <mterry> I meant the u-s-c crash, but yeah, these powerd interactions seem less than predictable
[16:51] <ogra_> oh, ok
[16:52] <mterry> I haven't been able to reproduce the screen wake up problem at all.  Might just be a maguro issue
[16:52] <ogra_> yeah, like the old one was
[16:53] <alan_g> kdub: do you still dislike "namespace google { namespace protobuf { class RpcChannel; } }"?
[16:53] <mterry> debs are in the merge for ya, btw
[16:54] <alan_g> alf__: anpok opinions on "namespace google { namespace protobuf { class RpcChannel; } }" as a single line?
[16:57] <kdub> i don't mind it in general, but the rest of the code puts something like that on 7 lines
[16:59] <alf__> alan_g: I am ok with one level of "namespace X { class Yy }", but with more I think the class name is somewhat lost in the text
[17:01] <alf__> alan_g: e.g., I would be more OK with http://paste.ubuntu.com/6727615/ if we want to keep it short
[17:08] <janimo> ogra_, better than I thought, all the deps of mir-test-tools are already in the image (they were not on my desktop only)
[17:09] <ogra_> janimo, ah, perfect ...
[17:11] <janimo> ogra_, where is the bzr branch you need a MR agains for adding mir-test-tools ?
[17:22] <alan_g> alf__: sorry, got distracted. I don't think we have a consensus format.
[17:25] <janimo> ogra_, https://code.launchpad.net/~jani/ubuntu-seeds/ubuntu-touch.trusty-mir-test-tools/+merge/201236
[17:26] <ogra_> janimo, perfect
[17:32] <kgunn> janimo: i saw your mail...about the failing tests....did you stop unity8 before running ?
[17:32] <kgunn> kdub: janimo should stop unity8 correct ?? ^
[17:33] <kdub> yes
[17:33] <kgunn> at least i did stop unity8....and integration, acceptance tests pass 100%
[17:33] <kdub> although segfaults shouldnt be happening
[17:33] <kgunn> unit-test fails...only 1 after many...its the
[17:34] <janimo> kgunn, I did not stop it :)
[17:34] <janimo> kgunn, well then the tests are great, since the majority passed even with unity8 running
[17:34] <kgunn> janimo: ok...hopefully you'll get even better results when you try with untiy8 stoped
[17:35] <janimo> kgunn, how is that doen again? kill the process or some upstart command?
[17:35] <janimo> I keep forgetting even though I had stopped unity8 in the past IIRC
[17:36] <alan_g> janimo: sudo -u phablet -i stop unity8
[17:37] <kdub> janimo, sent a mail, but last I remember, mir_stress should be run against a demo server
[17:38] <kgunn> janimo: right...running as "phablet" just "stop unity8"
[17:39] <kgunn> janimo: also...as kdub says....really for the case of this testing...it should be unit, integration & acceptance
[17:39] <janimo> I used su - phablet and that did not find stop. I need to remember to stick to sudo -i -H -u phablet
[17:45] <kgunn> janimo: i'm gonna update https://docs.google.com/a/canonical.com/document/d/1oxXDxehRQ35rYRwkuBCy1ZNmB_IBpg5UhE3jvNHEk_0/edit#
[17:45] <kgunn> with the unity8 stop
[17:47] <janimo> kgunn, ok. I just sent a new email
[17:50] <kgunn> janimo: thanks..
[17:54] <ogra_> janimo, never use su :)
[17:54] <ogra_> (gets you a totally different env than sudo)
[17:55] <janimo> ogra_, yes  I remember the thread on the mailing list a few months ago, but it seemed to end inconclusively
[17:55] <janimo> I had used su - so far because it is shorter :)
[17:55] <ogra_> we use sudo -u phablet -i everywhere
[17:55] <janimo> ogra_, I will too from now on :)
[17:55] <ogra_> yeah :)
[17:55] <ogra_> janimo, meta uploaded btw
[17:57] <janimo> ogra_, thanks
[20:35] <mterry> Does mirserver initialize the display to on or off on startup?  (by itself, not worrying about powerd right now)
[20:35]  * mterry is trying to wade through the code to determine, but perhaps someone knows off the top of their head
[20:52] <anpok> mterry: i dont think so, it only interferes with hwc and framebuffer device
[20:52] <mterry> anpok, so it leaves it uninitialized until powerd asks the compositor to turn it on/off?
[20:53] <mterry> anpok, mirserver deals with screen when that happens via Display::configure()
[20:53] <mterry> I'd assumed it would do something on startup too
[20:55] <kdub> mterry, it does set the screen to unblanked on start
[20:55] <mterry> kdub, OK, cool.  Where?
[20:57] <anpok> HWCCommondevice::turn_screen_on ..
[20:57] <kdub> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platform/graphics/android/hwc_common_device.cpp#L58
[20:57] <anpok> but I thought that would not turn the display on/off
[20:58] <kdub> anpok, those hal functions should blank or unblank the fb device
[20:59] <kdub> mterry, is that what you meant, or did you mean something else?
[21:00] <mterry> kdub, I believe that's what I wanted, yeah
[21:01] <kdub> cool... that constructor should get hit when the_display() is called the first time (not for nested / offscreen of course)
[21:09] <mterry> kdub, hmm
[21:10] <mterry> kdub, testing restarting unity8 with the screen off doesn't turn screen on
[21:11] <kdub> restarting how
[21:11] <kdub> and in what powerd state?
[21:13] <mterry> kdub, um
[21:14] <mterry> kdub, I had pressed power button so screen was off
[21:14] <mterry> kdub, then I did a "sudo -u phablet -i restart unity8"
[21:15] <kdub> right, so the power button allows the system to enter 'powerd inactive'
[21:16] <kdub> my understanding is that everyone could assume that things were on to start with... although hopefully the discussion about those power interactions clarifies the situation
[21:16] <mterry> kdub, sure.  I'm just trying to document the current situation.  And if mirserver is turning display on on startup, I'd expect a unity8 restart to turn display on
[21:17] <kdub> right, it should
[21:18] <mterry> hmm