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