Comment # 16 on bug 916048 from
(In reply to Takashi Iwai from comment #15)
> The place you should look at isn't there.  The HDMI/DP on Intel oboard gives
> two PCI entries, one for graphics and one for audio, even though they are
> both on the same GPU.  The audio driver receives and handles the events only
> through the audio chip PCI.
> 
> There is /proc/asound/card*/eld*.* files, and you can check whether any of
> them changes while plugging/unplugging.  There can be multiple such files as
> the chip may have up to three ports.  Usually BIOS should disable unused
> ports, but some BIOS don't.
>  
> > I looked around a bit, and I found some tricks where a udev rule invokes a
> > script that then switches PulseAudio's output depending on the status of
> > HDMI connectivity in /sys. I tried it, and it does seem to work with one
> > problem. udev does not invoke the script when I plug the cable in (Despite
> > /sys indicating the status correctly), so I invoke the script manually and
> > it works. When I disconnect the cable, udev notices without a problem,
> > script is invoked, and sound is returned to the laptop speakers.
> 
> For the audio, it's not udev but it's the notification via ALSA control API.
> You can watch it via "alsactl monitor" command, for example.

This was really useful information, thanks! I checked the files in /proc that
you referred to, and one of them (Specifically /proc/asound/card0/eld#3.0) does
indeed change as soon as I plug the HDMI/DP cable in AND activate output to the
TV (The event does not occur before the image on the TV is showing), and it
changes again when I unplug the cable. "alsactl monitor" also consistently
reports this.

The udev rule I was using earlier is (As well as some variations, but basically
the same thing):
SUBSYSTEM=="drm", RUN+"/path/to/my/script"

Is it possible to make a rule that makes udev take a look at the audio status
in the manner you indicated? As I said, the file /proc/asound/card0/eld#3.0
gets correctly updated with the HDMI audio status when the HDMI output is
activated, so if udev could take a look at that, that would probably solve my
problem.


You are receiving this mail because: