ALSA: HDA: Add jack detection for HDMI

From d47239ae3d352b898649d0c15869dedd032ccbd7 Mon Sep 17 00:00:00 2001

From cdc4030a2028efdd1c36f2dc37402ea6971e1b12 Mon Sep 17 00:00:00 2001

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

I considered making additional SND_JACK_* constants for HDMI and Displayport instead of going with SND_JACK_VIDEOOUT, but it didn't seem worth the additions, and breakage of compiling with old kernels, etc. Let me know if you think otherwise and I'll prepare a second patch for that.

At Tue, 17 May 2011 15:46:43 +0200,

Quoted 4 lines · David Henningsson

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

Quoted 5 lines

I considered making additional SND_JACK_* constants for HDMI and Displayport instead of going with SND_JACK_VIDEOOUT, but it didn't seem worth the additions, and breakage of compiling with old kernels, etc. Let me know if you think otherwise and I'll prepare a second patch for that.

Did you test it with the actual machine, right?
If it's working, I'm fine to add it.

From 0be95828e59250af983c86b3ec49d1ea81d8ec82 Mon Sep 17 00:00:00 2001

Quoted 6 lines · Takashi Iwai

At Tue, 17 May 2011 15:46:43 +0200,

Quoted 4 lines · David Henningsson

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

Quoted 8 lines

Quoted 5 lines

I considered making additional SND_JACK_* constants for HDMI and Displayport instead of going with SND_JACK_VIDEOOUT, but it didn't seem worth the additions, and breakage of compiling with old kernels, etc. Let me know if you think otherwise and I'll prepare a second patch for that.

Did you test it with the actual machine, right?
If it's working, I'm fine to add it.

To be honest; it's partially working, or rather it's working in the sense that it follows the eld proc file. It's also working in hda-emu.

I've tried it on one Nvidia (with binary drivers), and one Intel Graphics and well, and both seem to have the same problem essentially:
There is no hotplug event coming in (through hdmi_unsol_event) when a monitor is removed. But with this patch in perhaps the graphics driver writers will feel more motivated to fix it? :-)

Note that the hotplug event is not coming in when you actually plug the cable but when you detect displays and/or apply the monitor configuration change.

I'm attaching a new version of the patch according to your preference, in hopes that it will be in 2.6.40.

Signature · 4 lines

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
[2 0001-ALSA-HDA-Add-jack-detection-for-HDMI.patch <text/x-patch (7bit)>]

Quoted 1 line

From 0be95828e59250af983c86b3ec49d1ea81d8ec82 Mon Sep 17 00:00:00 2001

From: David Henningsson <[email protected]>
Date: Thu, 19 May 2011 11:46:03 +0200
Subject: [PATCH] ALSA: HDA: Add jack detection for HDMI

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

Signed-off-by David Henningsson <[email protected]>

---
 sound/pci/hda/hda_codec.c  |    2 ++
 sound/pci/hda/patch_hdmi.c |   11 +++++++++++
 2 files changed, 13 insertions(+), 0 deletions(-)

sound/pci/hda/hda_codec.c +2 -0

index c63f376..8edd998 100644
@@ -5055,6 +5055,8 @@ static const char *get_jack_default_name(struct hda_codec *codec, hda_nid_t nid,
 		return "Line-out";
 	case SND_JACK_HEADSET:
 		return "Headset";
+	case SND_JACK_VIDEOOUT:
+		return "HDMI/DP";
 	default:
 		return "Misc";
 	}

sound/pci/hda/patch_hdmi.c +11 -0

index 6eb209d..7348296 100644
@@ -33,6 +33,7 @@
 #include <linux/slab.h>
 #include <linux/moduleparam.h>
 #include <sound/core.h>
+#include <sound/jack.h>
 #include "hda_codec.h"
 #include "hda_local.h"
 

@@ -720,6 +721,8 @@ static void hdmi_intrinsic_event(struct hda_codec *codec, unsigned int res)
 				  &spec->sink_eld[index]);
 		/* TODO: do real things about ELD */
 	}
+
+	snd_hda_input_jack_report(codec, tag);
 }
 
 static void hdmi_non_intrinsic_event(struct hda_codec *codec, unsigned int res)

