| Summary: | [snb regression] TV reports "Unsupported signal" when power-cycling | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Matt Horan <matt> |
| Component: | DRM/Intel | Assignee: | Paulo Zanoni <przanoni> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | ben, chris, daniel, jbarnes, przanoni |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
Created attachment 64492 [details]
dmesg from power-cycling receiver only
Created attachment 64493 [details]
dmesg from power-cycling TV only
Note that the mode can be recovered with a manual "xrandr --output HDMI1 --off; xrandr --output HDMI --preferred" after powercycling the TV and receiver. A few things: - hdmi infoframe support is known-broken up to at least 3.4. Please test with that (an preferrably 3.5 even). - dmesg is cut off, can you please attach a full dmesg (you can increase the dmesg buffer with log_buf_size=4m on the kernel cmdline). - I've closed bug #43947 again, imo it's better to track everything here (and I suspect it's all due to the totally broken infoframe support in 3.2). - In your comment on bug #43947 you've mentioned that "this patch" breaks things for your. Can you please specify exactly which patch/commit you mean and how things broke? - Also, did the same commit that broke audio also break the video signal, i.e. resulted in "Unsuppported signal" on your TV screen? I just compiled and tested 3.5, and the "Unsupported signal" issue persists. Regarding bug 43947, commit c1230df7e19e0f27655c0eb9d966c7e03be7cc50 caused an issue where if the TV or receiver were power-cycled, audio would not resume. Reverting this commit caused this issue to go away. This issue seems to be resolved in 3.5. The bisect revealed that the patch from bug 40281, commit 64a8fc0145a1d0fdc25fc9367c2e6c621955fb3b, was ultimately responsible for these issues. Both the "Unsupported video" and sound not resuming after power-cycle were introduced with this commit. I was experiencing an additional issue where the TV would flash every 5 seconds if there was no audio signal on the HDMI link, but this seems to be resolved in 3.5. Created attachment 64502 [details]
non-truncated dmesg (power-cycled both TV and receiver)
Hi I'm still trying to understand what exactly you are trying to say. Are you saying that this commit: http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=c1230df7e19e0f27655c0eb9d966c7e03be7cc50 causes a regression on SNB? SNB does not run that code... That commit shouldn't be causing regressions on SNB :( I'm still trying to understand what exactly is the problem that you're seeing on Kernel 3.5 and when it started... While you're at it, can you please run "./intel_infoframes -d" from-intel-gpu-tools and paste its output here? Just running this tool can sometimes fix some bugs... Reproduce the bug on your system, run the tool, check if the problem gets solved after you run the tool, paste its output here. Thank you, Paulo Paulo - It's possible that it just a fluke that the audio regression was detected when reverting http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=c1230df7e19e0f27655c0eb9d966c7e03be7cc5, however I ran the failing scenario a few times with consistent results. However, the ultimate source of regressions was http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=64a8fc0145a1d0fdc25fc9367c2e6c621955fb3b. This commit caused my TV to display "Unsupported signal" when either the TV or receiver were power-cycled. The audio issue, however, did not seem to be present at this point. A third issue, where the display blinks every five seconds when there is no audio on the HDMI link, showed up at some point between c1230df7e19e0f27655c0eb9d966c7e03be7cc50 and 3.2. I've not found the ultimate source for the blinking screen, but Daniel Vetter recommended that I try out the drm-intel-next-queued branch, which resolved this issue. Despite my previous comment, 3.5 has this issue as well. The drm-intel-next-queued branch also resolves the "Unsupported signal" issue. The intermittent audio issue still persists, though it's not as severe. If I turn off either the TV or the receiver, sometimes audio will not playback after power-cycle, though the receiver detects a signal. I'm thinking the audio problems may be PulseAudio related, which means c1230df7e19e0f27655c0eb9d966c7e03be7cc5 would have nothing to do with the issue. If I restart PulseAudio, or power-cycle any device in the chain, audio returns. Daniel had recommended that I grab /sys/class/drm/card0-HDMI-A-2/edid in the working and broken states, but both are identical. The output of intel_infoframes is identical as well. Created attachment 64575 [details]
EDID from system in broken audio state
Created attachment 64576 [details]
infoframes from system in broken audio state
With the latest drm-intel-fixes atop v3.6-rc1, I'm only experiencing one outstanding, intermittent issue. Sometimes it is desirable to listen to music through the receiver without leaving the TV on. Sometimes this just works. However, most of the time the audio will cut out every once in a while while the TV is off. When this happens, shutting the TV off immediately results in audio cutting out, with a corresponding *ERROR* EDID checksum is invalid in the dmesg. If I run xrandr at this point, it does not return the expected modes. Audio will normally resume, but a few minutes later will cut out again. The checksum invalid will appear in dmesg, and then audio will resume. xrandr returns the same incorrect list of modes. If I turn the TV back on at this point, the desktop will usually extend slightly outside the viewable area of the TV. xrandr reports a different list of modes. I've grabbed an EDID dump from each of these states. extended.edid corresponds to the broken extended desktop state when the TV is turned on after the audio cutout. working.edid corresponds to the EDID in working state. tv_off.edid corresponds to the EDID when the TV is shut off but the receiver is on. In some cases, the EDID returned when the TV is off is identical to the working EDID. Audio does not cut out, and the desktop displays correctly when the TV is turned on. In other cases, the TV will first display in the extended state, but will then reset and display properly. xrandr reports the correct list of modes at this time. Created attachment 65318 [details]
EDID from system in working state
Created attachment 65319 [details]
EDID from desktop in extended display state
Created attachment 65320 [details]
EDID from system when TV is off
You remaining issue sounds like your receiver (or your TV) are somehow causing hotplug events every once a while. Every time this happens, we reconfigure the output pipeline (we also do the EDID read as a side-effect, which seems to reliably fail). I don't see anything we can do differently with the hotplug detection (we pretty much _need_ to react to hdmi hotplug events in this fashion), so until some evidence to the contrary pops up I'll mark this as a hw issue and close as wontfix. Thanks anyway for reporting this issue (and it looks like we've at least managed to fix the infoframe confusion for you). Closing resolved+wontfix. |
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.
Created attachment 64491 [details] dmesg from both receiver and TV power-cycled at the same time I'm running Linux 3.2.21 and Xorg 1.12.1.902 on a Sandy Bridge desktop (GT2) with a receiver between the desktop and the TV connected via HDMI. Between Linux 3.1 and 3.2, a regression caused "Unsupported signal" to be displayed on the TV when power-cycling either the TV or the receiver. I bisected the kernel and tracked down the issue to #40281. This change causes "Unsupported signal" to be displayed on the TV when either the TV or the receiver are power-cycled.