[19:14] <mterry> Hey folks!  I'm trying to figure out lifecycle event management for mirserver instances.  If USC gives the mirserver a life cycle event, which piece of code might end up calling SIGSTOP on the shell?
[19:17] <mterry> kdub_, racarr__ ^ ?
[20:16] <racarr__> mterry: "Calling SIGSTOP on the shell"A
[20:16] <racarr__> ?
[20:19] <mterry> racarr__, well
[20:19] <mterry> racarr__, what seems to happen is that the unity8-greeter *sometimes* will be SIGSTOPPED when inactive
[20:19] <mterry> racarr__, seemingly due to Mir lifecycle management
[20:19] <mterry> racarr__, the unity8 shell doesn't seem to have this problem
[20:20] <racarr__> interesting, and they are both usc clients?
[20:20] <mterry> racarr__, and the greeter doesn't always.  I'm trying to trace down the origin of the SIGSTOP
[20:20] <mterry> racarr__, yeah
[20:21] <mterry> racarr__, platform-api has some code to SIGSTOP, but I didn't think USC ran the platform-api code.  Does Mir do any default interpretation of those events, or does it simply pass them on to clients?
[20:21] <racarr__> prettysure it just passes it on...maybe platform API does some interpretation
[20:22] <racarr__> I dont think things are wired to sigstop themselves though?!
[20:25] <racarr__> so lets see whats going on
[20:25] <racarr__> mterry: So the normal process lifecycle management sigstop stuff
[20:25] <racarr__> is processcontroller.cpp in unity-mir...
[20:26] <racarr__> there is also this weird
[20:26] <racarr__> serverstatuslistener.cpp
[20:26] <racarr__> which raises SIGSTOP as part of some dance with upstart...
[20:26] <racarr__> maybe that is your offender
[20:26] <mterry> racarr__, right
[20:26] <mterry> racarr__, I don't *think* so
[20:26] <mterry> racarr__, not the upstart bit though.  greeter doesn't set that variable and there is no corresponding SIGCONT for that one
[20:27] <racarr__> (the second part of that could be the problem though right?)
[20:27] <racarr__> second argument to signal handler, siginfo_t
[20:27] <racarr__> has pid of sender
[20:27] <racarr__> so maybe best to start there
[20:28] <mterry> racarr__, well the greeter CONTs fine
[20:28] <mterry> racarr__, and will STOP/CONT as it becomes active/inactive
[20:29] <mterry> racarr__, and processcontroller looks like it's used for shell apps, not shells themselves.  :-/
[20:29] <mterry> racarr__, good point about pid of sender
[20:30]  * mterry goes afk for a bit
[20:30] <racarr__> mterry: Yes...I don't think processcontroller could be involved...
[20:30] <racarr__> I was just trying to locate all the sigstops lol
[20:30] <mterry> fair!
[20:30] <racarr__> the one in platform API is for the old surface flinger compatibility
[20:30] <mterry> racarr__, oh really?  You don't think that's still used?
[20:30] <racarr__> errr let me look more carefully lol but I dont think so
[20:31] <mterry> racarr__, the stuff in default_application_manager.cpp is what I was looking at.  Not sure when it's used though
[20:31] <racarr__> yeah 98% sure thats its the old
[20:32] <racarr__> surface flinger out of process window manager
[20:32] <racarr__> thing
[20:32] <mterry> racarr__, I would love it if we just deleted all non-Mir ways of doing things
[20:33] <racarr__> I kind of thought I heard we had done that lol
[20:33] <racarr__> but apparently now
[20:33] <racarr__> not
[20:33]  * mterry goes afk for realz
[20:33] <racarr__> cya
[20:38] <kdub_> mterry, i've seen bad drivers use signals (maybe even sigstop)
[23:46] <kdub_> AlbertA, with usc and alpha, is it that the nested display doesn't fill the alpha channel?
[23:46] <kdub_> i'm finding I have to disable the alpha blending to get pixels with the overlay work