Re: [PULL] soc-camera and mediabus
Hi Mauro
On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:
Guennadi Liakhovetski wrote:
So, is the doc patch, that I've sent to the list ok? Ok, the hunk for the
automatically (in hg) generated file will get dropped, and otherwise does
it look correct?
It looks correctly on my eyes. The only thing I noticed is that you've added
emacs headers at the end of the new patches:
+
+ !--
+Local Variables:
+mode: sgml
+sgml-parent-document: pixfmt.sgml
+indent-tabs-mode: nil
+End:
+ --
Please remove those tags when submitting the final version.
I tried to just through away the media-specs/media-entities.tmpl hunk, as
that file should be auto-generated, but the new version doesn't include
the new formats either. What am I doing wrong? The patch attached below.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
# HG changeset patch
# User Guennadi Liakhovetski g.liakhovet...@gmx.de
# Date 1261648434 -3600
# Node ID 52e14d4799279a860fe158e8bf4f1993d6c6
# Parent 4506e2d541265bfa0c0fd5187c6a39d39a456559
document new pixel formats
Document all four 10-bit Bayer formats, 10-bit monochrome and a missing
8-bit Bayer formats.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
diff -r 4506e2d54126 -r 52e14d479927
linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb10.xmlThu Dec 24
10:53:54 2009 +0100
@@ -0,0 +1,90 @@
+refentry
+ refmeta
+ refentrytitleV4L2_PIX_FMT_SRGGB10 ('RG10'),
+V4L2_PIX_FMT_SGRBG10 ('BA10'),
+V4L2_PIX_FMT_SGBRG10 ('GB10'),
+V4L2_PIX_FMT_SBGGR10 ('BG10'),
+/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname
id=V4L2-PIX-FMT-SRGGB10constantV4L2_PIX_FMT_SRGGB10/constant/refname
+ refname
id=V4L2-PIX-FMT-SGRBG10constantV4L2_PIX_FMT_SGRBG10/constant/refname
+ refname
id=V4L2-PIX-FMT-SGBRG10constantV4L2_PIX_FMT_SGBRG10/constant/refname
+ refname
id=V4L2-PIX-FMT-SBGGR10constantV4L2_PIX_FMT_SBGGR10/constant/refname
+ refpurpose10-bit Bayer formats expanded to 16 bits/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThe following four pixel formats are raw sRGB / Bayer formats with
+10 bits per colour. Each colour component is stored in a 16-bit word, with 6
+unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
+formats/para
+
+example
+ titleconstantV4L2_PIX_FMT_SBGGR10/constant 4 times; 4
+pixel image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte, high 6 bits in high bytes are 0.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryBsubscript00low/subscript/entry
+ entryBsubscript00high/subscript/entry
+ entryGsubscript01low/subscript/entry
+ entryGsubscript01high/subscript/entry
+ entryBsubscript02low/subscript/entry
+ entryBsubscript02high/subscript/entry
+ entryGsubscript03low/subscript/entry
+ entryGsubscript03high/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryGsubscript10low/subscript/entry
+ entryGsubscript10high/subscript/entry
+ entryRsubscript11low/subscript/entry
+ entryRsubscript11high/subscript/entry
+ entryGsubscript12low/subscript/entry
+ entryGsubscript12high/subscript/entry
+ entryRsubscript13low/subscript/entry
+ entryRsubscript13high/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;16:/entry
+ entryBsubscript20low/subscript/entry
+ entryBsubscript20high/subscript/entry
+ entryGsubscript21low/subscript/entry
+ entryGsubscript21high/subscript/entry
+ entryBsubscript22low/subscript/entry
+ entryBsubscript22high/subscript/entry
+ entryGsubscript23low/subscript/entry
+ entryGsubscript23high/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;24:/entry
+ entryGsubscript30low/subscript/entry
+ entryGsubscript30high/subscript/entry
+ entryRsubscript31low/subscript/entry
+
[PATCH] soc-camera: adjust coding style to match V4L preferences
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/soc_mediabus.c | 45
1 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
index f8d5c87..0149290 100644
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -24,91 +24,106 @@ static const struct soc_mbus_pixelfmt mbus_fmt[] = {
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(YVYU8_2X8_LE)] = {
+ },
+ [MBUS_IDX(YVYU8_2X8_LE)] = {
.fourcc = V4L2_PIX_FMT_YVYU,
.name = YVYU,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(YUYV8_2X8_BE)] = {
+ },
+ [MBUS_IDX(YUYV8_2X8_BE)] = {
.fourcc = V4L2_PIX_FMT_UYVY,
.name = UYVY,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(YVYU8_2X8_BE)] = {
+ },
+ [MBUS_IDX(YVYU8_2X8_BE)] = {
.fourcc = V4L2_PIX_FMT_VYUY,
.name = VYUY,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(RGB555_2X8_PADHI_LE)] = {
+ },
+ [MBUS_IDX(RGB555_2X8_PADHI_LE)] = {
.fourcc = V4L2_PIX_FMT_RGB555,
.name = RGB555,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(RGB555_2X8_PADHI_BE)] = {
+ },
+ [MBUS_IDX(RGB555_2X8_PADHI_BE)] = {
.fourcc = V4L2_PIX_FMT_RGB555X,
.name = RGB555X,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(RGB565_2X8_LE)] = {
+ },
+ [MBUS_IDX(RGB565_2X8_LE)] = {
.fourcc = V4L2_PIX_FMT_RGB565,
.name = RGB565,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(RGB565_2X8_BE)] = {
+ },
+ [MBUS_IDX(RGB565_2X8_BE)] = {
.fourcc = V4L2_PIX_FMT_RGB565X,
.name = RGB565X,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_2X8_PADHI,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(SBGGR8_1X8)] = {
+ },
+ [MBUS_IDX(SBGGR8_1X8)] = {
.fourcc = V4L2_PIX_FMT_SBGGR8,
.name = Bayer 8 BGGR,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_NONE,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(SBGGR10_1X10)] = {
+ },
+ [MBUS_IDX(SBGGR10_1X10)] = {
.fourcc = V4L2_PIX_FMT_SBGGR10,
.name = Bayer 10 BGGR,
.bits_per_sample= 10,
.packing= SOC_MBUS_PACKING_EXTEND16,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(GREY8_1X8)] = {
+ },
+ [MBUS_IDX(GREY8_1X8)] = {
.fourcc = V4L2_PIX_FMT_GREY,
.name = Grey,
.bits_per_sample= 8,
.packing= SOC_MBUS_PACKING_NONE,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(Y10_1X10)] = {
+ },
+ [MBUS_IDX(Y10_1X10)] = {
.fourcc = V4L2_PIX_FMT_Y10,
.name = Grey 10bit,
.bits_per_sample= 10,
.packing= SOC_MBUS_PACKING_EXTEND16,
.order = SOC_MBUS_ORDER_LE,
- }, [MBUS_IDX(SBGGR10_2X8_PADHI_LE)] = {
+ },
+ [MBUS_IDX(SBGGR10_2X8_PADHI_LE)] = {
.fourcc = V4L2_PIX_FMT_SBGGR10,
.name
Cx88 ( Hauppauge WinTV-HVR-4000 ): can't do zapping.
Hi all, I've a Hauppauge WinTV-HVR-4000 (http://www.hauppauge.co.uk/site/products/data_hvr4000.html http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000), and i use it mainly for DVB-T through vlc and kaffeine in a Gentoo x86_64 and x86 box. The first one is a bit faster in tuning but both have a problem: if i'm watching something i can't change channel directly without stopping the one i'm watching. This also happens with a tzap's based script (http://www.linuxtv.org/wiki/index.php/Testing_reception_quality) which tests signal quality. So i think it is a driver problem (i'm using kernel's one): uname -a : Linux P4 2.6.31-gentoo-r6 #3 SMP PREEMPT Sun Dec 20 09:53:55 CET 2009 x86_64 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux lspci -vnn : 02:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Subsystem: Hauppauge computer works Inc. Device [0070:6902] Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at f400 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Kernel driver in use: cx8800 Kernel modules: cx8800 02:00.1 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8801] (rev 05) Subsystem: Hauppauge computer works Inc. Device [0070:6902] Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at f500 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88_audio Kernel modules: cx88-alsa 02:00.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) Subsystem: Hauppauge computer works Inc. Device [0070:6902] Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at f600 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 02:00.4 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] [14f1:8804] (rev 05) Subsystem: Hauppauge computer works Inc. Device [0070:6902] Flags: bus master, medium devsel, latency 32, IRQ 9 Memory at f700 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 dmesg: [5.269734] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded [5.269934] cx88[0]: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68,autodetected], frontend(s): 2 [5.269939] cx88[0]: TV tuner type 63, Radio tuner type -1 [5.286188] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded [5.296136] cx2388x alsa driver version 0.0.7 loaded [5.384144] cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner [5.837300] tuner 1-0043: chip found @ 0x86 (cx88[0]) [5.837306] tda9887 1-0043: creating new instance [5.837309] tda9887 1-0043: tda988[5/6/7] found [5.843180] tuner 1-0061: chip found @ 0xc2 (cx88[0]) [5.886173] tveeprom 1-0050: Hauppauge model 69009, rev B4D3, serial# 6520465 [5.886180] tveeprom 1-0050: MAC address is 00-0D-FE-63-7E-91 [5.886185] tveeprom 1-0050: tuner model is Philips FMD1216MEX (idx 133, type 78) [5.886190] tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) [5.886195] tveeprom 1-0050: audio processor is CX880 (idx 30) [5.886199] tveeprom 1-0050: decoder processor is CX880 (idx 20) [5.886203] tveeprom 1-0050: has radio, has IR receiver, has no IR transmitter [5.886206] cx88[0]: hauppauge eeprom: model=69009 [5.886692] tuner-simple 1-0061: creating new instance [5.886697] tuner-simple 1-0061: type set to 78 (Philips FMD1216MEX MK3 Hybrid Tuner) [5.891595] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci:00/:00:1e.0/:02:00.2/input/input4 [5.891726] cx88[0]/2: cx2388x 8802 Driver Manager [5.891748] cx88-mpeg driver manager :02:00.2: PCI INT A - GSI 20 (level, low) - IRQ 20 [5.891760] cx88[0]/2: found at :02:00.2, rev: 5, irq: 20, latency: 32, mmio: 0xf600 [5.891768] IRQ 20/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs [5.891821] cx8800 :02:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [5.891830] cx88[0]/0: found at :02:00.0, rev: 5, irq: 20, latency: 32, mmio: 0xf400 [5.891841] IRQ 20/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs [5.963166] wm8775 1-001b: chip found @ 0x36 (cx88[0]) [5.970089] cx88[0]/0: registered device video0 [v4l2] [5.970137] cx88[0]/0: registered device vbi0 [5.970184] cx88[0]/0: registered device radio0 [5.986679] cx88_audio :02:00.1: PCI
Re: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
Martin,
(Moving discussion to the linux-media list since the ivtv-devel list was
unresponsive/dead recently.)
On Sun, 2009-12-06 at 19:44 +0100, Martin Dauskardt wrote:
From: Andy Walls awa...@radix.net
Martin,
It is not turning the digitizer on/off but really enable/disable the
clock output pins of the digitizer. The cause of the tinny audio is
likely that the clock pins from the CX2584x are floating.
This call makes sure the clock output enables are turned on and the pins
are not floating. I suspect no where else are they explciity enabled in
the driver before the first capture (I can go back and verify).
I am only a hobbyist, so please forgive me if there is an error ...
No that's fine too; as long as *somewhere* in the ivtv driver we turn on
the CX2584x's output enables before the first capture.
It really seems that no where else the clock output pins are enabled. I did
not find another s_stream call to the digitizer. But amazing: Even I comment
out the line
v4l2_subdev_call(itv-sd_video, video, s_stream, 1);
the stream starts most of the time (but fails occasionally).
You wrote I suspect that these signals floating cause the CX23416 to make
some bad guesses about audio sample rate when CX2341X_ENC_INTIALIZE_INPUT is
called.
Then we have to enable the digitizer before CX2341X_ENC_INTIALIZE_INPUT.
But the first patch from Argus -which helped him to solve the problem- does
not enable the output. So this is either not necessary or the real problem is
something else. (I made a lot of testing with a PVR150 and an unpatched
driver
and had never any audio problems)
Unfortunately there was a mistake in my last code. The if-statement has to be
in additionally brackets, otherwise it is never true and the digitizer is not
disabled for saa7115-based card.
I tested this code now with PVR150 and PVR350:
if (atomic_read(itv-capturing) == 0) {
/* Clear all Pending Interrupts */
ivtv_set_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE);
clear_bit(IVTV_F_I_EOS, itv-i_flags);
/* Turn off non-cx25840 digitizer to avoid flickering */
if (!(itv-sd_video-grp_id IVTV_HW_CX25840)) {
v4l2_subdev_call(itv-sd_video, video, s_stream, 0);
}
else {
/* make sure the cx25840 clock output pins are enabled and
not
floating */
v4l2_subdev_call(itv-sd_video, video, s_stream, 1);
}
ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
/* Turn on non-cx25840 digitizer and allow clock
output of the digitizer to stabilize before starting
capture */
if (!(itv-sd_video-grp_id IVTV_HW_CX25840)) {
v4l2_subdev_call(itv-sd_video, video, s_stream, 1);
ivtv_msleep_timeout(300, 1);
}
}
You mentioned that the 300ms sleep is probably needed for the clock output of
the digitizer to stabilize. For me it seems more logical if this is done
after ***enabling*** the digitizer output, so I moved this. It seems to work
fine.
I made a similar test with the pvrusb2 driver (which has a black video
problem
and currently no timeout sleep after the digitizer switches). There it works
better when we place the sleep after re-enabling the digitizer. So I think
the
above solution should be right.
I also tested if we can avoid disabling the digitizer for saa7115. Both
pvrusb2 (old model 29xxx) and PVR350 show disturbance (sync problems) when
stopping/starting a stream. This leads to flickering with cx23415 (PVR350).
The cx23416 has no flickering problem, but it is annoying to see sync
problems
during channel switches.
The cx25840 devices (PVR150 and the pvrusb2-based HVR1900) do not show these
problems. The connection to the cx23416 must be different - the new stream
appears always without any snc issues.
Suggestion:
We need more testers to see if a driver change like above is safe for
everybody. Even if it turns out that it is no reliable fix against tinny
audio, it improves the speed for encoder stop/start on cx25840 devices.
I don't know if Myth is stopping/starting the stream for every channel
switch,
but for vdr (pvrinput-plugin) we are doing this. And there I recognize that
channel switching is faster now with cx25840 devices.
And we shouldn't do anything without hearing Hans Hans, where are you?
Greets,
Martin
I have a version of the change for the ivtv/PVR-150 tinny audio fix at
http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix
http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix/rev/7753cdcebd28
It separates out the enable/disable of audio video streaming from each
other for the cx25840 module. Then the ivtv driver can set them
independently to
Re: Which modules for the VP-2033? Where is the module mantis.ko?
Aljaž Prusnik schrieb: On sre, 2009-12-23 at 23:24 +0400, Manu Abraham wrote: Aljaz, do you have the module mantis.ko? There was a build issue when i posted the link originally, but it had been fixed.. m...@manu-04:/stor/work/merge/v4l-dvb/v4l ls *.ko |grep mantis mantis_core.ko mantis.ko Yup, I have both of them. I just compiled http://jusst.de/hg/v4l-dvb again and the result is (depmode -a was run): - ir-common.ko is under drivers/media/common (not drivers/media/IR like Igor suggested but that is probably because it's a different repository). - mantis.ko and mantis_core.ko are under drivers/media/dvb/mantis Aljaž, thanks for the reply. As Manu said above there was a build problem. As said already in this Thread, I downloaded version 2315248f648c, which compiles fine and has all modules for the 2033 DVB-C. Rüdiger -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which modules for the VP-2033? Where is the module mantis.ko?
On čet, 2009-12-24 at 17:45 +0100, Ruediger Dohmhardt wrote: Aljaž, thanks for the reply. As Manu said above there was a build problem. As said already in this Thread, I downloaded version 2315248f648c, which compiles fine and has all modules for the 2033 DVB-C. I have the same version and it doesn't work for me. I have a 2040 module. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Dec 24 19:00:07 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13842:4506e2d54126 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30-i686: ERRORS linux-2.6.31-i686: ERRORS linux-2.6.32-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
Hi everybody and Merry Christmas,
Andy Walls wrote:
I have a version of the change for the ivtv/PVR-150 tinny audio fix at
http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix
http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix/rev/7753cdcebd28
It separates out the enable/disable of audio video streaming from each
other for the cx25840 module. Then the ivtv driver can set them
independently to avoid both the unpredictable PCI hang and the tinny
audio in a very generic way. Please test when you can.
@ Andy:
now we have a second 300ms delay in ivtv-streams.c
2.6/* Initialize Digitizer for Capture */
2.7 + /* Avoid tinny audio problem - ensure audio clocks are
going */
2.8 + v4l2_subdev_call(itv-sd_audio, audio, s_stream, 1);
2.9 + /* Avoid unpredictable PCI bus hang - disable video
clocks */
2.10v4l2_subdev_call(itv-sd_video, video, s_stream, 0);
2.11ivtv_msleep_timeout(300, 1);
2.12ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
2.13v4l2_subdev_call(itv-sd_video, video, s_stream, 1);
2.14 + ivtv_msleep_timeout(300, 1);
This would increase the time for channel switching (using encoder stop/start)
noticeable. My suggestion was to move the 300ms sleep at the point after the
stream is re-enabled, so we don't need the first msleep.
I have not tested your code, hope I can do this during the next days.
Mike,
I had to add another subdev call to pvrusb2 to get the same end result
of s_stream calls to the cx25840 module.
@ Mike:
do you remember my posting in the pvrusb2 list about sporadic black screen
after starting a stream? We had the same problem in ivtv, and the 300ms sleep
after disabling the digitizer solved the problem.
I implemented this in a similary way in the pvrusb2 driver and the problem
never appeared again:
--- v4l-dvb-309f16461cf4-orig/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-12-05 13:34:21.0 +0100
+++ v4l-dvb-309f16461cf4-patched/linux/drivers/media/video/pvrusb2/pvrusb2-
hdw.c 2009-12-24 22:42:49.746899065 +0100
@@ -4689,6 +4689,7 @@
del_timer_sync(hdw-quiescent_timer);
if (hdw-flag_decoder_missed) return 0;
if (pvr2_decoder_enable(hdw,!0) 0) return 0;
+ msleep(300);
hdw-state_decoder_quiescent = 0;
hdw-state_decoder_run = !0;
}
My initial idea was to avoid disabling/enabling the digitizer for devices with
cx2584x-digitizer. Channel changing (using encoder stop/start) with a PVR150
and HVR1900 took always about a second longer than with saa7115-based devices.
Without disabling/enabling the digitizer around the
CX2341X_ENC_INITIALIZE_INPUT call it speeds up noticeable.
So this is the alternate patch for the pvrusb2 driver (similar code for ivtv
was in my last posting which Andy had in his mail):
--- v4l-dvb-309f16461cf4-orig/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c
2009-12-05 13:34:21.0 +0100
+++ v4l-dvb-309f16461cf4-patched/linux/drivers/media/video/pvrusb2/pvrusb2-
hdw.c 2009-12-24 22:48:03.481899379 +0100
@@ -4646,9 +4646,9 @@
!hdw-state_pipeline_pause
hdw-state_pathway_ok) return 0;
}
- if (!hdw-flag_decoder_missed) {
- pvr2_decoder_enable(hdw,0);
- }
+if (hdw-decoder_client_id != PVR2_CLIENT_ID_CX25840 !hdw-
flag_decoder_missed) {
+ pvr2_decoder_enable(hdw,0);
+}
hdw-state_decoder_quiescent = 0;
hdw-state_decoder_run = 0;
/* paranoia - solve race if timer just completed */
@@ -4688,7 +4688,10 @@
!hdw-state_encoder_ok) return 0;
del_timer_sync(hdw-quiescent_timer);
if (hdw-flag_decoder_missed) return 0;
- if (pvr2_decoder_enable(hdw,!0) 0) return 0;
+if (hdw-decoder_client_id != PVR2_CLIENT_ID_CX25840) {
+ if (pvr2_decoder_enable(hdw,!0) 0) return 0;
+msleep(300);
+}
hdw-state_decoder_quiescent = 0;
hdw-state_decoder_run = !0;
}
It works fine with a HVR 1900, but should be tested with a PVRUSB2 model
24xxx.
Greets,
Martin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bad image quality with Medion MD 95700
Hi, I tried a Medion MD 95700 with kernel 2.6.32 (for tests: 2.6.30.9) and have a very bad image and sound quality. Right now I'm using 2.6.32 with V4L/DVB from SVN (v4l-dvb-4506e2d54126) Here is an example: http://img200.imageshack.us/img200/3950/dvbtlinux.png and another: http://img130.imageshack.us/img130/6278/dvbt2.png The DVB-T stream seems to be good: femon FE: Conexant CX22702 DVB-T (DVBT) status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK (it's a bit bad right now, normally the signal is around 50%) under windows XP the image and sound is perfect. P.S. this is the output from mplayer after looking DVB-T for a few seconds: mplayer dvb://ProSieben(ProSiebenSat.1) MPlayer SVN-r29796-4.4.2 (C) 2000-2009 MPlayer Team Spiele dvb://ProSieben(ProSiebenSat.1). dvb_tune Freq: 69000 TS-Dateiformat erkannt! VIDEO MPEG2(pid=511) AUDIO MPA(pid=512) NO SUBS (yet)! PROGRAM N. 0 VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s) == Öffne Videodecoder: [mpegpes] MPEG 1/2 Video passthrough Konnte keinen passenden Farbraum finden - neuer Versuch mit '-vf scale'... Öffne Videofilter: [scale] Der ausgewählte Videoausgabetreiber ist nicht kompatibel mit diesem Codec. Versuche den scale-Filter zu deiner Filterliste hinzuzufügen, z.B. mit -vf spp,scale an Stelle von -vf spp. Initialisierung des Videodecoders fehlgeschlagen :( Öffne Videodecoder: [ffmpeg] FFmpeg's libavcodec codec family Unsupported PixelFormat -1 Ausgewählter Videocodec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2) == == Öffne Audiodecoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000-192000) Ausgewählter Audiocodec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) == AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starte Wiedergabe... Film-Aspekt ist 1,78:1 - Vorskalierung zur Korrektur der Seitenverhältnisse. VO: [xv] 720x576 = 1024x576 Planar YV12 [mpeg2video @ 0xc62be0]ac-tex damaged at 23 4 [mpeg2video @ 0xc62be0]ac-tex damaged at 14 9 [mpeg2video @ 0xc62be0]skipped MB in I frame at 40 10 [mpeg2video @ 0xc62be0]invalid mb type in I Frame at 29 15 [mpeg2video @ 0xc62be0]skipped MB in I frame at 32 19 [mpeg2video @ 0xc62be0]ac-tex damaged at 34 33 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors?% 0 0 [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors% 0 0 [mpeg2video @ 0xc62be0]mb incr damaged,008 3/ 3 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]00 motion_type at 27 17 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 98 DC, 98 AC, 98 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 34 54/ 4 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 35 95/ 5 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]ac-tex damaged at 36 86/ 6 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]invalid cbp at 25 13 [mpeg2video @ 0xc62be0]ac-tex damaged at 4 23 [mpeg2video @ 0xc62be0]concealing 157 DC, 157 AC, 157 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 8 8 7/ 7 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]concealing 50 DC, 50 AC, 50 MV errors?,?% 0 0 Bindung für Taste 'c' nicht gefunden. ?% 0 0 [mpeg2video @ 0xc62be0]invalid mb type in P Frame at 4 16 [mpeg2video @ 0xc62be0]concealing 45 DC, 45 AC, 45 MV errors [mpeg2video @ 0xc62be0]invalid mb type in B Frame at 0 31% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 225 DC, 225 AC, 225 MV errors [mpeg2video @ 0xc62be0]mb incr damaged,040 11/ 11 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]invalid cbp at 28 30 [mpeg2video @ 0xc62be0]concealing 203 DC, 203 AC, 203 MV errors [mpeg2video @ 0xc62be0]ac-tex damaged at 24 72/ 12 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]skipped MB in I frame at 6 12 [mpeg2video @ 0xc62be0]skipped MB in I frame at 1 19 [mpeg2video @ 0xc62be0]skipped MB in I frame at 23 25 [mpeg2video @
Bad image/sound quality with Medion MD 95700
Hi, I tried a Medion MD 95700 with kernel 2.6.32 (for tests: 2.6.30.9) and have a very bad image and sound quality. Right now I'm using 2.6.32 with V4L/DVB from SVN (v4l-dvb-4506e2d54126) Here is an example: http://img200.imageshack.us/img200/3950/dvbtlinux.png and another: http://img130.imageshack.us/img130/6278/dvbt2.png The DVB-T stream seems to be good: femon FE: Conexant CX22702 DVB-T (DVBT) status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK (it's a bit bad right now, normally the signal is around 50%) under windows XP the image and sound is perfect. P.S. this is the output from mplayer after looking DVB-T for a few seconds: mplayer dvb://ProSieben(ProSiebenSat.1) MPlayer SVN-r29796-4.4.2 (C) 2000-2009 MPlayer Team Spiele dvb://ProSieben(ProSiebenSat.1). dvb_tune Freq: 69000 TS-Dateiformat erkannt! VIDEO MPEG2(pid=511) AUDIO MPA(pid=512) NO SUBS (yet)! PROGRAM N. 0 VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s) == Öffne Videodecoder: [mpegpes] MPEG 1/2 Video passthrough Konnte keinen passenden Farbraum finden - neuer Versuch mit '-vf scale'... Öffne Videofilter: [scale] Der ausgewählte Videoausgabetreiber ist nicht kompatibel mit diesem Codec. Versuche den scale-Filter zu deiner Filterliste hinzuzufügen, z.B. mit -vf spp,scale an Stelle von -vf spp. Initialisierung des Videodecoders fehlgeschlagen :( Öffne Videodecoder: [ffmpeg] FFmpeg's libavcodec codec family Unsupported PixelFormat -1 Ausgewählter Videocodec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2) == == Öffne Audiodecoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000-192000) Ausgewählter Audiocodec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) == AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starte Wiedergabe... Film-Aspekt ist 1,78:1 - Vorskalierung zur Korrektur der Seitenverhältnisse. VO: [xv] 720x576 = 1024x576 Planar YV12 [mpeg2video @ 0xc62be0]ac-tex damaged at 23 4 [mpeg2video @ 0xc62be0]ac-tex damaged at 14 9 [mpeg2video @ 0xc62be0]skipped MB in I frame at 40 10 [mpeg2video @ 0xc62be0]invalid mb type in I Frame at 29 15 [mpeg2video @ 0xc62be0]skipped MB in I frame at 32 19 [mpeg2video @ 0xc62be0]ac-tex damaged at 34 33 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors?% 0 0 [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors% 0 0 [mpeg2video @ 0xc62be0]mb incr damaged,008 3/ 3 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]00 motion_type at 27 17 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 98 DC, 98 AC, 98 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 34 54/ 4 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 35 95/ 5 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]ac-tex damaged at 36 86/ 6 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]invalid cbp at 25 13 [mpeg2video @ 0xc62be0]ac-tex damaged at 4 23 [mpeg2video @ 0xc62be0]concealing 157 DC, 157 AC, 157 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 8 8 7/ 7 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]concealing 50 DC, 50 AC, 50 MV errors?,?% 0 0 Bindung für Taste 'c' nicht gefunden. ?% 0 0 [mpeg2video @ 0xc62be0]invalid mb type in P Frame at 4 16 [mpeg2video @ 0xc62be0]concealing 45 DC, 45 AC, 45 MV errors [mpeg2video @ 0xc62be0]invalid mb type in B Frame at 0 31% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 225 DC, 225 AC, 225 MV errors [mpeg2video @ 0xc62be0]mb incr damaged,040 11/ 11 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]invalid cbp at 28 30 [mpeg2video @ 0xc62be0]concealing 203 DC, 203 AC, 203 MV errors [mpeg2video @ 0xc62be0]ac-tex damaged at 24 72/ 12 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]skipped MB in I frame at 6 12 [mpeg2video @ 0xc62be0]skipped MB in I frame at 1 19 [mpeg2video @ 0xc62be0]skipped MB in I frame at 23 25 [mpeg2video @
Dev help
Hi All, I'm just wondering if someone can point me in the direction of maybe either some documents or a good driver code to look at to understand how to write the drivers for cards etc. As some might have seen as playing with the terratec cinergy 2400i which has an old driver and am gonna have a play and see if i can get it working. Not sure if my coding would be good enough to submit to yourselves at the moment, but if there is a document to read, as current I dont understand how the PCI-e bridge loads and then loads the demod module and tuner and how it all links together... So any documents and maybe an example modules that loads a bridge / demod then tuner so i can understand would be great. Cheers for any help. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How to know which camera is /dev/videoX
Dear Guennadi Now my board (EcoVec) can use 2 soc-camera (mt9t112 / tw9910), and mt9t112 can attach/detach. If mt9t112 is attached, /dev/video0 = mt9t112 /dev/video1 = tw9910 But if mt9t112 is detached, it will /dev/video0 = tw9910 Now I would like to know which camera is /dev/video0. my /dev/video0 is ls -l /dev/video0 crw--w 1 root 1000 81, 0 Jun 9 2009 /dev/video0 I cheked 81:0 's name cat /sys/dev/char/81\:0/name sh_mobile_ceu.1 Above name is host of soc-camera for me. Are there any way to know camera name (mt9t112/tw9910) ? Best regards -- Kuninori Morimoto -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] dvb-apps ported for ISDB-T
Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu: I wrote several patches those days in order to allow dvb-apps to properly parse ISDB-T channel.conf. On ISDB-T, there are several new parameters, so the parsing is more complex than all the other currently supported video standards. I've added the changes at: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/ I've merged there Patrick's dvb-apps-isdbt tree. While there, I fixed a few bugs I noticed on the parser and converted it to work with the DVB API v5 headers that are bundled together with dvb-apps. This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones there can now be removed. TODO: = The new ISDB-T parameters are parsed, but I haven't add yet a code to make them to be used; There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the segment parameters. Currently, the parser will fail if those parameters are found. gnutv is still reporting ISDB-T as DVB-T. I've just fixed the issues on the TODO list. The DVB v5 code is now working fine for ISDB-T. Pending stuff (patches are welcome): - Implement v5 calls for other video standards; - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code for calling DVBv5 is now at /lib/libdvbapi/v5api.c); - Test/use the functions to retrieve values via DVBv5 API. The function is already there, but I haven't tested. With the DVBv5 API implementation, zap is now working properly with ISDB-T. gnutv also works (although some outputs - like decoder - may need some changes, in order to work with mpeg4/AAC video/audio codecs). Have fun! Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