@@ -912,6 +915,7 @@ static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
 static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
 {
 	struct hdmi_spec *spec = codec->spec;
+	int err;
 
 	if (spec->num_pins >= MAX_HDMI_PINS) {
 		snd_printk(KERN_WARNING

@@ -919,6 +923,12 @@ static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
 		return -E2BIG;
 	}
 
+	err = snd_hda_input_jack_add(codec, pin_nid,
+				     SND_JACK_VIDEOOUT, NULL);
+	if (err < 0)
+		return err;
+	snd_hda_input_jack_report(codec, pin_nid);
+
 	hdmi_present_sense(codec, pin_nid, &spec->sink_eld[spec->num_pins]);
 
 	spec->pin[spec->num_pins] = pin_nid;

@@ -1120,6 +1130,7 @@ static void generic_hdmi_free(struct hda_codec *codec)
 
 	for (i = 0; i < spec->num_pins; i++)
 		snd_hda_eld_proc_free(codec, &spec->sink_eld[i]);
+	snd_hda_input_jack_free(codec);
 
 	kfree(spec);
 }

Signature · 1 line

1.7.4.1

I'm working on the driver for the dmx 6fire usb. ...
since Ubuntu 11.04, I get complaints about the card not working anymore,

Quoted 2 lines · Torsten Schenk

I'm working on the driver for the dmx 6fire usb. ...
since Ubuntu 11.04, I get complaints about the card not working anymore,

I'd guess that would be commit 82d90313980b:

| ALSA: USB: 6fire: signedness bug in usb6fire_pcm_prepare() 
| 
| rt->rate is an unsigned char so it's never equal to -1. It's not a huge 
| problem because the invalid rate is caught inside the call to 
| usb6fire_pcm_set_rate() which returns -EINVAL. But if we fix the test 
| then it prints out the correct error message so that's good. 
| 
| Signed-off-by: Dan Carpenter  
| 
| --- a/sound/usb/6fire/pcm.c 
| +++ b/sound/usb/6fire/pcm.c 
| @@ -493,13 +493,12 @@ static int usb6fire_pcm_prepare(struct snd_pcm_substream *alsa_sub) 
|     sub->period_off = 0; 
| 
|     if (rt->stream_state == STREAM_DISABLED) { 
| -        rt->rate = -1; 
|         for (i = 0; i < ARRAY_SIZE(rates); i++) 
|             if (alsa_rt->rate == rates[i]) { 
|                 rt->rate = i; 
|                 break; 
|             } 
| -        if (rt->rate == -1) { 
| +        if (i == ARRAY_SIZE(rates)) { 
|             mutex_unlock(&rt->stream_mutex); 
|             snd_printk("invalid rate %d in prepare.", 
|                     alsa_rt->rate); 

This fixed not a bug but just a symptom of the actual bug, that rt->rate is not signed.

There are still "rt->rate = -1" initializations, and usb6fire_pcm_open() then does:

    if (rt->rate >= 0)
        alsa_rt->hw.rates = rates_alsaid[rt->rate];

Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

That did the job indeed. I still wonder why it worked in so many cases... However, I will soon create a patch and submit it.

At Thu, 19 May 2011 11:55:21 +0200,

Quoted 5 lines · David Henningsson

Quoted 3 lines · Takashi Iwai

At Tue, 17 May 2011 15:46:43 +0200,

Quoted 1 line · David Henningsson

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

...

OK, as the jack report itself doesn't play a big role yet so far for HD-audio, let's get it in, and give pressure to graphics guys :)

Takashi Iwai wrote at Thursday, May 19, 2011 4:06 AM:

Quoted 7 lines

At Thu, 19 May 2011 11:55:21 +0200,

Quoted 5 lines · David Henningsson

Quoted 3 lines · Takashi Iwai

At Tue, 17 May 2011 15:46:43 +0200,

Quoted 1 line · David Henningsson

Quoted 7 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

...

OK, as the jack report itself doesn't play a big role yet so far for HD-audio, let's get it in, and give pressure to graphics guys :)

I've been testing a preliminary fix for this internally. I found that the /proc ELD files correctly report monitor_present and eld_valid when we hot unplug a monitor, but the other fields in the ELD file are not cleared out to their default state. As best I can tell, this is an ALSA driver issue, since our display driver only fills in the other fields when ELDV==1.

Quoted 7 lines · Stephen Warren

...
I've been testing a preliminary fix for this internally. I found that the /proc ELD files correctly report monitor_present and eld_valid when we hot unplug a monitor, but the other fields in the ELD file are not cleared out to their default state. As best I can tell, this is an ALSA driver issue, since our display driver only fills in the other fields when ELDV==1.

Then it's just showing stale data. The eld fields are updated only when the data is valid. The patch below should fix the confusion.

---

sound/pci/hda/hda_eld.c +2 -0

index 74b0560..cd96b1d 100644
@@ -477,6 +477,8 @@ static void hdmi_print_eld_info(struct snd_info_entry
 *entry,
 
 	snd_iprintf(buffer, "monitor_present\t\t%d\n", e->monitor_present);
 	snd_iprintf(buffer, "eld_valid\t\t%d\n", e->eld_valid);
+	if (!e->eld_valid)
+		return;
 	snd_iprintf(buffer, "monitor_name\t\t%s\n", e->monitor_name);
 	snd_iprintf(buffer, "connection_type\t\t%s\n",

eld_connection_type_names[e->conn_type]);

Takashi Iwai wrote at Monday, May 23, 2011 11:40 PM:

Quoted 26 lines

Quoted 7 lines · Stephen Warren

...
I've been testing a preliminary fix for this internally. I found that the /proc ELD files correctly report monitor_present and eld_valid when we hot unplug a monitor, but the other fields in the ELD file are not cleared out to their default state. As best I can tell, this is an ALSA driver issue, since our display driver only fills in the other fields when ELDV==1.

Then it's just showing stale data. The eld fields are updated only when the data is valid. The patch below should fix the confusion.

---

sound/pci/hda/hda_eld.c +2 -0

index 74b0560..cd96b1d 100644
@@ -477,6 +477,8 @@ static void hdmi_print_eld_info(struct snd_info_entry
 *entry,
 
 	snd_iprintf(buffer, "monitor_present\t\t%d\n", e->monitor_present);
 	snd_iprintf(buffer, "eld_valid\t\t%d\n", e->eld_valid);
+	if (!e->eld_valid)
+		return;
 	snd_iprintf(buffer, "monitor_name\t\t%s\n", e->monitor_name);
 	snd_iprintf(buffer, "connection_type\t\t%s\n",

Quoted 1 line

eld_connection_type_names[e->conn_type]);

Takashi,

Your patch looks fine as far as the reporting side goes.

Should we also modify hdmi_intrinsic_event() as follows:

	if (pind && eldv) {
		hdmi_get_show_eld(codec, spec->pin[index],
				  &spec->sink_eld[index]);
		/* TODO: do real things about ELD */
	}

(quoted diff) +3 -0

+	else {
+		memset(&spec->sink_eld[index], 0, sizeof(spec->sink_eld[index]));
+	}

... to make sure that if something accidentally uses the ELD data without checking eld_valid, it'll get obviously bad data instead of valid-looking-but-stale data? Right now, this isn't an issue, but if we start pushing the ELD into user-space through a binary control, it'd be nice if the ELD content were consistent in this way.

Hmm. Actually, hdmi_eld isn't storing the raw ELD bytes, but a parsed representation of them, so this may not be entirely relevant.

Quoted 9 lines

Takashi Iwai wrote at Monday, May 23, 2011 11:40 PM:

Quoted 8 lines

---

sound/pci/hda/hda_eld.c +0 -0

index 74b0560..cd96b1d 100644
@@ -477,6 +477,8 @@ static void hdmi_print_eld_info(struct snd_info_entry
 *entry,
 

Quoted 7 lines

Quoted 7 lines

sound/pci/hda/hda_eld.c +2 -0

 	snd_iprintf(buffer, "monitor_present\t\t%d\n", e->monitor_present);
 	snd_iprintf(buffer, "eld_valid\t\t%d\n", e->eld_valid);
+	if (!e->eld_valid)
+		return;
 	snd_iprintf(buffer, "monitor_name\t\t%s\n", e->monitor_name);
 	snd_iprintf(buffer, "connection_type\t\t%s\n",

eld_connection_type_names[e->conn_type]);

---

sound/pci/hda/patch_hdmi.c +1 -0

index 3229018..4dbe8d6 100644
@@ -707,6 +707,7 @@ static void hdmi_intrinsic_event(struct hda_codec
 *codec, unsigned int res)
 	if (index < 0)
 		return;
 
+	memset(&spec->sink_eld[index], 0, sizeof(spec->sink_eld[index]));
 	if (spec->old_pin_detect) {
 		if (pind)

hdmi_present_sense(codec, tag, &spec->sink_eld[index]);

sound/pci/hda/hda_eld.c +0 -0

 	snd_iprintf(buffer, "monitor_name\t\t%s\n", e->monitor_name);
 	snd_iprintf(buffer, "connection_type\t\t%s\n",

eld_connection_type_names[e->conn_type]);

Quoted 5 lines

At Tue, 17 May 2011 15:46:43 +0200,

Quoted 3 lines · David Henningsson

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

...

To be honest; it's partially working, or rather it's working in the sense that it follows the eld proc file. It's also working in hda-emu.

I've tried it on one Nvidia (with binary drivers), and one Intel Graphics and well, and both seem to have the same problem essentially:
There is no hotplug event coming in (through hdmi_unsol_event) when a monitor is removed. But with this patch in perhaps the graphics driver writers will feel more motivated to fix it? :-)

Note that the hotplug event is not coming in when you actually plug the cable but when you detect displays and/or apply the monitor configuration change.

David Henningsson wrote at Thursday, May 19, 2011 3:55 AM:

Quoted 17 lines · Takashi Iwai

Quoted 5 lines

At Tue, 17 May 2011 15:46:43 +0200,

Quoted 3 lines · David Henningsson

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

...

To be honest; it's partially working, or rather it's working in the sense that it follows the eld proc file. It's also working in hda-emu.

I've tried it on one Nvidia (with binary drivers), and one Intel Graphics and well, and both seem to have the same problem essentially:
There is no hotplug event coming in (through hdmi_unsol_event) when a monitor is removed. But with this patch in perhaps the graphics driver writers will feel more motivated to fix it? :-)

Quoted 3 lines

Note that the hotplug event is not coming in when you actually plug the cable but when you detect displays and/or apply the monitor configuration change.

That's certainly the expected behavior of our drivers at present.

The ELD data and PD/ELDV bits are only updated when we perform a modeset operation, which only happens in response to an explicit user request, either with XRandR or through our nvidia-settings application.

I'm not sure if there's a standard that says what our driver's behavior should be or not; I could argue that the current behavior makes sense to some degree, so that if the user unplugs their monitor then replugs it, we don't end up reprogramming all the display hardware. If we did disable the HDMI output path when a monitor was unplugged, given that I think the idea is that new paths don't get auto-programmed by the X driver when a new device is plugged in, but instead wait until XRandR is used to configure them, in which case if we'd just turned off all the display outputs, how would the user configure the new one without being able to see the desktop?

(While this may or may not be ideal, I'm simply pointing this out to indicate this behavior doesn't indicate any issue with David's patch)

...
Ok, thanks. Just to clarify my current problem - if I start nvidia-settings, I'll find my current screen through DVI and an extra HDMI screen that is disabled. If I choose to enable this screen (by clicking Apply on the "X Server Display Information" tab), I get a hotplug event through patch_hdmi.c:hdmi_unsol_event, telling me that the monitor is now present. So far, that's what's expected. However, if I then disable that second HDMI screen and click Apply again, I *don't* get an hdmi_unsol_event telling me that the monitor is now not present. This seems inconsistent to me.

David Henningsson wrote at Thursday, May 19, 2011 4:45 PM:

Quoted 10 lines

...
Ok, thanks. Just to clarify my current problem - if I start nvidia-settings, I'll find my current screen through DVI and an extra HDMI screen that is disabled. If I choose to enable this screen (by clicking Apply on the "X Server Display Information" tab), I get a hotplug event through patch_hdmi.c:hdmi_unsol_event, telling me that the monitor is now present. So far, that's what's expected. However, if I then disable that second HDMI screen and click Apply again, I *don't* get an hdmi_unsol_event telling me that the monitor is now not present. This seems inconsistent to me.

OK, now that's definitely a bug. I'll file one internally.

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

David Henningsson wrote at Tuesday, May 17, 2011 7:47 AM:

Quoted 2 lines

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

Interesting. I was asked to look into this, but you beat me to it; thanks!

A couple questions though:

a) Is it possible to report more information alongside the plug events, such as ELD/EDID content? Or, is the idea that the kernel sends a plug event, and then user-space retrieves that information via some other API? I don't think there's an API to retrieve ELD information at present though right? Although certainly it'd make sense for that to be a completely separate patch.

b) We might discuss how to tie ALSA jacks/ports/PCMs to X displays in some way, so that we can represent to the user which specific active monitor is the one that supports audio (e.g. in a 2-head setup with both monitors connected over HDMI, yet only 1 monitor supports audio).

I note that the ELD data contains a port_id field, which might be usable for this purpose. Could this contain an xrandr value, or an NV-CTRL (NVIDIA's proprietary control protocol) display ID, or something similar?

Quoted 6 lines

a) Is it possible to report more information alongside the plug events, such as ELD/EDID content? Or, is the idea that the kernel sends a plug event, and then user-space retrieves that information via some other API? I don't think there's an API to retrieve ELD information at present though right? Although certainly it'd make sense for that to be a completely separate patch.

A simple approach would be adding a control element containing byte-array of ELD/EDID.

Quoted 8 lines

Quoted 7 lines

a) Is it possible to report more information alongside the plug events, such as ELD/EDID content? Or, is the idea that the kernel sends a plug event, and then user-space retrieves that information via some other API? I don't think there's an API to retrieve ELD information at present though right? Although certainly it'd make sense for that to be a completely separate patch.

Quoted 2 lines

A simple approach would be adding a control element containing byte-array of ELD/EDID.

Are there any examples of such controls? Or are we talking about a new kind of control?

We could really use this ELD information in PulseAudio now that the passthrough mode is in git master; for now the codecs supported by the receiver are hard-coded, not a very reliable solution...

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

a) Is it possible to report more information alongside the plug events, such as ELD/EDID content? Or, is the idea that the kernel sends a plug event, and then user-space retrieves that information via some other API? I don't think there's an API to retrieve ELD information at present though right? Although certainly it'd make sense for that to be a completely separate patch.

Quoted 5 lines

Quoted 2 lines

A simple approach would be adding a control element containing byte-array of ELD/EDID.

Are there any examples of such controls? Or are we talking about a new kind of control?

Look for SNDRV_CTL_ELEM_TYPE_BYTES.  Some codecs provide these.

Quoted 13 lines

Quoted 12 lines

Quoted 9 lines

Quoted 6 lines

a) Is it possible to report more information alongside the plug events, such as ELD/EDID content? Or, is the idea that the kernel sends a plug event, and then user-space retrieves that information via some other API? I don't think there's an API to retrieve ELD information at present though right? Although certainly it'd make sense for that to be a completely separate patch.

