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