On 07.01.2018 20:32, Tanu Kaskinen wrote: > On Thu, 2018-01-04 at 20:54 +0100, Georg Chini wrote: >> On 04.01.2018 14:35, Tanu Kaskinen wrote: >>> On Thu, 2018-01-04 at 08:52 +0100, Georg Chini wrote: >>>> On 03.01.2018 14:51, Tanu Kaskinen wrote: >>>>> Your proposal sounds good, if I understand it correctly. I don't think >>>>> module-rescue-streams needs or should be involved, however. >>>> Don't we still need module-rescue-stream when a non-default HDMI >>>> sink is forcefully suspended? Or do you want to move the rescue >>>> functionality to the core? >>> I didn't think of this case. Moving rescuing to the core would make >>> sense to me, but for now I think it's fine to handle this in module- >>> rescue-streams. I think the rescue trigger should be a sink becoming >>> unavailable rather than suspended, though. If we were to use suspending >>> as the trigger, we'd anyway only do the move when the suspend cause is >>> PA_SUSPEND_UNAVAILABLE, and I don't see why we shouldn't rescue streams >>> that are left on unavailable sinks that are not suspended. >>> >> I don't understand the argument. module-rescue-stream currently >> rescues any stream if the underlying sink becomes unavailable, so >> streams that are left on unavailable sinks that are not suspended >> are already rescued. >> >> PA_SUSPEND_UNAVAILABLE would only be an additional trigger for >> the case that the sink is not removed. Your current patches change >> the state of the sink to unavailable without removing it. >> >> I do not want to rely on another module like switch-on-port-available >> to remove the sink. I see three possible ways to ensure that the >> streams are properly rescued: >> >> - Change your patches so that the sink will be removed instead of suspended. >> - Or add PA_SUSPEND_UNAVAILABLE as additional trigger to >> module-rescue-stream. >> - Or let the core rescue the streams in the suspend case. > My plan is to let the core rescue streams that are left on a sink whose > active port becomes unavailable. It doesn't matter whether the sink > suspends itself or not. > I wonder if in that case it would not make sense to put the whole rescue logic into the core (and maybe add a flag to disable it). But that can be done in a second step.