A simple approach would be adding a control element containing byte-array of ELD/EDID.

Are there any examples of such controls? Or are we talking about a new kind of control?

Quoted 1 line

Look for SNDRV_CTL_ELEM_TYPE_BYTES.  Some codecs provide these.

Thanks for the pointer. looks simple enough to expose the ELD bytes. This type of element can store up to 512 bytes, enough to store the ELD header+baseline fields (260 bytes tops). I don't think userspace would want to muck with vendor-specific information?

we may need an array of ELD controls in case there are several monitors. Not sure how to represent which one is actually used. The ELD is linked to a specific nid (node id), we'd need to link this to the audio device #?

Isn't the ELD limited to 256 bytes, since verb F2F has an 8-bit offset parameter?

I think it'd be a good idea to just dump the entire ELD out to user-space for future flexibility. It's trivial for user-space to ignore the vendor- specific data (since it's always after the standardized data).

Perhaps the vendor-specific data space could be useful for matching audio ports to X displays; there is a 64-bit Port_ID in the ELD that might be used for that, or we could define X/Linux/Unix as the vendor, and specify the format of the vendor-specific data in a way that defines this mapping.

That said, the internal APIs our graphics driver uses to write the ELD is currently limited to 96 bytes (the size of the standardized section of the ELD). I'm not sure yet if that's simply because 96 bytes was all that was needed, or if that also ended up being encoded as a HW design limitation.

...

Quoted 4 lines

Perhaps the vendor-specific data space could be useful for matching audio ports to X displays; there is a 64-bit Port_ID in the ELD that might be used for that, or we could define X/Linux/Unix as the vendor, and specify the format of the vendor-specific data in a way that defines this mapping.

Sounds complicated...The spec says this PortID field is "a ""canned"" field that would be populated through implementation specific mean of default programming before the graphic driver is loaded". Duh?

The standard "Monitor Name String" may be easier to use...

Quoted 5 lines

That said, the internal APIs our graphics driver uses to write the ELD is currently limited to 96 bytes (the size of the standardized section of the ELD). I'm not sure yet if that's simply because 96 bytes was all that was needed, or if that also ended up being encoded as a HW design limitation.

Looks like the max for ELDv2 is 80 bytes for the baseline+4 for the header.

Quoted 5 lines

Quoted 2 lines

A simple approach would be adding a control element containing byte-array of ELD/EDID.

Are there any examples of such controls? Or are we talking about a new kind of control?

Look for SNDRV_CTL_ELEM_TYPE_BYTES.  Some codecs provide these.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

A simple approach would be adding a control element containing byte-array of ELD/EDID.

Are there any examples of such controls? Or are we talking about a new kind of control?

Look for SNDRV_CTL_ELEM_TYPE_BYTES.  Some codecs provide these.

I started doing some work on this, adding a persistent 256-byte buffer to store the ELD data instead of dynamically allocating and freeing the buffer. I am kind of lost with the controls though, never looked at this part of ALSA before.
In all the HDA code, all controls have an IFACE_MIXER type, while all the code that uses ELEM_TYPE_BYTES the type is IFACE_PCM. Does this matter at all?

Likewise, there's a 'generic_hdmi_build_controls' routine in which I could add the ELD control, but it uses cvt structures. I think it would make more sense to relate ELD controls to pins, as done with the proc information.

static void hdmi_non_intrinsic_event(struct hda_codec *codec, unsigned int res)

sound/pci/hda/patch_hdmi.c +0 -0

@@ -919,6 +922,17 @@ static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
 		return -E2BIG;
 	}
 

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

I considered making additional SND_JACK_* constants for HDMI and Displayport instead of going with SND_JACK_VIDEOOUT, but it didn't seem worth the additions, and breakage of compiling with old kernels, etc. Let me know if you think otherwise and I'll prepare a second patch for that.

David Henningsson wrote at Tuesday, May 17, 2011 7:47 AM:

Quoted 8 lines

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

I considered making additional SND_JACK_* constants for HDMI and Displayport instead of going with SND_JACK_VIDEOOUT, but it didn't seem worth the additions, and breakage of compiling with old kernels, etc. Let me know if you think otherwise and I'll prepare a second patch for that.

One more thought on this:

Some of our older HW (MCP6x, MCP7x chipsets) doesn't support unsolicited responses, nor PD/ELDV/ELD data. If PulseAudio is updated to listen to these new jack events on kernels where the input files are present, that'll presumably cause it never to allow use of the HDMI sinks on those chipsets. I don't know if other vendors have this issue or not.

In that case, can we do one of:

* Not create the jack/input files at all.

* Immediately mark the jack as "present".

I assume the latter would be easier for user-space to deal with; it'd be more in line with the kernel abstracting HW differences.

Quoted 24 lines · Stephen Warren

David Henningsson wrote at Tuesday, May 17, 2011 7:47 AM:

