[alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz

[Deucher, Alexander]

> -----Original Message-----
> From: David Henningsson [mailto:david.henningsson at canonical.com]
> Sent: Tuesday, September 30, 2014 8:25 AM
> To: Deucher, Alexander; Takashi Iwai
> Cc: Anssi Hannula; alsa-devel at alsa-project.org
> Subject: Re: [alsa-devel] Radeon unconnected HDMI eats samples at 280 kHz
> 
> 
> 
> 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. :-)

I agree.  It should be possible (barring figuring out what to do in the multiple-connected-HDMI case), but I don't have the cycles right now to do the necessary rework of the driver to move the audio enable/disable and speaker info fetch into the probe and hotplug code paths.

Alex