On 04.01.2018 14:49, Tanu Kaskinen wrote: > On Thu, 2018-01-04 at 15:35 +0200, 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. > Hmm... when the sink becomes available again, the rescued streams > should be moved back to it. I think this functionality is not a good > fit for module-rescue-streams. I think I'll put this stuff in the core > instead, if you're ok with that. > Yes, I am fine with that. Basically it means that when a new sink becomes available, you have to check the default sink if there is any stream playing on it where the users choice is the just appearing sink.
