On 11/2/11 2:45 AM, Wu Fengguang wrote:
Hi Christopher,
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.
Thanks,
Fengguang
I've been really busy on a project (as mentioned in my last posting) and
apologize for the 2 day delay. The project is now done and no further
response delays will happen. Promise.
Alright, so first of all I am glad that you found the tool and
information useful.
Now, onto the intel-gpu-tools test. I ran intel_audio_dump as requested
and it only comes back with "Couldn't map MMIO region: No such file or
directory". I spent 10 minutes looking around on Google to no avail. It
seems it tries to mmap() something that doesn't exist.
I then spent some time looking in /var/log/Xorg.0.log to double-check
what driver it's using. It says:
"Matched intel as autoconfigured driver 0
Matched vesa as autoconfigured driver 1
Matched fbdev as autoconfigured driver 2
VESA: driver for VESA chipsets: vesa
FBDEV: driver for framebuffer: fbdev
Loading: /usr/lib/xorg/modules/drivers/intel_drv.so"
All in all it looks fine, at least as far as I can tell. I mean, we
already KNOW the driver has to be running since I see the DRM module in
the logs.
So, the Intel driver is running, yet whatever file intel_audio_dump is
looking for doesn't exist.
We already know that the DRM driver is reading the correct EDID, by the
way, since we saw "[ 21.061417] [drm:drm_edid_to_eld], ELD monitor
TX-SR607".
The EDID it's reading from is the dump I linked to in the previous posting.
To go the extra mile, I just looked at the xf86-video-intel source in
src/reg_dumper_util.c, which is where the "Couldn't map MMIO region"
message originated. I now see that it's not trying to mmap() a physical
file. It tries to map the graphics card's physical memory using
pci_device_map_range(dev, dev->regions[mmio_bar].base_addr,
dev->regions[mmio_bar].size, PCI_DEV_MAP_FLAG_WRITABLE, &mmio);
It tries that AFTER it has already found the graphics adapter and
verified that it's from Intel.
So, why it fails to actually map the memory of the device is anyone's
guess. Perhaps there's no support for the HD3000 in intel_audio_dump?
Anyway, with all of this out of the way: Why not instead look at the
EDID binary dump I sent you and step through the edid_to_eld() function
to see what it's doing?
Christopher
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
