/srv/irclogs.ubuntu.com/2013/12/11/#ubuntu-mir.txt

robert_ancellmterry, around?00:05
mterryrobert_ancell, hello00:05
robert_ancellCan I get you to do a quick sanity check on a lightdm merge? Just pushing it now...00:07
robert_ancellhttps://code.launchpad.net/~robert-ancell/lightdm/usc-module/+merge/19847900:08
mterryrobert_ancell, ok, looking00:09
robert_ancellta00:09
mterryrobert_ancell, why not use xmir for this?00:10
mterrywith a unity seat00:10
robert_ancellmterry, this is so we can run Unity 8 + USC from a greeter, i.e. no X00:10
robert_ancellyou then have one USC per session00:11
robert_ancelland can do full user switching etc00:11
mterryrobert_ancell, oh, huh.00:11
mterryrobert_ancell, why not run unity8 standalone then?00:11
robert_ancellbecause then it has to be root to do the VT switching / graphics permissions00:11
mterryrobert_ancell, sorry, got distracted by something.  Coming back to this00:51
mterryrobert_ancell, I guess I don't know enough about how Mir works, but I would have thought standalone unity8 and USC would have the same problems00:52
mterryrobert_ancell, so the xlocal dropping ready signal seems unrelated.  But the rest of it makes sense.  Why is the usc class a display server?  For convenience of adopting its API?01:04
robert_ancellmterry, it will be used as a display server in the U8+USC case, but yes, mostly a convenience01:14
robert_ancellactually it is required to be a display server for that case01:14
robert_ancellI figured it would be better to make the code common01:14
robert_ancellyeah, the xlocal ready signal was just something I noticed was unused01:14
mterryWell, seems fine.  Mostly just moving code around01:15
robert_ancellyes01:15
mterryI imagine the unity seat is nice and lean now01:15
robert_ancellit is :)01:15
mterryrobert_ancell, I'm working on a bug I'm seeing in Touch, with lightdm/greeter/session interaction01:15
mterryrobert_ancell, can you look at a log real quick and maybe hit me with a cluebat?01:16
mterryhttp://paste.ubuntu.com/6554125/01:16
robert_ancellsure01:16
mterryrobert_ancell, in there, I've commented some lines01:16
mterryrobert_ancell, around line 89, why do we kill the user session?01:16
mterryDoesn't seem to make sense.  Separately, I'm not sure 100% why the greeter is dying, but I think that's a mir crash01:17
robert_ancellthat is odd01:18
robert_ancellmterry, A guess - it's reset_session in greeter.c killing the existing sessions which for some reason we still hold a reference to?01:19
robert_ancellgrepping through the source suggests that would make the logs in the same order01:20
robert_ancellperhaps we have a reference to the old greeter for some reason01:20
robert_ancellbecause obviously the new greeter shouldn't know about an existing session01:21
mterryhm01:21
mterryI can add more debugging logs and drill down01:23
mterryMight be another of these 'mir does things instantly' bugs like with the other display/session bug01:24
=== duflu_ is now known as duflu
mterryWhat causes the "Could not unblank display" error?  I can't remember.  I know we used to see it often02:13
mterryI'm seeing it now in the USC during greeter testing02:13
RAOFOn the device I'd be pointing fingers at powerd.02:20
RAOFThat seems like the scapegoat of choice :)02:21
kgunnrobert_ancell: cool...just found out you're gonna do something to usc to make xmir not req'd for the unity8 preview thanks!02:33
kgunni was worrying about that one02:33
robert_ancellyeah, as discussed on a piece of paper in a hotel room :)02:34
=== shuduo_afk is now known as shuduo
robert_ancellwe just need Mir on Mir working...02:34
* robert_ancell looks at RAOF02:34
robert_ancellno pressure02:34
RAOFrobert_ancell: Mostly working :)02:35
RAOFrobert_ancell: Or, at least, the non-Mir-on-Mir bit of Mesa is working again02:36
RAOFkgunn: Why was xmir required for the unity8 preview in the first place?02:37
kgunnRAOF: only if we took in usc as-is today...in order to run unity8 on mir-on-mir w/ usc02:38
kgunnso a knock on effect02:38
RAOFAh, for the greeter?02:39
kgunnyes...02:39
RAOFRight.02:41
RAOFGah! What a super-useless error message: “session_error("egldemo")”02:42
RAOFThanks, SessionMediatorReport!02:42
RAOF(For those playing at home - current state of Mir-on-Mir-on-Mesa is ‘everything seems to work, except that clients mysteriously fail to connect’)02:43
dufluRAOF: How do unthrottled frame rates of fullscreen clients compare (-n -f) ?02:45
RAOFduflu: Between mir-on-mir and mir-on-hardware.02:46
dufluRAOF: Yes02:46
RAOFduflu: Unknown; clients fail to connect to the nested mir server.02:46
dufluRAOF: OK. We'll get there. Will be interesting to see. In fact I think that's my job. I just don't have the right Mesa to test desktop nesting yet02:47
RAOFduflu: Yeah. You'll have the right mesa just as soon as I can verify that the mesa I've got here *is* the right mesa :)02:47
RAOFWell, modulo buildd time.02:47
RAOFOh, and a small Mir change.02:47
dufluRAOF: That's fine. I have plenty of other stuff to get through before I'm back on that task02:49
=== chihchun_afk is now known as chihchun
=== shuduo is now known as shuduo_afk
RAOFduflu: So, quick and dirty eglplasma FPS eyeballing suggests that running nested slightly *increases* framerate, and seems to reduce variance.03:26
dufluRAOF: That's totally weird :)03:26
RAOFNot at all.03:26
dufluRAOF: Reduced variance is not weird. Only increased throughput03:26
dufluRAOF: You know it outputs framerate to stdout?03:27
RAOFYes, that's what I was reading.03:27
RAOFThere's no way I could tell the difference between 1800fps and 1700fps otherwise.03:27
RAOFIt's also possible that there *isn't* a significant difference in throughput; I haven't actually computed averages.03:28
dufluRAOF: Yeah, that's what I meant. We can't just say "it's over 60FPS so who cares?". It's all about percentage differences, which often interpolate to less capable machines where a small difference is more critical03:29
RAOFAnyway, this now works, except for software buffers.03:29
dufluAll too often that extra 10% on a developer machine equates to no longer missing frame deadlines on a slower customer machine03:30
RAOFI'm a bit surprised that nested gave different numbers at all, actually.03:31
dufluYeah all things working properly, throughput should be unaffected03:34
robert_ancellbregma, https://code.launchpad.net/~robert-ancell/lightdm/mir-sessions2/+merge/198487 adds support for Mir sessions03:34
RAOFduflu: Particularly because nested currently doesn't change the swapbuffers flow at all - it's client → immediate server in both cases.03:36
* duflu wonders if we're getting some extra N-buffering effect03:37
=== shuduo_afk is now known as shuduo
RAOFHm. The client receiving a 0×0 shm buffer isn't actually going to be a Mesa problem.03:50
RAOFWhich means that mesa works!03:50
RAOFWhich means that it's time to upload :)03:50
RAOFWoot. Also works on radeon.04:15
RAOFduflu: Oh, this mesa should also make running Mir under vmware work.04:19
dufluRAOF: Very interesting04:19
RAOFAssuming that our drm probing method doesn't discount them.04:19
dufluRAOF: And qemu with the vmware graphics option? :)04:19
RAOFLikewise; as long as it supports the newer vmware kernel module.04:20
RAOFHm. Mir team meeting today?04:20
dufluNot sure. Hope not. I have nothing to talk about and need to duck out at lunch04:21
=== tvoss|dinner is now known as tvoss
dufluRAOF: proposed counts as "Fix Committed", no?06:03
RAOFduflu: Yes, but if you're thinking of changing the bug status, I wouldn't bother; it'll be automatically marked as fix released soon enough.06:06
dufluRAOF: Too late06:06
RAOFHm. The commit which broke nesting on Mesa seems to have been made to fix nesting on Android.06:23
duflu??06:26
RAOFIt switched the nested platform constructor from creating a context with EGL_NO_SURFACE to creating a dummy 1×1 pbuffer surface and creating the context on that.06:28
RAOFPresumably because at least one of the Android EGL stacks didn't support EGL_KHR_surfaceless_context.06:28
RAOFHowever: Mesa doesn't support pbuffer surfaces06:28
dufluRAOF: So the new Mesa still can't nest using dev branch?06:31
dufluBecause of the dev branch...06:31
RAOFCorrect.06:31
dufluExcellent. Yes, I suspected pbuffers were deprecated but wasn't sure so did not block that from landing... Was it mterry?06:32
RAOFYeah.06:32
dufluYeah I remember that commit. Sorry. At the time it appeared nesting was still very much under development. Which is only half true06:33
dufluRAOF: Could you log a bug for that? tagged "nested" ?06:54
RAOFI'd rather just fix it.06:54
dufluThat too06:54
RAOFOnce this branch builds you can have a merge to review :)06:55
dufluWhee, more reciews06:55
dufluAnd reviews06:55
dufluAlthough if Mesa prevented it from working till now, no functionality is technically lost, yet :)06:57
RAOFI guess I should really test this on android nested, shouldn't I.07:31
RAOFBah. Why doesn't bzr lp-propose properly target lp:mir/devel when I ask it to?07:35
RAOFduflu: https://code.launchpad.net/~raof/mir/check-for-surfaceless/+merge/198510 if you want to play the nested game.07:36
dufluRAOF: Looking at it07:36
dufluRAOF: Did I miss something? Does C++ really force us to create constructors like that? Is there no other way?07:37
dufluLast time the answer was "no" but I think it's worth asking again07:37
RAOFNo other way while retaining the constness, no.07:38
dufluDear C++: Be better :S07:38
dufluAt everything07:38
didrocksRAOF: yeah lp-propose will still catch up to the "toppest branch" to what you target07:38
didrocksRAOF: that's why everytime we deploy a stack, we have to reconfigure to set trunk target as "trunk" :/07:39
RAOFWe *could* factor out the surface construction into a function, which would make things look a bit better.07:39
didrocksyou shuold do the same for mir/devel I guess07:39
didrocksshould*07:39
RAOFdidrocks: What needs to happen? lp:mir/devel properly points at lp:~mir-team/mir/development-branch07:40
RAOFduflu: You wouldn't happen to know on which android device(s) nesting is most likely to work, would you?07:40
dufluRAOF: I had it working on N4 last week07:41
didrocksRAOF: I've just run "bzr config -d lp:mir/devel public_branch=~mir-team/mir/development-branch"07:41
dufluWithout fuss07:41
didrocksRAOF: if you try now, it should work07:41
didrocksRAOF: it's a question of internal launchpad stacking branch07:41
anpok_RAOF: worked on the nexus 10 too07:54
anpok_where do i see which tests are executed or not executed through make test?07:55
RAOFThey're all executed; output goes to stdout IIRC.07:57
RAOFThere's also logs in Testing/..07:58
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
anpok_hm why do I experience test failures when i run the binaries manually?08:01
RAOFBecause you need the environment set up by umockdev08:02
RAOF(Running the binaries with “umockdev-run bin/unit-tests” will work)08:03
anpok_thx!08:03
* RAOF is hit *again* with the “find_libhardware doesn't look in the chroot” bug. Perhaps it's time to fix that.08:15
RAOFWhat's the easiest way to test on the phone again?08:28
tvossSaviq, can you help RAOF ?08:28
Saviqtvoss, RAOF, I can try, test what? (first time I've seen the find_libhardware thing)08:29
* RAOF would have turned up to the session at the sprint, but it was on before I knew it was on :)08:29
RAOFSaviq: You probably have libhardware-dev installed system-wide; that masks the bug.08:29
* duflu would have gone to a couple of useful sessions, but each time mir-team was too busy in discussions and no one could escape08:30
SaviqRAOF, nope, no libhardware-dev installed here08:30
RAOFSaviq: I need to test nesting mir on android; our documentation for that is significantly out of date.08:30
RAOFSaviq: Hm, odd. Building with ./cross-compile-chroot.sh?08:30
SaviqRAOF, haven't built mir for a long time, but when I was - yes, cross :)08:31
dufluRAOF: How old is your image?08:31
RAOFduflu: Fresh as of now.08:31
RAOFNewest in trusty-proposed.08:32
dufluRAOF: BTW, umockdev-run still not joyful on saucy... bug 125985108:32
ubot5bug 1259851 in Mir ""umockdev-run bin/mir_unit_tests" fails with: sendmsg_all: cannot run glob: Invalid argument umockdev-run: unable to propagate signal 6 to child 9323: No such process" [Undecided,New] https://launchpad.net/bugs/125985108:32
SaviqRAOF, I'm also afraid I never touched nested mir - mterry and ricmm know most there, but obviously TZ is wrong there...08:32
* duflu retests trusty08:32
RAOFduflu: Yeah, needs a umockdev SRU08:32
anpok_i could test nested on n10 .. that what i did the last two days..08:35
dufluFun. Some trusty update has bricked my laptop. Almost08:36
duflu... and that's why I maintain saucy on my primary system08:37
dufluanpok_: Very nice first code review08:44
RAOFBah. How can the phablet image not have strace installed? :)08:46
RAOFanpok_: Yeah, I agree that we should have an actual shared “check EGL extensions” helper. I'll factor one out of our existing stuff.08:47
anpok_i was unsure whether minor stuff like that was enough for "needs fixing" or .. dunno08:48
anpok_guide me ..08:48
RAOFI think that's a reasonable use of "needs fixing"08:48
dufluSometimes. Depends if we have time and have spent much time iterating the branch yet. In this case, it's fine08:48
RAOFCool, didn't break android.08:49
anpok_should the integration/acceptance test run on the device08:50
RAOFYes, but it doesn't.08:51
RAOFOh, actually it will.08:51
anpok_[ RUN      ] AndroidGPUDisplay.gpu_display_ok_with_gles08:51
anpok_unknown file: Failure08:51
anpok_C++ exception with description "could not select EGL config for use with framebuffer" thrown in the test body.08:51
anpok_[  FAILED  ] AndroidGPUDisplay.gpu_display_ok_with_gles08:51
anpok_but that happened with devel too08:51
anpok_and that one [----------] 1 test from AndroidInternalClient08:51
anpok_[ RUN      ] AndroidInternalClient.internal_client_creation_and_use08:51
anpok_seems to hang.. or take longer?08:52
anpok_i have to shutdown lightdm and unity for that?08:54
RAOFMaybe? I wouldn't think so.08:58
dufluanpok_: bug 124901909:00
ubot5bug 1249019 in Mir "Test failure: AndroidGPUDisplay.hwc_display_ok_with_gles" [Medium,Triaged] https://launchpad.net/bugs/124901909:00
=== shuduo is now known as shuduo_afk
anpok_how do i stop unity8? i thought kill would work..09:12
alan_ganpok_: as phablet: "stop unity8"09:13
anpok_hm unkown job unity809:13
RAOFanpok_: stop --user unity809:14
=== shuduo_afk is now known as shuduo
alf_anpok_: Are you logged in as user 'phablet'?09:15
alan_gsudo -i -u phablet09:15
alan_gstop unity809:16
dufluAnd if it can't find the "stop" command then: /sbin/stop unity 809:17
duflu/sbin/stop unity809:17
anpok_arg not properly logged in .. now it works09:17
anpok_hm it works09:19
anpok_but i get strange framerates09:19
anpok_7800 on non nested09:19
anpok_32 on nested demo shell09:19
anpok_7800 on non nested demo shell09:20
anpok_both eglplasma09:20
anpok_hm 32 is for root .. and 7800 for phablet user..09:20
anpok_ah09:21
* duflu just needs to reinstall the world and can then confirm :)09:30
anpok_7800 happened when i was using the mir lbiraries from system..09:34
anpok_and i also resized the buffer09:34
anpok_ah cmake  default is no optimization09:38
RAOFcmake defaults are almost all wrong. :(09:40
dufluanpok_: The surface size is a huge factor in frame rate. You need to keep it unchanged if you're comparing frame rates09:40
RAOFParticularly for eglplasma; that thing does *lots* of per-pixel computation.09:41
RAOFLess so for egltriangle :)09:41
dufluHmm, yes, I did promise less trig-per-fragment and never got around to it09:41
RAOFNah, I wouldn't bother; it's useful that it pushes the GPU a bit.09:42
dufluWe could move the existing shader into the planned "hand warmer" app09:43
alan_gduflu: in boston I found 6 levels of nesting made any app a hand-warmer09:45
dufluHandy09:45
alan_g...and terrible frame rates09:45
duflualan_g: I had a good theoretical reason why the frame rates degraded. But as recently as this morning RAOF and I couldn't see why it would happen09:46
dufluI had a reason many months ago which seemed to line up with your findings... Just can't remember09:47
alan_gduflu: well, there have been a lot of optimizations since09:47
duflualan_g: We pass through to bypass now?09:47
alan_gI don't know. We couldn't then09:47
RAOFBypass shouldn't make any difference to framerate on our current nested stack?09:48
dufluRAOF: It definitely should. If bypass was critical before, it's still critical now.09:48
alan_gRAOF: if we don't bypass then surely we copy the whole buffer for each nest09:49
* duflu hopes alan_g is kidding09:49
RAOFYeah, we copy the buffer for each nest; I guess if you nest enough that's going to kill GPU bandwidth enough for you to notice.09:50
RAOFBut that's only a 60Hz copy.09:50
dufluA 60Hz copy will kill performance on plenty of systems. Obviously we'll need to eliminate that09:50
RAOFYes, indeed.09:50
RAOFBut for things which aren't bandwidth constrained - and I'd guess that eglplasma is not bandwidth constrained - a bunch of 60Hz copies isn't going to materially affect the results.09:51
* alan_g thinks that measurement is the key09:52
RAOFOh, certainly.09:52
dufluRAOF: Not sure. Seems to depend on the GPU x framebuffer dimensions09:52
RAOFThe thing that we *don't* have with nested is spiralling IPC latency, because the relevant IPC is only client <-> immediate compositor. Once we land the generalised bypass/HWC stuff, though, IPC might be interesting.09:53
dufluAn "extra copy" was the reason why XMir never performed as well as X, despite the fact it should have been faster than X. Let's not get into the habit of accepting extra copies, or we may indefinitely lag behind existing X performance09:53
=== shuduo is now known as shuduo_afk
anpok_hm for the nested hwc stuff client api needs to be changed too? or would nested behave like a client with a bag of buffers to post?09:59
RAOFI'm not advocating that we accept extra copies.09:59
RAOFIndeed the client API needs to change for the nested HWC stuff.09:59
dufluanpok_: It's transparent. The client should never know09:59
dufluReally?09:59
anpok_duflu: the "can-you-compose-part"..09:59
alan_ganpok_: the point is that that the client doesn't know09:59
* duflu doesn't remember that discussion10:00
anpok_yeah it starts to blur away10:00
alan_ganpok_: what "can-you-compose-part" was left at the end of discussions10:00
alan_gWe ended with "you will compose..."10:01
anpok_alan_g: i thought only for the nested case.. yes10:01
alan_ganpok_: you're talking about the revised composite loop discussion?10:02
anpok_yes10:02
anpok_but maybe that happened when my stomoach toldme that i am continental10:02
alan_gWe ended with unity8 doing its own thing and then passing a set of surfaces(?) to Mir wht the instruction "you will compose this"10:03
RAOFalan_g: The nested compositor is a client; it has to know.10:03
RAOFunity8 will pass that set of surfaces to it's Mir, which will pass that set of surfaces over the client API up to usc, which will composite.10:04
RAOFs/'//g10:04
dufluThat doesn't sound right. We'd be explicitly preventing hardware composition/overlay/bypass... ?10:05
alan_gRAOF: there's still no "can-you-compose-part"10:06
RAOFalan_g: Correct.10:06
RAOFalan_g: But there *is* a change in the client api, to allow passing the bag of buffers to composite up.10:06
RAOF(Because usc is the only thing that can reasonably allocate hardware resources)10:07
* RAOF declares EOD, but may be around later to argue further :)10:08
anpok_and here i need to dig deeper10:09
* alan_g thinks maybe we need to get into the same timezone for a proper argument10:09
anpok_we talked about usc not being able to do hardware overlays due to the way buffers got allocated10:09
alan_ganpok_: this is all "future optimization" as for the time being unity8 is only passing a single buffer10:10
anpok_and that we might be able to remember those buffers/surfaces?10:10
anpok_ah ok10:10
anpok_but then we dont use hwc10:10
alan_gwe will10:11
anpok_but therfore we need to reidentifiy through one nested compositor that this is for the same surface we had in the last bag..10:12
anpok_alan_g: just wanted to finish my thoughts - while being interrupted by wife .. -> need to hunt something for lunch10:12
dufluOK, that kind of makes sense for the complicated case of some overlays and some non-overlays. But we should probably focus on not breaking the existing bypass in the simple one-fullscreen-surface case10:13
alan_gduflu: I'm not convinced it isn't already broken in nesting10:14
alan_gBut otherwise +110:14
duflualan_g: isn't? or is?10:14
dufluI'm just saying make sure bypass still works before covering complicated partial overlays10:14
alan_gduflu: has it ever worked in nested mode?10:15
duflualan_g: No idea. I haven't been able to test nesting on desktop yet. Just reinstalling trusty at present10:15
alan_gduflu: me neither10:16
dufluBut it's definitely a requirement. The need for performance at least 90% that of X is still a need10:16
dufluIdeally better10:16
alan_gAgreed. I was just reacting to "not breaking" by saying we likely need to fix first.10:17
dufluSo if it's not implemented yet, who's working on finishing nesting?10:17
dufluAnyone, or are we distracted?10:18
alan_gNo-one at the moment10:19
dufluOK, well it's all just talk right now anyway. I'll soon get back to speed and implement some automation for gathering numbers10:20
alan_gBut RAOF has been landing stuff to make it work on mesa and kdub has been fixing some problems on different android stacks. It's only just getting to the "it runs" stage.10:21
dufluYeah I know. Which is fine with me, because it should become usable just as I'm ready to use it10:21
duflu... this week at least10:21
anpok_;32m[ RUN ] ServerDisconnect.client_detects_server_shutdown11:46
anpok_unknown file: Failure11:46
anpok_C++ exception with description "Timeout while waiting for child to change state" thrown in TearDown().11:46
anpok_;31m[ FAILED ] ServerDisconnect.client_detects_server_shutdown (60188 ms)11:46
anpok_something like that happened on jenkins for roafs merge request11:46
anpok_is that something that happens now and then .. (timeout in unit test..)11:46
alan_ganpok_: something like that is happening for several requests11:47
alan_gLooks like recently switched on tests are failing intermittently11:47
alan_galf_: are you working today?11:49
alf_alan_g: yes11:49
alan_gI was going to look at our new test failures - but not if you're already onto it?11:50
alf_alan_g: I am currently working on screenshotting/casting, but I can take a look at the failures. Are these the ones mentioned above?11:53
alan_galf_: No I'll look - I just didn't want to duplicate effort11:53
alf_alan_g: ok, thanks11:53
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== chihchun is now known as chihchun_afk
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== tvoss is now known as tvoss|food
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
=== dandrader is now known as dandrader|lunch
=== dandrader|lunch is now known as dandrader
mterryI need help with Mir + Qt integration.  Specifically, strategies for getting as far as possible into a process before causing Mir to wait due to screen-off  (i.e. I want greeter to load as much as possible before pushing buffer to Mir)20:16
mterryMaybe use a different Qt backend, get everything prepped, then switch to Mir?  Is that even possible?20:16
mterryOr use some Mir API to queue changes, but not actually push the buffer until I ask?20:17
mterrygreyback, ^ ?  Or do you know who best to ping?20:17
mterryricmm, ^20:28
kdub'getting as far as possible into a process'20:33
kdub?20:33
kdubi also think our power model isn't flexible enough to handle USC in the mix as it stands today20:35
mterrykdub, the way it works right now20:38
mterrykdub, is that if you are in your session, and press the power button to lock...20:38
mterrykdub, the greeter process is frozen by Mir quite early in its lifecycle and so after the user turns screen back on again, it takes a couple seconds for greeter to finish loading and display on screen20:39
mterrykdub, I'd like to get that loading to happen while screen is off20:39
mterrykdub, but right now, Mir is getting in the way20:39
kdubyeah, a bit of a different problem than what I was talking about20:40
mterryI believe Mir is freezing us in the runQMirServerWithClient call20:41
kdubdo we know which call is blocking?20:41
mterry^  I can get more details if needed, but maybe that is enough of a clue?20:41
mterryThat call is in unity-mir20:41
kdubeh, doesn't mean much to me20:41
kdubwithout digging20:41
mterryWhich eventually calls mir::run_mir20:42
mterrykdub, ^ does that ring a bell?20:42
mterryThat's really all it does.  And connects to QApplication::quit20:42
mterryWell, it also creates ShellServerConfiguration20:42
kdubwhat's probably happening is20:43
mterryWhich might be blocking on some graphics call20:43
kdubusc stops serving buffers out to the greeter (because its obscured from view)20:43
mterryI don't think this is USC specific.  I saw the same thing with just standalone unity8.  When the screen is off, Mir freezes all clients20:44
kdubwe were talking about that last week20:45
kduband the plan was to improve our IPC a bit for that situation20:45
* kdub forgets who was looking at that though20:47
mterrykdub, that doesn't mean much to me.  Does that mean you wouldn't freeze clients?20:47
mterrykgunn, ^ do you remember who was looking into that?20:47
* kgunn reads20:47
kdubkgunn, it was the discussion about the different 'channels' of ipc requests need20:49
kdubcirca wednesday?20:49
kduband how acquiring new buffers does not need to be serialized at the protocol level with display requests20:50
kgunnkdub: mterry ....is this the long desire racarr topic of wanting to have a split queue on the server side....20:50
kgunnin order to untangle unrelated events20:51
kgunne.g. some events you don't want serialized in with the rest20:51
kdubyes20:51
kdubin as far as I understand the problem mterry is describingc20:51
kdubmterry, what i understand you to want is...20:54
kgunnmterry: kdub ...if that is it, then its racarr ....we were thinking maybe january20:54
kgunnsee this bp20:54
kgunnhttps://blueprints.launchpad.net/ubuntu/+spec/client-1404-mir-performance20:54
kgunnkdub: yeah...i think your right...becuase this was exactly the point...seperating render queue fom things like power event queue20:55
kgunnbtw...i have this one weird dysgraphic tick...i often type "g" for "q"....so if you see gueue in a minute..just replace w queue in your head20:56
mterry:)20:56
kgunnits totlally weird....they;re not even close on keyboard or in alphabet....evidence i think in shapes20:57
mterrykgunn, well, just so ya know, without that feature, locking delay might be enough of a regression to block landing split greeter.  Can still develop feature branch on side, but in terms of landing, there's probs a dependency there20:58
kgunnmterry: ok....so its become more than just a nusance of that "stale" screen shot appearing20:59
kgunn?20:59
mterrykgunn, yeah.  The stale screen shot is still a nit, but even with that one frame fixed, there'd still be a couple seconds delay as the greeter comes up because Mir is preventing startup21:00
kgunncrap21:01
kgunnmterry: anyway...when i do get hold of racarr...we'll try to bump this in priority (at least the split q part)21:04
kgunnmterry: so to distill it into what you need...you need to be able to queue up rendering even tho the screen is off ?21:06
kdubwe won't be able to do that21:32
kdubif the screen is off, more likely than not, the clocks are powered down :/21:33
mterrykgunn, sorry, missed highlights.  Yeah, I want to queue up rendering22:16
mterrykdub, if something is using cpu, I don't think we suspend everything22:16
* mterry has to jet22:17
kgunnkdub: mterry ...well actually you're wanting to "pre-render" just before waking the screen right ?22:17
kdubmterry, but we need the cpu, gpu, and bus clocks up to perform a render22:18
kdubmterry, i guess once 'power on' comes over dbus from powerd, you're probably okay to do a render there22:21
* kdub writes iterator over SurfaceStack23:02
kgunnkdub: did we get to the bottom of the exception in screen blank/unblank rapidly in succession ?23:06
kdubkgunn, no23:16
kdubkgunn, still around?23:35

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!