On 21 August 2015 at 17:11, Tanu Kaskinen <tanuk at kemper.freedesktop.org> wrote: [...] > + /* XXX: If this is a headphone jack that mutes speakers when plugged in, > + * and the headphones get unplugged, then the headphone device must be set > + * to unavailable and the speaker device must be set to unknown. So far so > + * good. But there's an ugly detail: we must first set the availability of > + * the speakers and then the headphones. We shouldn't need to care about > + * the order, but we have to, because module-switch-on-port-available gets > + * separate events for the two devices, and the intermediate state between > + * the two events is such that the second event doesn't trigger the desired > + * port switch, if the event order is "wrong". > + * > + * These are the transitions when the event order is "right": > + * > + * speakers: 1) unavailable -> 2) unknown -> 3) unknown > + * headphones: 1) available -> 2) available -> 3) unavailable > + * > + * In the 2 -> 3 transition, headphones become unavailable, and > + * module-switch-on-port-available sees that speakers can be used, so the > + * port gets changed as it should. > + * > + * These are the transitions when the event order is "wrong": > + * > + * speakers: 1) unavailable -> 2) unavailable -> 3) unknown > + * headphones: 1) available -> 2) unavailable -> 3) unavailable > + * > + * In the 1 -> 2 transition, headphones become unavailable, and there are > + * no available ports to use, so no port change happens. In the 2 -> 3 > + * transition, speaker availability becomes unknown, but that's not > + * a strong enough signal for module-switch-on-port-available, so it still > + * doesn't do the port switch. > + * > + * We should somehow merge the two events so that > + * module-switch-on-port-available would handle both transitions in one go. > + * If module-switch-on-port-available used a defer event to delay > + * the port availability processing, that would probably do the trick. */ > + > + PA_DYNARRAY_FOREACH(device, jack->ucm_hw_mute_devices, idx) > + pa_alsa_ucm_device_update_available(device); > + I'm really not happy about the idea of module-alsa-card needing to know about switching order in module-switch-on-port-available (or in general have knowledge of unrelated modules in any module if avoidable). Doesn't it make sense to fix module-switch-on-port-available to work correctly in the second case? -- Arun
