[RFC][PATCH] ELD routines and proc interface
Wu Fengguang
wfg at linux.intel.com
Thu Nov 20 17:36:55 PST 2008
Hi Shane,
On Thu, Nov 20, 2008 at 12:06:06PM -0800, Shane W wrote:
> Hi,
>
> Ok, it appears to be the kernel I was using. Going to a
> 2.6.27 kernel rather than 2.6.28-rc fixed the segfault. So
> now I get ELD data though 5.1 PCM isn't quite there yet.
> Here's the ELD info.
Thanks.
> HDMI intrinsic event: PD=1 ELDV=1
> detected monitor Haier TV*** at connection type HDMI
> supports coding type LPCM: channels = 2, rates = 44100
> 48000 88200 176400 192000 384000, bits =
> supports coding type LPCM: channels = 8, rates = 44100
> 48000 88200 176400 192000 384000, bits =
It reveals bugs in showing the bits field. Will fix it in a following
email.
> supports coding type AC-3: channels = 6, rates = 44100
> 48000 88200, max bitrate = 640000
> supports coding type DTS: channels = 7, rates = 44100 48000
> 88200 176400 192000, max bitrate = 1536000
> supports coding type DSD (One Bit Audio): channels = 6,
> rates = 48000
It's weird that DTS supports 7 channels while DSD supports 6.
DTS is simple the compressed form of DSD.
> set status page addr 0x08360000
> [drm:i915_getparam] *ERROR* Unknown parameter 5
>
> shane at chintoka:~$ cat /proc/asound/Intel/eld#3
> monitor name Haier TV***
> connection_type HDMI
> eld_version [0x2] CEA-861D or below
> edid_version [0x1] CEA-861
> manufacture_id 0x4148
> product_id 0xb01
> port_id 0x0
> support_hdcp 0
> support_ai 0
> audio_sync_delay 0
> speakers [0x0]
> sad_count 8
> sad0_coding_type [0x1] LPCM
> sad0_channels 2
> sad0_rates [0x1ee0] 44100 48000 88200 176400
> 192000 384000
> sad0_bits [0xe0000]
> sad1_coding_type [0x1] LPCM
> sad1_channels 8
> sad1_rates [0x1ee0] 44100 48000 88200 176400
> 192000 384000
> sad1_bits [0xe0000]
> sad2_coding_type [0x2] AC-3
> sad2_channels 6
> sad2_rates [0xe0] 44100 48000 88200
> sad2_max_bitrate 640000
> sad3_coding_type [0x7] DTS
> sad3_channels 7
> sad3_rates [0x6e0] 44100 48000 88200 176400
> 192000
> sad3_max_bitrate 1536000
> sad4_coding_type [0x9] DSD (One Bit Audio)
> sad4_channels 6
> sad4_rates [0x40] 48000
> sad5_coding_type [0x0] undefined
> sad5_channels 1
> sad5_rates [0x0]
> sad6_coding_type [0x0] undefined
> sad6_channels 1
> sad6_rates [0x0]
> sad7_coding_type [0x0] undefined
> sad7_channels 1
> sad7_rates [0x0]
I wonder why the monitor report these zero valued SADs?
> The speakers 0 line is a bit confusing, not sure if that's
Yes it's unexpected. Do you know its real speaker numbers and
allocations? Does it provide some number of line-out ports?
> what's doing it. I am using:
> aplay 51test.wav
>
> which I have put here:
> http://www.csy.ca/~shane/51test.wav
I hear only "front left" and "front right" in my T61 :-)
Thanks,
Fengguang
---
>
> Shane
> On Thu, Nov 20, 2008 at 09:02:04AM +0800, Wu Fengguang wrote:
> > Thanks Shane!
> >
> > Ma Ling: do you have a quick fix for it? Or shall I look into it?
> >
> > Thank you,
> > Fengguang
> >
> > On Wed, Nov 19, 2008 at 12:02:01PM -0800, Shane W wrote:
> > > On Wed, Nov 19, 2008 at 05:39:40PM +0800, Wu Fengguang wrote:
> > > > I managed to update the last working Xorg ELD patches to the latest
> > > > git tree, and they compile flawlessly. The attached 2 patches are for
> > > > xf86-video-intel/ and xserver/ respectively.
> > >
> > > They do compile but I can't get them to run. Here's the
> > > Xorg backtrace when starting. I'm having trouble
> > > generating a core but I'll work on getting gdb output if
> > > needed.
> > >
> > > Backtrace:
> > > 0: /opt/gfx-test/bin/Xorg(xorg_backtrace+0x26) [0x4ebbb6]
> > > 1: /opt/gfx-test/bin/Xorg(xf86SigHandler+0x39) [0x495b49]
> > > 2: /lib/libc.so.6 [0x7f2d1648bf60]
> > > 3:
> > > /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so(gen4_render_state_cleanup+0x1c)
> > > [0x7f2d14ebab9c]
> > > 4: /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so
> > > [0x7f2d14e92dfd]
> > > 5: /opt/gfx-test/bin/Xorg(AbortDDX+0x8d) [0x4690fd]
> > > 6: /opt/gfx-test/bin/Xorg(AbortServer+0x1d) [0x4f505d]
> > > 7: /opt/gfx-test/bin/Xorg(LogVMessageVerb+0) [0x4f5700]
> > > 8:
> > > /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so(i830_bind_all_memory+0x102)
> > > [0x7f2d14e99592]
> > > 9: /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so
> > > [0x7f2d14e93ad0]
> > > 10: /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so
> > > [0x7f2d14e950f8]
> > > 11: /opt/gfx-test/bin/Xorg(AddScreen+0x1c6) [0x431086]
> > > 12: /opt/gfx-test/bin/Xorg(InitOutput+0x241) [0x469ae1]
> > > 13: /opt/gfx-test/bin/Xorg(main+0x205) [0x431795]
> > > 14: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f2d164781a6]
> > > 15: /opt/gfx-test/bin/Xorg [0x430dd9]
> > >
> > > It seems to be the xserver patch that's doing it. When they
> > > are both unapplied, X starts fine, when the Xserver patch
> > > is applied, we segfault, when the intel is applied alone,
> > > it starts fine and when both are applied the segfault
> > > returns.
> > >
> > > Shane
More information about the xorg
mailing list