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. Thanks, Paul
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
