[alsa-devel] [PATCH 2/2] ALSA: hda - hdmi: Set infoframe and channel mapping even without sink

[Takashi Iwai]

At Mon, 05 May 2014 17:48:04 +0300,
Anssi Hannula wrote:
> 
> Takashi Iwai kirjoitti 2014-05-05 17:34:
> > At Mon,  5 May 2014 02:38:44 +0300,
> > Anssi Hannula wrote:
> >> 
> >> Currently infoframe contents and channel mapping are only set when a
> >> sink (monitor) is present.
> >> 
> >> However, this does not make much sense, since
> >> 1) We can make a very reasonable guess on CA after 18e391862c ("ALSA:
> >>    hda - hdmi: Fallback to ALSA allocation when selecting CA") or by
> >>    relying on a previously valid ELD (or we may be using a
> >>    user-specified channel map).
> >> 2) Not setting infoframe contents and channel count simply means they
> >>    are left at a possibly incorrect state - playback is still allowed
> >>    to proceed (with missing or wrongly mapped channels).
> >> 
> >> Reasons for monitor_present being 0 include disconnected cable, video
> >> driver issues, or codec not being spec-compliant. Note that in
> >> actual disconnected-cable case it should not matter if these settings
> >> are wrong as they will be re-set after jack detection, though.
> >> 
> >> Change the behavior to allow the infoframe contents and the channel
> >> mapping to be set even without a sink/monitor, either based on the
> >> previous valid ELD contents, if any, or based on sensible defaults
> >> (standard channel layouts or provided custom map, sink type HDMI).
> >> 
> >> Signed-off-by: Anssi Hannula <anssi.hannula at iki.fi>
> >> Tested-by: Stephan Raue <stephan at openelec.tv>
> >> ---
> >> 
> >> This simply removes the monitor_present check, which is probably more
> >> trouble than it is worth, as it may trip obscure setups even though we
> >> can tolerate !monitor_present and !eld in 99%+ of all cases by using
> >> defaults, nowadays post-18e391862c anyway.
> >> Downside is that missing monitor_present may not be noticed by the 
> >> user
> >> as ~everything continues to work.
> > 
> > Is this considered as a "fix" for 3.15 kernel?  If so, I find it a bit
> > distracting to queue the previous patch for stable while we're
> > removing the whole things here later.
> > 
> > If this is intended for testing for 3.16 kernel, I'm fine to take as
> > is.
> 
> Well, I intended it for 3.16, since I don't have anything concrete that 
> it
> would fix that the previous AFAICS safer patch did not (for now, at 
> least...).
> 
> Sorry for not making it explicit.

Alright, I applied both, one to for-linus and another to for-next
branches.  Thanks.


Takashi