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.
