Comment 30 for bug 939161

At Fri, 07 Sep 2012 14:47:16 +0200,
David Henningsson wrote:
>
> On 09/07/2012 02:36 PM, Takashi Iwai wrote:
> > At Fri, 07 Sep 2012 14:17:58 +0200,
> > David Henningsson wrote:
> >>
> >> On 09/07/2012 01:59 PM, Takashi Iwai wrote:
> >>> At Fri, 07 Sep 2012 13:26:35 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> On 09/07/2012 12:01 PM, Takashi Iwai wrote:
> >>>>> At Fri, 7 Sep 2012 07:25:44 +0200,
> >>>>> David Henningsson wrote:
> >>>>>>
> >>>>>> The purpose of this flag is unclear. If the problem is that some machines
> >>>>>> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
> >>>>>>
> >>>>>> In addition, this causes jack detection functionality to be flawed on
> >>>>>> the M31EI, where there are two jacks without jack detection (which is
> >>>>>> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
> >>>>>> jacks are instead being reported as being present but always unplugged.
> >>>>>>
> >>>>>> BugLink: https://bugs.launchpad.net/bugs/939161
> >>>>>> Signed-off-by: David Henningsson <email address hidden>
> >>>>>
> >>>>> So this will fix this one case but will break some others certainly.
> >>>>> It's a difficult to judge, but more removal is better, so I'll take
> >>>>> this.
> >>>>
> >>>> Ok. Do you have a sense for how many machines that will regress due to
> >>>> this patch? If it is common to set all pins to the wrong value, maybe
> >>>> its the M31EI that is the exception.
> >>>
> >>> Maybe a few Acer and ASUS ones with old codecs.
> >>> Possibly some desktops with unknown mobos might hit, but that's not
> >>> what I do care so much for now.
> >>
> >> Hrm, ok. I still don't like the idea of regressing machines...maybe this
> >> patch needs further research.
> >
> > Well, let's see. I guess a problem will pop up anyway a few kernel
> > release later. People with such machines rarely follow the kernel
> > development soonish.
>
> No, they complain on Launchpad, three months after the release or so,
> about how we could be stupid enough to break their systems ;-)
>
> >>>>> But I still wonder why PulseAudio cares the headphone jack state even
> >>>>> though this has only one output at all?
> >>>>
> >>>> When seeing the system as a whole, there can be other outputs on other
> >>>> cards - HDMI, USB etc. If somebody e g plugs a USB headset in it will be
> >>>> simpler for the user if PulseAudio does not also show the unplugged 3.5
> >>>> mm jack.
> >>>
> >>> OK, but masking it out unconditionally isn't always nice. There are
> >>> always corner cases...
> >>
> >> Not sure what corner case you mean here, but if you like, you can
> >> configure this behaviour in
> >> /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf,
> >> causing the jack detection to be ignored if you prefer. And you can
> >> quirk a specific machine to use another .conf file based on udev rules.
> >>
> >> Or is the corner case that ALSA don't give the correct jack detection
> >> value? If so I prefer it to be fixed in ALSA ;-)
> >
> > Well, I can think of different cases: BIOS is broken, my hardware is
> > broken and the driver is broken. In such a case, an easier test would
> > be to disable this jack auto-things in PA, rather than fiddling with
> > the pin config and reconfigure the driver, so I hoped there might be
> > an intuitive and easy way to do that.
>
> Naah, in all those cases it is ALSA's responsibility to give a correct
> answer up to PA - and as such, also to provide an "intuitive and easy
> way" to disable jack detection if you feel there is a need. IMO.

Adjusting a user-space things is much safer than adjusting something
in kernel. The former doesn't need a root privilege (if it's done
right). Thus for debugging purpose, fiddling with PA at first would
be more comfortable than digging with the driver code and BIOS
setups.

Of course, a permanent fix is a different story. I'm talking about
the debuggability.

> That said, it's not super difficult to comment out a few lines in
> /usr/share/pulseaudio/alsa-mixer/paths/*.conf, and also, most mixer UIs
> (e g pavucontrol) still allows you to route audio to an unavailable port.

Yes, but some guidelines would be nice to have somewhere explicitly...
Also this can be done without being root somehow, right?

Takashi