On Mon, 2016-04-25 at 15:02 +0530, Arun Raghavan wrote: > On Tue, 2016-03-22 at 15:54 +0200, Tanu Kaskinen wrote: > > > > On Tue, 2016-03-22 at 15:41 +0200, Tanu Kaskinen wrote: > > > > > > > > > device-manager reroutes all streams whenever a new device appears. > > > When filter-apply has loaded a filter for some stream, the filter > > > device may not be what device-manager considers the best device for > > > the stream, which means that when an unrelated device appears, > > > device-manager may break the filtering that filter-apply had set up. > > > > > > This patch changes filter-apply so that it saves the filter device > > > name to the stream proplist when it sets up a filter. device-manager > > > can then check the proplist when it does rerouting, and skip the > > > rerouting for streams that have a filter applied to them. > > > > > > The proplist isn't cleaned up when the stream moves away from the > > > filter device, so before doing any decisions based on the > > > filter_device property, it should be checked that the stream is > > > currently routed to the filter device. It seemed simpler to do it this > > > way compared to setting up stream move monitoring in filter-apply and > > > removing the property when the stream moves away from the filter > > > device. > > > --- > My preference is to manage an ignore property that module-device- > manager can check, and have that managed within module-filter-apply. In > that way, all the behaviour related to module-filter-apply is > effectively encapsulated in that module, rather than leaking into > module-device-manager. > > Thoughts? I don't quite understand what you mean. With this patch, module-device- manager doesn't have other logic than checking a property and ignoring the stream if the property is set (and up to date). The property is managed by module-filter-apply. Your proposal sounds exactly the same. --Â Tanu