Quoted 8 lines

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

I considered making additional SND_JACK_* constants for HDMI and Displayport instead of going with SND_JACK_VIDEOOUT, but it didn't seem worth the additions, and breakage of compiling with old kernels, etc. Let me know if you think otherwise and I'll prepare a second patch for that.

One more thought on this:

Some of our older HW (MCP6x, MCP7x chipsets) doesn't support unsolicited responses, nor PD/ELDV/ELD data. If PulseAudio is updated to listen to these new jack events on kernels where the input files are present, that'll presumably cause it never to allow use of the HDMI sinks on those chipsets. I don't know if other vendors have this issue or not.

In that case, can we do one of:

* Not create the jack/input files at all.

* Immediately mark the jack as "present".

Quoted 3 lines

I assume the latter would be easier for user-space to deal with; it'd be more in line with the kernel abstracting HW differences.

Ok, thanks for the input (no pun intended ;-) ). If they support presence detect, we could create a polling loop. Otherwise, don't create the jack.

Quoted 9 lines

David Henningsson wrote at Tuesday, May 17, 2011 7:47 AM:

Quoted 2 lines

Just as for headphones and microphone jacks, this patch adds reporting of HDMI jack status through the input layer.

Some of our older HW (MCP6x, MCP7x chipsets) doesn't support unsolicited responses, nor PD/ELDV/ELD data. If PulseAudio is updated to listen to these new jack events on kernels where the input files are present, that'll presumably cause it never to allow use of the HDMI sinks on those chipsets. I don't know if other vendors have this issue or not.

Ok, thanks for the input (no pun intended ;-) ). If they support presence detect, we could create a polling loop. Otherwise, don't create the jack.

Is this autodetectable or do we have to quirk it?