All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: Takashi Iwai <tiwai@suse.de>,
	ALSA Development Mailing List <alsa-devel@alsa-project.org>
Subject: Re: [PATCH] ALSA: HDA: Add jack detection for HDMI
Date: Fri, 20 May 2011 00:45:18 +0200	[thread overview]
Message-ID: <4DD59D7E.7040307@canonical.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0498A47BE9@HQMAIL01.nvidia.com>

On 2011-05-19 18:57, Stephen Warren wrote:
> David Henningsson wrote at Thursday, May 19, 2011 3:55 AM:
>> On 2011-05-17 17:46, Takashi Iwai wrote:
>>> At Tue, 17 May 2011 15:46:43 +0200,
>>> David Henningsson wrote:
>>>>
>>>> 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.
>
> 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, Canonical Ltd.
http://launchpad.net/~diwic

  reply	other threads:[~2011-05-19 22:45 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 13:46 [PATCH] ALSA: HDA: Add jack detection for HDMI David Henningsson
2011-05-17 15:46 ` Takashi Iwai
2011-05-19  9:55   ` David Henningsson
2011-05-19 10:06     ` Takashi Iwai
2011-05-19 10:24       ` Setting invalid samplerate Torsten Schenk
2011-05-19 10:32         ` Torsten Schenk
2011-05-19 10:55         ` Clemens Ladisch
2011-05-19 11:28           ` Torsten Schenk
2011-05-19 11:36             ` Daniel Mack
2011-05-23 21:49       ` [PATCH] ALSA: HDA: Add jack detection for HDMI Stephen Warren
2011-05-24  5:39         ` Takashi Iwai
2011-05-24 17:27           ` Stephen Warren
2011-05-24 18:09             ` Takashi Iwai
2011-05-24 19:18               ` Stephen Warren
2011-05-24 21:00           ` Stephen Warren
2011-05-19 16:57     ` Stephen Warren
2011-05-19 22:45       ` David Henningsson [this message]
2011-05-19 22:51         ` Stephen Warren
2011-06-09 20:59           ` Stephen Warren
2011-05-17 16:00 ` Stephen Warren
2011-05-17 16:08   ` Takashi Iwai
2011-05-17 17:09     ` pl bossart
2011-05-17 17:31       ` Takashi Iwai
2011-05-17 20:51         ` pl bossart
2011-05-17 21:42           ` Stephen Warren
2011-05-17 22:11             ` pl bossart
2011-05-17 23:14               ` Stephen Warren
2011-05-18 15:43         ` pl bossart
2011-05-18 15:49           ` Takashi Iwai
2011-05-18 10:02 ` Takashi Iwai
2011-05-20 21:59 ` Stephen Warren
2011-05-21  6:25   ` David Henningsson
2011-05-21  7:37     ` Takashi Iwai
2011-05-23 15:29     ` Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DD59D7E.7040307@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=swarren@nvidia.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.