Created attachment 68010 [details] Xorg log file When I plug my Gateway laptop's HDMI output to a Sony Bravia LED TV (or any other TV), the TV screen shows no video, neither on boot nor on log in, and even though it's getting a signal, it shows an "incompatible signal" message no matter which mode is set by desktop. External monitor stays blank *unless* audio is played through HDMI either from media file or from system sound, then desktop momentarily appears on screen but as soon as sound stops, monitor gets back to blank state (incompatible signal). So the only way to use external monitor is to keep sending an audio signal through HDMI port. External monitor via HDMI used to work just fine under kernel branch 3.0, only issue was this branch doesn't have intel backlight patch. HDMI output stopped working nice from kernel 3.2 onwards. Only workaround is to open a flash player in web browser and desktop will show up as long as flash player is kept open even if paused. -System environment: Chipset: 965GM System architecture: x86_64 xf86-video-intel: 2.19.0 xserver: 1.12.1.902 mesa: 8.0.3 libdrm: 2.4.33 kernel: 3.2.0-3-amd64 Linux distribution: LMDE UP5 Machine model: Gateway M-6804m Display connector: HDMI -Reproducing steps: 1. Plug HDMI connector to external monitor (TV) 2. TV screen is blank, says incompatible signal 3. Play a sound via HDMI port 4. TV screen shows desktop 5. Sound stops playing 6. TV screen gets blank again -Additional info: ·Same behavior on any digital TV/external monitor ·Started somewhere between branches 3.0 and 3.2 ·Internal monitor has no problem. ·All log files with TV plugged to laptop ·Tested kernels: a) Work OK: 3.0.24 b) Don't work: 3.2.30, 3.4.11, 3.5.4, 3.6-rc7
Created attachment 68012 [details] dmesg output
Created attachment 68013 [details] intel_reg_dumper output
Created attachment 68014 [details] VBIOS dump
Can you please attach dmesg with drm.debug=0xe added to your kernel cmdline?
Created attachment 68067 [details] dmesg with drm.debug=0xe
I've quickly looked through the relevant sdvo/hdmi commits between 3.0 and 3.2 and couldn't find anything that would explain this. Can you please attempt to bisect this regression?
Of course, as soon as I have some time. I'm still learning to git-bisect and I have yet to find the exact kernel version which introduced the regression for the first time.
Confirmed, this regression started right in kernel 3.1.0, so I started to git-bisect like this: [good] v3.0.44 [bad] v3.1 I'll report back the results as soon as the bisecting process finishes.
Created attachment 68467 [details] Bad commit, full description I've finally found the culprit, according to git-bisect this is the bad commit: 384a48d71520ca569a63f1e61e51a538bedb16df is the first bad commit commit 384a48d71520ca569a63f1e61e51a538bedb16df Author: Stephen Warren <swarren@nvidia.com> Date: Wed Jun 1 11:14:21 2011 -0600 ALSA: hda: HDMI: Support codecs with fewer cvts than pins Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> So it's not a drm/i915 related issue but an alsa/hda related one. Regressions concerning this commit were reported, but none of the reports describe the same behavior as my machine's. Should I submit a new bug report?
Created attachment 68468 [details] git bisect log output
Comment on attachment 68012 [details] dmesg output Made obsolete by dmesg with drm.debug=0xe
Created attachment 68767 [details] [review] clear the entire infoframe buffer Can you please test this patch?
Patch tested on clone of Linus' kernel tree (v3.7.0-rc2). It didn't work, there is still the same odd behavior: no video on external monitor except when an application plays audio via HDMI. Let me know if you need extra info.
Takashi, do you have any ideas about this?
Hmm.... It's obviously a change only to HD-audio codec, and I see no link how it affects the video output. Maybe the SVDO HDMI is enabled only when the audio codec's pin is turned on by some reason? The recent HD-audio HDMI driver sets the audio pin only when used. If this is the case, try the following: - get hda-verb program (described in Documentation/sound/alsa/HD-Audio.txt) - build the kernel with CONFIG_SND_HDA_HWDEP=y - check the codec number of HDMI codecs; you can find /proc/asound/card*/codec#* files, and one of them must contain "HDMI" codec name. The number after '#' is the codec address. - Check "Pin" widget nodes. The codec#* proc file contains the list of widgets, and some of them must be pin widgets, e.g. 0x03. - Run the command to each pin widget like below: hda-verb /dev/snd/hwC0D3 0x03 SET_PIN_WID 0x40 where /dev/snd/hwC0D3 is the hwdep device corresponding to card0/codec#3. The second argument (0x03) is the pin widget NID to apply.
Or if you prefer patching the kernel, try the patch below. It stopped flickering on another machine, at least. https://bugzilla.kernel.org/show_bug.cgi?id=51421
Created attachment 71493 [details] [review] Patch to set HDMI audio pins on constantly
(In reply to comment #15) > Hmm.... It's obviously a change only to HD-audio codec, and I see no link > how it affects the video output. > > Maybe the SVDO HDMI is enabled only when the audio codec's pin is turned on > by some reason? The recent HD-audio HDMI driver sets the audio pin only > when used. > > If this is the case, try the following: > > - get hda-verb program (described in Documentation/sound/alsa/HD-Audio.txt) > > - build the kernel with CONFIG_SND_HDA_HWDEP=y > > - check the codec number of HDMI codecs; you can find > /proc/asound/card*/codec#* files, and one of them must contain "HDMI" codec > name. The number after '#' is the codec address. > > - Check "Pin" widget nodes. The codec#* proc file contains the list of > widgets, and some of them must be pin widgets, e.g. 0x03. > > - Run the command to each pin widget like below: > hda-verb /dev/snd/hwC0D3 0x03 SET_PIN_WID 0x40 > > where /dev/snd/hwC0D3 is the hwdep device corresponding to card0/codec#3. > The second argument (0x03) is the pin widget NID to apply. Finally, it worked! I ran the command hda-verb /dev/snd/hwC0D2 0x03 SET_PIN_WID 0x40 and that solved the problem, and I suppose the patch to set pins on should also work. Thank you so much, Takashi. Will that patch be committed in future kernel releases? Or will patching kernel be needed every time a new one is released in order to make the fix permanent? Regards, Charles.
Good to hear. The patch was already queued to sound git tree, and will be included in 3.8-rc1 in this week. Then it'll be eventually backported to stable kernels.
Takashi, can you please add a git commit citation here for the sound patch and close the bug? Thanks, Daniel
The commit ID is included in the attached patch :) commit 6169b673618bf0b2518ce413b54925782a603f06 Author: Takashi Iwai <tiwai@suse.de> Date: Fri Dec 14 10:22:35 2012 +0100 ALSA: hda - Always turn on pins for HDMI/DP
On Tue, Dec 18, 2012 at 12:00 PM, <bugzilla-daemon@freedesktop.org> wrote: > --- Comment #21 from Takashi Iwai <tiwai@suse.de> --- > The commit ID is included in the attached patch :) Ah, didn't notice that it's the patch which goes upstream - usually I attach random patches from random trees, so the sha1 will be totally different when merged. Thanks, Daniel
It's good to know the patch will be backported to stable kernels in the future. Thanks to you all guys for helping to solve this issue. Regards, Charles.
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.