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.

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.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic