On Wed, Nov 2, 2011 at 2:35 AM, Paul Menzel <paulepan...@users.sourceforge.net> wrote: > Dear Sander, > > > Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen: >> On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang <fengguang...@intel.com> wrote: > >> >> The log does confirm that the drm_edid_to_eld function is running, and >> >> that we're not far from a solution: >> >> [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607 >> >> [ 21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8 >> > >> > It looks all sane to this point. >> > >> >> As for where I am getting the EDID dump from, I am getting it from >> >> /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-2/edid, >> >> which provides direct virtual access to the EDID response of the >> >> connected device. >> >> >> >> I'm completely confident that the device doesn't report too small of a >> >> buffer size, and that it's completely compliant with the spec: If you >> > >> > Agreed. >> > >> >> have a Windows virtual machine (or if you're masochistic enough - a real >> >> machine) you should download the excellent, free "Monitor Asset Manager" >> >> by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It >> >> will let you analyze EDID + ELD + extended timings, etc from an EDID >> >> dump, such as the one taken above. It understands every part of EDID. >> >> >> >> I've put together a small archive containing my exact EDID binary dump >> >> (taken from the above device path), the FULL dmesg log, as well as >> >> EnTech's interpretation of the EDID dump, showing the full list of >> >> supported channels, formats, etc. >> >> >> >> I'm guessing there is some tiny bug in your interpretation of how to >> >> read ELD, maybe an incorrect 1 byte offset or something like that. >> >> >> >> Here's the pack: >> >> http://www.pulseforce.com/node/edid_to_eld.zip >> > >> > Thanks! It's great tool and information! >> > >> >> If you do a hex analysis of my EDID dump and compare it to what the >> >> edid_to_eld function is trying to do, it will probably show what's >> >> wrong. I'd love to have a look at that myself but am really busy with a >> >> project over here so I can't help out other than to recompile and test >> >> as fast as I can. >> > >> > Would you install the "intel-gpu-tools" package and run its >> > intel_audio_dump utility? If not shipped with your distribution, the >> > source code is also available in >> > >> > git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools >> > >> > You'll need to install packages "autotools-dev pkg-config >> > libpciaccess-dev libdrm-dev libdrm-intel1" in order to build it from >> > source. >> > >> > intel_audio_dump will dump the ELD data in the hardware buffer for use >> > by the audio driver. By verifying if that data is correct, we are able >> > to analyze whether and how the audio driver goes wrong. >> > >> >> I think I experience similar issues. In my case the multi-channel pcm >> playback through HDMI doesn't work. Stereo and passthrough seem to >> work fine though !? It's hookedup to my TV via a yamaha receiver. >> >> I'm currently running Linux 3.1 with a G45 chipset. >> >> libdrm 2.4.27-1 >> xf86-video-intel 2.16.0-1 > > do you have Fengguang’s patch applied? This thread is about testing that > patch. > >> The eld seems be incorrectly parsed, though the kernel log didn't give >> much info. The eld info from alsa is rather empty: >> >> cat /proc/asound/Intel/eld#3.0 >> monitor_present 1 >> eld_valid 0 >> >> Using the same Monitor Asset Manager I was able to verify that the edid from >> (/sys/devices/pci0000\:00/0000\:00\:02.0/drm/card0/card0-HDMI-A-1/edid >> ) does seem to contain the correct information. >> >> I've attached both the edid and the output of Monitor Asset Manager.In >> addition I also run the intel_audio_dump. >> >> Let me know if you need anymore information. > > It would be great if you could test the patch.
Ah, that explains. I was under the impression this was already in 3.1 (but then again, it was rather late for me :) ) I will give the patch a try and report back. . Thanks, Sander _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
