Created attachment 95061 [details] dmesg 3.13.4 (stock Arch kernel, booted with drm.debug=0xe) This time it's not a bug with a ThinkPad nor a docking station involved, even no laptop at all. But, again it's some DP vs. audio "issue". I have just set up my new desktop at home. It's a Haswell i7-4770 sitting on a Intel DH87RL board. A monitor (iiyama 27") is connected via DP. This monitor has a massive sound system of 2x2W speakers build in, which I tested (this bug report doesn't cover the audio quality). So, the audio output via DP to the monitor played and I just tested to mute the S/PDIF via alsamixer ... and the monitor turned off into standby, audio stoped. Blindly typing another 'm' to unmute the S/PDIF and the monitor turned back on and the audio playback proceeded. If I don't play audio and mute the S/PDIF, the monitor stays active/on. Until I start playing audio. I've attached a dmesg log (drm.debug=0xe) of a boot to the console, where I have played audio and muted the S/PDIF. Though, the log doesn't show anything after the login. There's a "[drm:ivb_err_int_handler], Pipe A FIFO underrun" at the end, but I don't think (...famous noob words) that this is related because I've "turned off" the monitor via muting during this boot a couple of times and this message doesn't show up. How can provide any useful debug logs for this issue? (I guess: build a kernel with alsa-debug options?)
CC Mengdong. Any ideas?
I think most people want be affected by this as they don't touch the S/PDIF directly. They may use something like pulseaudio in between. Even I may have to use it for volume control. This misbehaviour exists, but it's not a showstopper for me and I don't mind if you set and treat this bug as lowest-minor.
Hi Martin/Jani, Sorry for the late reply. I don't think this is an audio driver issue, because audio driver operations does not directly cause screen on/off. Screen on/off is controlled by Gfx driver. For Haswell, the display audio devices (controller + codec) share the same power well with display. So the audio verb excution, such as muting/unmuting S/PDIF can wake up the audio devices and the audio driver will request power from Graphic driver. When audio devcies are idle (in D3), the audio driver will notify gfx driver it does not need the power. That's all. And even if the gfx driver keeps the power well always on, it can still turn on/off the screen. It seems to me that some user space module binds ALSA S/PDIF mute control with screen on/off. Thanks Mengdong
(In reply to comment #3) > Hi Martin/Jani, > > Sorry for the late reply. No problem, as stated it's not a showstopper for me. (And I'm even worse with replies.) > I don't think this is an audio driver issue, because audio driver operations > does not directly cause screen on/off. Screen on/off is controlled by Gfx > driver. > > For Haswell, the display audio devices (controller + codec) share the same > power well with display. So the audio verb excution, such as muting/unmuting > S/PDIF can wake up the audio devices and the audio driver will request power > from Graphic driver. When audio devcies are idle (in D3), the audio driver > will notify gfx driver it does not need the power. That's all. And even if > the gfx driver keeps the power well always on, it can still turn on/off the > screen. > > It seems to me that some user space module binds ALSA S/PDIF mute control > with screen on/off. What do you mean by "user space module", some ALSA module configured with alsa.conf and friends? The only ALSA configuration I set is to choose the card with S/PDIF as default. I'll remove it for testing and may temporarily remove system provided ALSA configurations as well. Everything else is as bare as a fresh Archlinux installs it, using slim for login and spectrwm as WM. So, no fency hidden stuff should happen.
Hi Martin, Could you raise the question to ALSA mailiing list alsa-devel@alsa-project.org? I'm not sure about user space behavior. Maybe someone on the mailist list could share more information. Thanks Mengdong
Created attachment 96246 [details] alsa-info.log (v3.13.6) Output of alsa-util-alsa-info.sh.
(In reply to comment #5) > Could you raise the question to ALSA mailiing list > alsa-devel@alsa-project.org? > > I'm not sure about user space behavior. > Maybe someone on the mailist list could share more information. Done and Takashi Iwai replied: It's an issue of Haswell graphics side. From the audio POV, it merely turns on/off the IEC958 status bits in the HDMI audio codec. http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074707.html
Please re-test with current drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel
Hoping this is fixed now. Daniel, if not, please re-open. But we've made changes to the audio well handling and lots of other things since March, so hopefully this is resolved too.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.