On 2015-09-18 18:07, Tanu Kaskinen wrote: > Hi, > > I noticed that my headphone volume wasn't getting restored properly > when plugging in the headphones. The probable cause turned out to be > that gdm's PulseAudio instance was messing with the mixer controls, > causing mixer update events in my own PulseAudio instance. > > At the time I logged in, the gdm user lost access to the sound cards, > but Linux doesn't revoke access to file descriptors that are already > open. PulseAudio voluntarily closes the PCM device connections in that > situation, but PulseAudio doesn't close the mixer connection, so gdm > still had access to the mixer, and the jack detection events caused the > gdm to fiddle with the mixer controls. > > I will fix this issue, but I'm not sure how I should do that. There > might be some simple fix that would prevent mixer modifications when > the sink suspend cause is PA_SUSPEND_SESSION, but I could also do a > bigger change: close the mixer connection when udev changes the device > permissions. I think it's a bug in itself that we keep the mixer > connection open, even if in practice there's no harm from doing that. > Do others think the same, or should I try to only make a minimal fix, > adding a check somewhere that prevents writes to the mixer when > PA_SUSPEND_SESSION is set? Sorry for the late answer. I tend to agree, we should close the mixer connection if we don't have any access rights to it anyway. The fun thing happens when we have access again though - I think we first need to re-check jack detection stuff and update our current port (via module-switch-on-port-available), then we should probably synchronize volumes regardless of whether the port changed or not? And by that I mean always pushing our volume to the device, not the other way around. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
