[alsa-devel] [PATCH] ALSA: hda - Remove ignore_misc_bit
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 david.henningsson@canonical.com --- sound/pci/hda/hda_auto_parser.c | 4 ---- sound/pci/hda/hda_codec.h | 1 - sound/pci/hda/hda_jack.c | 5 ++--- 3 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/sound/pci/hda/hda_auto_parser.c b/sound/pci/hda/hda_auto_parser.c index 4f7d2df..9acd5a9 100644 --- a/sound/pci/hda/hda_auto_parser.c +++ b/sound/pci/hda/hda_auto_parser.c @@ -141,7 +141,6 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, memset(sequences_hp, 0, sizeof(sequences_hp)); assoc_line_out = 0;
- codec->ignore_misc_bit = true; end_nid = codec->start_nid + codec->num_nodes; for (nid = codec->start_nid; nid < end_nid; nid++) { unsigned int wid_caps = get_wcaps(codec, nid); @@ -157,9 +156,6 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, continue;
def_conf = snd_hda_codec_get_pincfg(codec, nid); - if (!(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) & - AC_DEFCFG_MISC_NO_PRESENCE)) - codec->ignore_misc_bit = false; conn = get_defcfg_connect(def_conf); if (conn == AC_JACK_PORT_NONE) continue; diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index 8fd9f63..ee4ae8e 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -861,7 +861,6 @@ struct hda_codec { unsigned int no_sticky_stream:1; /* no sticky-PCM stream assignment */ unsigned int pins_shutup:1; /* pins are shut up */ unsigned int no_trigger_sense:1; /* don't trigger at pin-sensing */ - unsigned int ignore_misc_bit:1; /* ignore MISC_NO_PRESENCE bit */ unsigned int no_jack_detect:1; /* Machine has no jack-detection */ unsigned int pcm_format_first:1; /* PCM format must be set first */ unsigned int epss:1; /* supporting EPSS? */ diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c index aaccc02..c9333c9 100644 --- a/sound/pci/hda/hda_jack.c +++ b/sound/pci/hda/hda_jack.c @@ -26,9 +26,8 @@ bool is_jack_detectable(struct hda_codec *codec, hda_nid_t nid) return false; if (!(snd_hda_query_pin_caps(codec, nid) & AC_PINCAP_PRES_DETECT)) return false; - if (!codec->ignore_misc_bit && - (get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) & - AC_DEFCFG_MISC_NO_PRESENCE)) + if (get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) & + AC_DEFCFG_MISC_NO_PRESENCE) return false; if (!(get_wcaps(codec, nid) & AC_WCAP_UNSOL_CAP)) return false;
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 david.henningsson@canonical.com
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.
But I still wonder why PulseAudio cares the headphone jack state even though this has only one output at all?
Takashi
sound/pci/hda/hda_auto_parser.c | 4 ---- sound/pci/hda/hda_codec.h | 1 - sound/pci/hda/hda_jack.c | 5 ++--- 3 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/sound/pci/hda/hda_auto_parser.c b/sound/pci/hda/hda_auto_parser.c index 4f7d2df..9acd5a9 100644 --- a/sound/pci/hda/hda_auto_parser.c +++ b/sound/pci/hda/hda_auto_parser.c @@ -141,7 +141,6 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, memset(sequences_hp, 0, sizeof(sequences_hp)); assoc_line_out = 0;
- codec->ignore_misc_bit = true; end_nid = codec->start_nid + codec->num_nodes; for (nid = codec->start_nid; nid < end_nid; nid++) { unsigned int wid_caps = get_wcaps(codec, nid);
@@ -157,9 +156,6 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, continue;
def_conf = snd_hda_codec_get_pincfg(codec, nid);
if (!(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) &AC_DEFCFG_MISC_NO_PRESENCE))codec->ignore_misc_bit = false;diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index 8fd9f63..ee4ae8e 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -861,7 +861,6 @@ struct hda_codec { unsigned int no_sticky_stream:1; /* no sticky-PCM stream assignment */ unsigned int pins_shutup:1; /* pins are shut up */ unsigned int no_trigger_sense:1; /* don't trigger at pin-sensing */
- unsigned int ignore_misc_bit:1; /* ignore MISC_NO_PRESENCE bit */ unsigned int no_jack_detect:1; /* Machine has no jack-detection */ unsigned int pcm_format_first:1; /* PCM format must be set first */ unsigned int epss:1; /* supporting EPSS? */
diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c index aaccc02..c9333c9 100644 --- a/sound/pci/hda/hda_jack.c +++ b/sound/pci/hda/hda_jack.c @@ -26,9 +26,8 @@ bool is_jack_detectable(struct hda_codec *codec, hda_nid_t nid) return false; if (!(snd_hda_query_pin_caps(codec, nid) & AC_PINCAP_PRES_DETECT)) return false;
- if (!codec->ignore_misc_bit &&
(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) &AC_DEFCFG_MISC_NO_PRESENCE))
- if (get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) &
AC_DEFCFG_MISC_NO_PRESENCE)-- 1.7.9.5
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 david.henningsson@canonical.com
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.
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.
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 david.henningsson@canonical.com
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.
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...
Takashi
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 david.henningsson@canonical.com
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.
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 ;-)
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 david.henningsson@canonical.com
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.
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.
Takashi
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 david.henningsson@canonical.com
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.
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 david.henningsson@canonical.com
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
On 09/07/2012 03:09 PM, Takashi Iwai wrote:
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:
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?
Hmm, I'm afraid it's not so easy to turn off PulseAudio's jack detection without being root. Maybe it's possible using some .asoundrc magic?
Btw - I've never seen this as a practical problem myself. For debugging jack sense problems, I typically triage with 1) "amixer contents" (PulseAudio or kernel space?) 2) "sudo hda-jack-sense-test" (hardware or driver?)
Asking people to run a sudo command has never been a problem. (but maybe that's a problem in itself - i e that people are not security aware...)
At Fri, 07 Sep 2012 16:28:19 +0200, David Henningsson wrote:
On 09/07/2012 03:09 PM, Takashi Iwai wrote:
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:
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?
Hmm, I'm afraid it's not so easy to turn off PulseAudio's jack detection without being root. Maybe it's possible using some .asoundrc magic?
That's bad. asoundrc is equally cryptic like udev rules :)
Honestly, can't the whole /usr/share/pulseaudio/* files be specified via an environment variable, or automatically looking at ~/.pulse/alsa-mixer/paths/* or such?
Btw - I've never seen this as a practical problem myself. For debugging jack sense problems, I typically triage with
- "amixer contents" (PulseAudio or kernel space?)
- "sudo hda-jack-sense-test" (hardware or driver?)
Asking people to run a sudo command has never been a problem. (but maybe that's a problem in itself - i e that people are not security aware...)
Indeed.
Anyway, it's way offtopic now :)
Takashi
On Fri, 2012-09-07 at 16:32 +0200, Takashi Iwai wrote:
Hmm, I'm afraid it's not so easy to turn off PulseAudio's jack detection without being root. Maybe it's possible using some .asoundrc magic?
That's bad. asoundrc is equally cryptic like udev rules :)
Honestly, can't the whole /usr/share/pulseaudio/* files be specified via an environment variable, or automatically looking at ~/.pulse/alsa-mixer/paths/* or such?
FWIW, I'm in favor of looking at the home directory...
2012-9-7 下午1:26 於 "David Henningsson" david.henningsson@canonical.com 寫道：
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.
do you mean the commit does not fix the bug?
ALSA: hda - add support for Uniwill ECS M31EI notebook
This hardware requires same fixup for the node 0x0f like Asus A6Rp. More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d...
the real cases are those desktop which does not use hda front audio panel , they just loss the auto mute since there is no jack detect circuit but they can still hear sound from the headphone at anytime
do pulseaudio need a phantom port for the front panel headphone and mic without jack detection ?
At Sat, 8 Sep 2012 09:10:14 +0800, Raymond Yau wrote:
2012-9-7 下午1:26 於 "David Henningsson" david.henningsson@canonical.com 寫道：
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.
do you mean the commit does not fix the bug?
ALSA: hda - add support for Uniwill ECS M31EI notebook
This hardware requires same fixup for the node 0x0f like Asus A6Rp. More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d...
the real cases are those desktop which does not use hda front audio panel , they just loss the auto mute since there is no jack detect circuit but they can still hear sound from the headphone at anytime
do pulseaudio need a phantom port for the front panel headphone and mic without jack detection ?
Actually this is one good point. The jack detection isn't always reliably on such old machines, and BIOS cannot know, too. That is, it has to be adjusted by user manually, whether the jack detection is enabled or not.
So far, we solved this by providing "Auto-Mute Mode" mixer switch. But the jack detection controls don't follow this yet. Maybe we can set such a jack control as inactive state when the jack detection is disabled.
(And this reminds me that we can cut off "Phantom" name hack by following the same rule -- just set the control inactive when it has no real detection. But it still appears in control list.)
Takashi
the real cases are those desktop which does not use hda front audio
panel ,
they just loss the auto mute since there is no jack detect circuit but
they
can still hear sound from the headphone at anytime
do pulseaudio need a phantom port for the front panel headphone and mic without jack detection ?
Actually this is one good point. The jack detection isn't always reliably on such old machines, and BIOS cannot know, too. That is, it has to be adjusted by user manually, whether the jack detection is enabled or not.
So far, we solved this by providing "Auto-Mute Mode" mixer switch. But the jack detection controls don't follow this yet. Maybe we can set such a jack control as inactive state when the jack detection is disabled.
(And this reminds me that we can cut off "Phantom" name hack by following the same rule -- just set the control inactive when it has no real detection. But it still appears in control list.)
The other case is the bios of some computers with alc880 codec have pin defaults 0x00000000 for some pin complexes
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1015232
hda jack detect need pin fixup
Pin Default 0x00000000: [Jack] Line Out at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0x0, Sequence = 0x0
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=67b6ec3...
On 09/09/2012 09:50 AM, Takashi Iwai wrote:
At Sat, 8 Sep 2012 09:10:14 +0800, Raymond Yau wrote:
2012-9-7 下午1:26 於 "David Henningsson" david.henningsson@canonical.com 寫道：
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:
do you mean the commit does not fix the bug?
ALSA: hda - add support for Uniwill ECS M31EI notebook
This hardware requires same fixup for the node 0x0f like Asus A6Rp. More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d...
The PCI SSIDs are different, so I don't think that commit will affect the bug I was trying to fix.
the real cases are those desktop which does not use hda front audio panel , they just loss the auto mute since there is no jack detect circuit but they can still hear sound from the headphone at anytime
If there is no HDA front panel connected to the motherboard physically, the codec should report front headphone and mic as unconnected.
If there is an AC'97 front panel connected, the BIOS should set NO_PRESENCE in the misc bit.
If BIOS/HW does not support these simple rules, we need to quirk them.
do pulseaudio need a phantom port for the front panel headphone and mic without jack detection ?
Actually this is one good point. The jack detection isn't always reliably on such old machines, and BIOS cannot know, too.
Can you be a bit more specific about this claim? What machines? How many machines? In what way is it unreliable?
That is, it has to be adjusted by user manually, whether the jack detection is enabled or not.
So far, we solved this by providing "Auto-Mute Mode" mixer switch.
This is not a proper way to "solve" it - "Auto-Mute mode" as the control name says is more closely related to the muting of outputs, than it is to the actual jack detection.
Also, "Auto-Mute mode" is 1) only related to outputs and 2) not available generically but only for specific codecs.
But the jack detection controls don't follow this yet. Maybe we can set such a jack control as inactive state when the jack detection is disabled.
(And this reminds me that we can cut off "Phantom" name hack by following the same rule -- just set the control inactive when it has no real detection. But it still appears in control list.)
Looking at the alsa-lib API, this seems doable. It seems possible to figure out using snd_hctl_elem_info and then snd_ctl_elem_info_is_inactive. If it is also runtime changeable (i e depending on some other mixer control), we need a callback to fire on the hctl.
At Mon, 17 Sep 2012 09:39:01 +0200, David Henningsson wrote:
But the jack detection controls don't follow this yet. Maybe we can set such a jack control as inactive state when the jack detection is disabled.
(And this reminds me that we can cut off "Phantom" name hack by following the same rule -- just set the control inactive when it has no real detection. But it still appears in control list.)
Looking at the alsa-lib API, this seems doable. It seems possible to figure out using snd_hctl_elem_info and then snd_ctl_elem_info_is_inactive. If it is also runtime changeable (i e depending on some other mixer control), we need a callback to fire on the hctl.
Why are you using snd_hctl? For looking over jack controls, using snd_ctl_* is more straightforward.
Also, which callback are you thinking of? The phantom jack is basically just a placeholder, so there should be no activity from itself.
Takashi
[removing CC to bug, since this has gone a bit offtopic]
On 09/18/2012 10:26 AM, Takashi Iwai wrote:
At Mon, 17 Sep 2012 09:39:01 +0200, David Henningsson wrote:
But the jack detection controls don't follow this yet. Maybe we can set such a jack control as inactive state when the jack detection is disabled.
(And this reminds me that we can cut off "Phantom" name hack by following the same rule -- just set the control inactive when it has no real detection. But it still appears in control list.)
Looking at the alsa-lib API, this seems doable. It seems possible to figure out using snd_hctl_elem_info and then snd_ctl_elem_info_is_inactive. If it is also runtime changeable (i e depending on some other mixer control), we need a callback to fire on the hctl.
Why are you using snd_hctl? For looking over jack controls, using snd_ctl_* is more straightforward.
Ehm, because I'm one of the confused users who doesn't know why there are four different APIs (ctl, hctl, mixer, smixer) in the first place? :-) And because I started with looking at the code to amixer. IIRC.
Also, which callback are you thinking of? The phantom jack is basically just a placeholder, so there should be no activity from itself.
You said something about the user telling the system to disable jack detection - if so, (s)he will probably do so by changing a (new?) kcontrol, which would then change the inactivity status of the jack kcontrol, and then we need to pick that change up.
At Tue, 18 Sep 2012 10:40:19 +0200, David Henningsson wrote:
[removing CC to bug, since this has gone a bit offtopic]
On 09/18/2012 10:26 AM, Takashi Iwai wrote:
At Mon, 17 Sep 2012 09:39:01 +0200, David Henningsson wrote:
But the jack detection controls don't follow this yet. Maybe we can set such a jack control as inactive state when the jack detection is disabled.
(And this reminds me that we can cut off "Phantom" name hack by following the same rule -- just set the control inactive when it has no real detection. But it still appears in control list.)
Looking at the alsa-lib API, this seems doable. It seems possible to figure out using snd_hctl_elem_info and then snd_ctl_elem_info_is_inactive. If it is also runtime changeable (i e depending on some other mixer control), we need a callback to fire on the hctl.
Why are you using snd_hctl? For looking over jack controls, using snd_ctl_* is more straightforward.
Ehm, because I'm one of the confused users who doesn't know why there are four different APIs (ctl, hctl, mixer, smixer) in the first place? :-) And because I started with looking at the code to amixer. IIRC.
I also wonder. It's Jaroslav's preference :)
I'm no big fan for this implementation, so I skipped the middle layers in salsa-lib.
Also, which callback are you thinking of? The phantom jack is basically just a placeholder, so there should be no activity from itself.
You said something about the user telling the system to disable jack detection - if so, (s)he will probably do so by changing a (new?) kcontrol, which would then change the inactivity status of the jack kcontrol, and then we need to pick that change up.
Ah, no, what I thought was not to use "Phantom" name but use the normal jack name "Speaker Jack", but make it inactive, which indicates the non-detectable jack.
But yes, it's also possible that the system enables/disables the jack detection dynamically. In that case, the inactive state change is notified to snd_ctl.
Takashi
do you mean the commit does not fix the bug?
ALSA: hda - add support for Uniwill ECS M31EI notebook
This hardware requires same fixup for the node 0x0f like Asus A6Rp. More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d...
The PCI SSIDs are different, so I don't think that commit will affect the
bug I was trying to fix.
How many audio jacks do this m31ei have as JrZabott specified model=3stack(3 jacks) which use cd pin , no auto Mic since this input source also does not support jack detect.
Node 0x11 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x00000063: IN Balanced Trigger ImpSense Pin Default 0x99331121: [Fixed] CD at Int ATAPI Conn = ATAPI, Color = Black DefAssociation = 0x2, Sequence = 0x1 Misc = NO_PRESENCE Pin-ctls: 0x00:
The master playback switch is at audio mixer node 0x16
Simple mixer control 'Master',0 Capabilities: pswitch penum Playback channels: Front Left - Front Right Mono: Front Left: Playback [on] Front Right: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [0.00dB] Front Right: Playback 255 [100%] [0.00dB]
There is no headphone playback volume/switch so why do pulseaudio remove the analog output path ?
ports: analog-output-headphones: Headphones (priority 9000, available: no) properties:
active port: <analog-output-headphones>
There are mini itx chassis which does not have front audio panel, will pulseaudio remove the analog output path ?
Default PCM: rates [0x140]: 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Refer to the block diagram of alc861 datasheet, it seem every audio output and pin complex has a mute switch
And you already mentioned there is no speaker pin
the real cases are those desktop which does not use hda front audio
panel ,
they just loss the auto mute since there is no jack detect circuit but
they
can still hear sound from the headphone at anytime
If there is an AC'97 front panel connected, the BIOS should set
NO_PRESENCE in the misc bit.
Do you mean the driver should a read/write kcontrol so that user can change the state by qashctl ?
2012-9-19 上午8:35 於 "Raymond Yau" superquad.vortex2@gmail.com 寫道：
do you mean the commit does not fix the bug?
ALSA: hda - add support for Uniwill ECS M31EI notebook
This hardware requires same fixup for the node 0x0f like Asus A6Rp. More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d...
The PCI SSIDs are different, so I don't think that commit will affect
the bug I was trying to fix.
https://launchpadlibrarian.net/93810068/PciMultimedia.txt
00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 02) Subsystem: Uniwill Computer Corp Device [1584:9072]
https://launchpadlibrarian.net/93810064/Card0.Codecs.codec.0.txt
Codec: Realtek ALC861 Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x10ec0861 Subsystem Id: 0x15840000 Revision Id: 0x100300
https://bugzilla.redhat.com/attachment.cgi?id=559582
Advanced information - PCI Vendor/Device/Subsystem ID's !!--------------------------------------------------------
00:1b.0 0403: 8086:27d8 (rev 02) Subsystem: 1584:9072
Codec: Realtek ALC861 Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x10ec0861 Subsystem Id: 0x15840000 Revision Id: 0x100300
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/939161
00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 02) Subsystem: Uniwill Computer Corp Device [1584:9072]
The PCI SSIDs are different, so I don't think that commit will affect the
bug I was trying to fix.
There was a model uniwill-m31
what you need is just provide a pin fixup from the patch which remove the model
- [ALC861_UNIWILL_M31] = "uniwill-m31",
- SND_PCI_QUIRK(0x1584, 0x9072, "Uniwill m31", ALC861_UNIWILL_M31),
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=9fb...
participants (4)
-
David Henningsson -
Raymond Yau -
Takashi Iwai -
Tanu Kaskinen