All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
	Takashi Iwai <tiwai@suse.de>
Cc: Anssi Hannula <anssi.hannula@iki.fi>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: Radeon unconnected HDMI eats samples at 280 kHz
Date: Tue, 30 Sep 2014 14:24:46 +0200	[thread overview]
Message-ID: <542AA10E.8090209@canonical.com> (raw)
In-Reply-To: <A3397C8B8B789E45844E7EC5DEAD89D05992C6FA@satlexdag05.amd.com>



On 2014-09-24 23:37, Deucher, Alexander wrote:
>> But it makes sense that the audio is turned off when the video is, right?
>
> It's a bit complicated.  X effectively just blanks (dpms off) the display when you disconnect it or xrandr --off.  The resources are not actually reclaimed and "disabled" until the next modeset.  I don't think we really want to turn audio off when the display goes into dpms as that will be reported as a disconnect on the audio side even if the display has just gone to sleep.
>
>>
>> Because if first unplug HDMI (nothing happens) and then run "xrandr"
>> (without parameters), running that command causes a "re-detection" or
>> whatever the correct term is - i e, my DVI screen goes black for a
>> second, and afterwards the mouse pointer can no longer move to the other
>> non-existent display.
>> At that point, audio still remains in the "plugged in" state. Also,
>> executing "xrandr --output HDMI-0 --off" has no effect in that state.
>>
>
> The problem is, X just puts the display to sleep when you unplug or xrandr --off.  The current KMS API doesn't really have a notion of "disable".  The actual disabling happens at the next modeset when displays that are no longer in use are disabled and their resources are freed for possible use in the upcoming modeset.  Forcing another modeset with the hdmi disconnected should get the status updated properly.

I'm not sure how to force a modeset, but just for comparison and for the 
desire of consistency, I did the same test with a laptop with an Intel 
built-in card.

In this case, both plug-in and unplug are responded to immediately on 
both sides, so when the cable is unplugged, the video does a 
"re-detection" which disables the HDMI display, and the audio side 
reports unplugged as well.

Also, executing "xrandr --output HDMI1 --off" while the cable is plugged 
causes the audio side to report unplugged.

I think this behaviour makes sense, but I'm not sure my rank is high 
enough to dictate behaviour. :-)

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

  reply	other threads:[~2014-09-30 12:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-17 13:40 Radeon unconnected HDMI eats samples at 280 kHz David Henningsson
2014-09-17 21:26 ` Anssi Hannula
2014-09-18  4:13   ` David Henningsson
2014-09-18  7:33     ` Takashi Iwai
2014-09-18  7:54       ` David Henningsson
2014-09-18 22:29         ` Deucher, Alexander
2014-09-19 13:38           ` David Henningsson
2014-09-19 14:14             ` Deucher, Alexander
2014-09-19 17:47               ` David Henningsson
2014-09-19 18:19                 ` Alexander E. Patrakov
2014-09-19 23:35                   ` David Henningsson
2014-09-20  9:37                     ` Anssi Hannula
2014-09-20  9:39                     ` Alexander E. Patrakov
2014-09-19 23:32                 ` Deucher, Alexander
2014-09-20  0:06                   ` David Henningsson
2014-09-20  9:31                     ` Alexander E. Patrakov
2014-09-22 12:46                     ` Deucher, Alexander
2014-09-22 14:39                       ` David Henningsson
2014-09-22 14:52                         ` Deucher, Alexander
2014-09-23  9:47                           ` David Henningsson
2014-09-23 14:07                             ` Deucher, Alexander
2014-09-24  9:27                               ` David Henningsson
2014-09-24 21:37                                 ` Deucher, Alexander
2014-09-30 12:24                                   ` David Henningsson [this message]
2014-09-30 12:45                                     ` Deucher, Alexander

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=542AA10E.8090209@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=anssi.hannula@iki.fi \
    --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.