On 03.01.2018 14:51, Tanu Kaskinen wrote: > On Sat, 2017-12-30 at 18:08 +0100, Georg Chini wrote: >> On 30.12.2017 16:12, Tanu Kaskinen wrote: >>> On Sat, 2017-12-30 at 14:27 +0100, Georg Chini wrote: >>>> On 30.12.2017 13:55, Tanu Kaskinen wrote: >>>>> On Sat, 2017-12-30 at 13:09 +0100, Georg Chini wrote: >>>>>> On 29.12.2017 21:28, Georg Chini wrote: >>>>>>> On 29.12.2017 13:49, Tanu Kaskinen wrote: >>>>>>>> There's still the problem that once the HDMI sink is available again, >>>>>>>> streams won't be moved there automatically (unless module-switch-on- >>>>>>>> connect is loaded), but I think that's a lesser problem than keeping >>>>>>>> streams connected to a silent sink. >>>>>> Would not using a hook and let module-rescue-stream handle the >>>>>> suspend/unsuspend solve that problem as well? You would then also >>>>>> have to modify the default sink selection to take the suspend state >>>>>> into account. >>>>> What logic would module-rescue-stream use in the unsuspend case? It's >>>>> not obvious to me how it should determine when to move streams to an >>>>> unsuspended sink and which streams to move. >>>> The same logic that module-switch-on-connect applies with the >>>> difference that the unsuspended sink does not become the default >>>> automatically. So if the "normal" default sink selection determines >>>> that the unsuspended sink should be the default, then move the >>>> streams from the current default to the new one, else do nothing. >>> So module-rescue-stream should move all streams from the old default >>> sink to the new default sink? Or are there some exceptions? Can it even >>> ignore the unsuspend event and only care about default sink changes? >> Yes, in theory module-rescue-stream could just care about default >> sink changes in addition to the appearance and disappearance of >> sinks. This would also simplify module-switch-on-connect or make >> it even obsolete. >> The drawback are those cards with flapping jack detection. At the >> moment we can hide this driver or card problem simply by not using >> module-switch-on-port-available. >> Therefore currently I would use the suspend/unsuspend events to >> avoid mixing several unrelated problems. > Good point about faulty jack detection. We shouldn't add too much > automation that can't be disabled when jack detection is broken. > >>> module-switch-on-connect doesn't move streams that have save_sink set >>> on them. I get the impression that you don't want that exception. >>> Instead, if a stream ever becomes routed to the default sink (either by >>> moving to the default sink, or the default sink changing to the >>> stream's sink), then that should make the stream "default-routed". >> In general you are right, I don't want exceptions. See also my >> other mail. You are however also correct that there are some >> situations I did not think about. So exceptions are necessary >> whenever a stream is moved forcefully to the default sink. >> >> To take care of those situations, the save_sink flag should be >> used differently. It should only be set on those streams that >> have forcefully been moved from a non-default-sink to the >> default sink. Two possible ways this can happen: >> >> 1) The stream is moved to the sink: The original sink disappears >> and the stream is rescued to the default sink. >> 2) The sink is moved to the stream: The default sink disappears >> and the default moves to a sink where some streams are >> already playing. >> >> If the default sink is chosen manually, all save_sink flags should >> be reset. >> A manual stream move to some sink would reset the flag. >> >> This way only streams on the default sink could have the save_sink >> flag set which would always clearly indicate if a stream is playing on >> the default sink on purpose. >> >> > 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? > Here's my proposal: > > - The "save_sink" flag should be replaced with "users_routing_choice", > which is a sink name (i.e. string). > - The routing choice is set when the user moves a stream to a non- > default sink and unset when the user moves a stream to the default > sink. > - When the default sink changes, streams connected to the old default > sink should be moved unless their routing choice is set to the old > default sink. > > The moving can be handled automatically by the core. module-stream- > restore doesn't have to be concerned with moving streams any more, it > just needs to save the routing choices in the database and restore them > when new streams appear. module-switch-on-connect doesn't have to move > streams either, it only needs to set the default sink. >
