Created attachment 90004 [details] Dmesg output I've been working with some of the openelec guys to try and resolve this to no avail, they suggested I come post a bug report here. First of all, this is what I'm seeing: http://www.youtube.com/watch?v=wTbucvaRt_I My hardware is as follows: Home theater computer (intel i3 3225 with asus p8875-m motherboard) connected to my AVR (Denon AVR 1913) which is then connected to my samsung tv (un46d6000) I've tried swapping hdmi cables. If I use a different media source (amd fusion e350) everything works flawlessly. If I remove the AVR and connect either intel or amd machines directly to the tv everything works correctly.
Created attachment 90005 [details] xrandr output
I think what would be a good starting point would be xrandr --verbose and intel_reg_dumper from the both setups (i.e. directly connected to the TV and via the AVR). My first thought is a modesetting issue where we are generating underruns to the AVR - or that we are not accounting for audio bandwidth, or the like.
Created attachment 90026 [details] xrandr output with AVR
Created attachment 90027 [details] reg dumper output with AVR
Created attachment 90028 [details] xrandr no AVR
Created attachment 90029 [details] reg dump no AVR
Hmm, the AVR does present a different EDID than the TV, but the current mode appears to be identical. So not sure, I guess we need to inspect the kernel debug for underruns.
Are there any particular debug flags that are needed?
Booting with drm.debug=0xe is all that's needed. Then hunt for fifo underrun reports in dmesg (it'll be oneshot per modeset to avoid flooding logs).
Created attachment 90179 [details] dmesg with drm.debug=0xe When I rebooted the machine with that debug flag my speakers started crackling rather audibly, regardless of the volume control on the receiver.
There's an HDMI audio clock fix that might be relevant: commit 1a91510dc3b8098930ebda3018f5cd72e8428243 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Oct 16 12:34:48 2013 +0300 drm/i915: set HDMI pixel clock in audio configuration The reported failures this fixes have been in audio, but please try v3.13-rc2 or backport the commit to your kernel in case this fixes audio caused FIFO underruns too.
Just gave kernel 3.13.0-rc2 a whirl, my issue is not resolved in it.
I did some further testing with fritsch from #openelec today and it seems everything works fine in modes less than or equal to 1080p30, even on older kernel versions. However 1080p60 results in the flickering as before (even using 3.13.6 rc builds). Any thoughts on how to proceed?
I just connected my Windows 8 desktop (Haswell i7 4770) to my AVR and everything worked correctly at 1080p60, under windows.
Created attachment 91393 [details] drm.debug=0xe linux 3.13-rc6 Here's a debug log I just grabbed from rc6, symptoms persists.
Timeout, please re-test using a recent kernel.
Are you kidding me right now? I've been ignored for the better part of a year and have moved onto superior hardware that actually works. I'm not wasting any more of my time with you.
Brad, I'm sorry we failed to solve the issue.
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.