Re: Patch implementing V4L2_CAP_STREAMING for zr364xx driver
Lamarque, On Fri, 27 Mar 2009 15:39:26 -0300 Lamarque Vieira Souza lamar...@gmail.com wrote: Here is the patch with the modifications you asked. There's just one important part missing on your patch: you forgot so send your Signed-off-by: (please read README.patches file, at v4l-dvb tree: http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches). Also, you didn't provide a description. So, I need you to re-send at the proper format, by adding a subject line like: [PATCH] Implement V4L2_CAP_STREAMING for zr364xx driver And the body of the email should contain just the description plus your patch. Something like: This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by converting the driver to use videobuf. Tested with PC-CAM 880. It basically: . re-implements V4L2_CAP_READWRITE using videobuf; . copies cam-udev-product to the card field of the v4l2_capability struct. That gives more information to the users about the webcam; . moves the brightness setting code from before requesting a frame (in read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is executed only when the application request a change in brightness and not before every frame read; . comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype + libv4l do not work. This patch fixes zr364xx for applications such as mplayer, Kopete+libv4l and Skype+libv4l can make use of the webcam that comes with zr364xx chip. Signed-off-by: your name/email should be here the patch -- 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
[PATCH] Implement V4L2_CAP_STREAMING for zr364xx driver
This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by
converting the driver to use videobuf.
Tested with Creative PC-CAM 880.
It basically:
. implements V4L2_CAP_STREAMING using videobuf;
. re-implements V4L2_CAP_READWRITE using videobuf;
. copies cam-udev-product to the card field of the v4l2_capability struct.
That gives more information to the users about the webcam;
. moves the brightness setting code from before requesting a frame (in
read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
executed only when the application requests a change in brightness and
not before every frame read;
. comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype +
libv4l do not work.
This patch fixes zr364xx for applications such as mplayer,
Kopete+libv4l and Skype+libv4l can make use of the webcam that comes
with zr364xx chip.
Signed-off-by: Lamarque V. Souza lamar...@gmail.com
---
--- v4l-dvb/linux/drivers/media/video/zr364xx.c 2009-03-27 15:18:54.050413997
-0300
+++ v4l-dvb/linux-lvs/drivers/media/video/zr364xx.c 2009-03-27
15:22:47.914414277 -0300
@@ -1,5 +1,5 @@
/*
- * Zoran 364xx based USB webcam module version 0.72
+ * Zoran 364xx based USB webcam module version 0.73
*
* Allows you to use your USB webcam with V4L2 applications
* This is still in heavy developpement !
@@ -10,6 +10,8 @@
* Heavily inspired by usb-skeleton.c, vicam.c, cpia.c and spca50x.c drivers
* V4L2 version inspired by meye.c driver
*
+ * Some video buffer code by Lamarque based on s2255drv.c and vivi.c drivers.
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -25,7 +27,6 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-
#include linux/version.h
#include linux/module.h
#include linux/init.h
@@ -36,25 +37,34 @@
#include linux/highmem.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
+#include media/videobuf-vmalloc.h
#include compat.h
/* Version Information */
-#define DRIVER_VERSION v0.72
+#define DRIVER_VERSION v0.73
+#define ZR364_VERSION_CODE KERNEL_VERSION(0, 7, 3)
#define DRIVER_AUTHOR Antoine Jacquet, http://royale.zerezo.com/;
#define DRIVER_DESC Zoran 364xx
/* Camera */
-#define FRAMES 2
+#define FRAMES 1
#define MAX_FRAME_SIZE 10
#define BUFFER_SIZE 0x1000
#define CTRL_TIMEOUT 500
+#define ZR364XX_DEF_BUFS 4
+#define ZR364XX_READ_IDLE 0
+#define ZR364XX_READ_FRAME 1
/* Debug macro */
-#define DBG(x...) if (debug) printk(KERN_INFO KBUILD_MODNAME x)
-
+#define DBG(fmt, args...) \
+ do { \
+ if (debug) { \
+ printk(KERN_INFO KBUILD_MODNAME fmt, ##args); \
+ } \
+ } while (0)
/* Init methods, need to find nicer names for these
* the exact names of the chipsets would be the best if someone finds it */
@@ -103,24 +113,97 @@ static struct usb_device_id device_table
MODULE_DEVICE_TABLE(usb, device_table);
+struct zr364xx_mode {
+ u32 color; /* output video color format */
+ u32 brightness; /* brightness */
+};
+
+/* frame structure */
+struct zr364xx_framei {
+ unsigned long ulState; /* ulState:ZR364XX_READ_IDLE,
+ ZR364XX_READ_FRAME */
+ void *lpvbits; /* image data */
+ unsigned long cur_size; /* current data copied to it */
+};
+
+/* image buffer structure */
+struct zr364xx_bufferi {
+ unsigned long dwFrames; /* number of frames in buffer */
+ struct zr364xx_framei frame[FRAMES];/* array of FRAME structures */
+};
+
+struct zr364xx_dmaqueue {
+ struct list_headactive;
+ struct zr364xx_camera *cam;
+};
+
+struct zr364xx_pipeinfo {
+ u32 transfer_size;
+ u8 *transfer_buffer;
+ u32 transfer_flags;;
+ u32 state;
+ u32 prev_state;
+ u32 urb_size;
+ void *stream_urb;
+ void *cam; /* back pointer to zr364xx_camera struct */
+ u32 err_count;
+ u32 idx;
+ u32 priority_set;
+};
+
+struct zr364xx_fmt {
+ char *name;
+ u32 fourcc;
+ int depth;
+};
+
+/* image formats. */
+static const struct zr364xx_fmt formats[] = {
+ {
+ .name = JPG,
+ .fourcc = V4L2_PIX_FMT_JPEG,
+ .depth = 24
+ }
+};
/* Camera stuff */
struct zr364xx_camera {
struct usb_device *udev;/* save off the usb device pointer */
struct usb_interface *interface;/* the interface for this device */
struct video_device *vdev; /* v4l video device */
- u8 *framebuf;
int nb;
- unsigned char *buffer;
+ struct zr364xx_bufferi buffer;
int skip;
- int brightness;
int width;
int height;
int method;
Re: LinuxTV.org Site Suggestion
John Doe wrote: It would be nice if LinuxTV.org added a Supported Hardware for television cards for linux users. Regards, John Have you checked the Wiki found at http://linuxtv.org/wiki/ ? It already has what you want... //Magnus -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-bttv
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-bttv for the following: - tvaudio: fix mute and s/g_tuner handling - tvaudio: add tda9875 support. - tvaudio: always call init_timer to prevent rmmod crash. - bttv: convert to v4l2_subdev since i2c autoprobing will disappear. Changes since the last version: - removed the card definition's has_saa6588 bitfield, but added a comment in the header that it should be added if needed. - update has_saa6588 in the bttv struct with the probe result and removed sd_saa6588. This makes it possible to use has_saa6588 if we need to check for the presence of a saa6588. - replaced the three msp3400, tda7432 and tvaudio options by a single audiodev option for 'no audio', 'autodetect', 'msp3400', 'tda7432' and 'tvaudio'. All review comments have been incorporated in this tree, so I think it is ready to be merged now. Thanks, Hans diffstat: bt8xx/bttv-cards.c | 187 +++- bt8xx/bttv-driver.c | 43 +-- bt8xx/bttv-i2c.c| 52 +- bt8xx/bttv.h|7 + bt8xx/bttvp.h |5 - tvaudio.c | 158 ++- 6 files changed, 341 insertions(+), 111 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-bttv
On Saturday 28 March 2009 12:44:32 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-bttv for the following: - tvaudio: fix mute and s/g_tuner handling - tvaudio: add tda9875 support. - tvaudio: always call init_timer to prevent rmmod crash. - bttv: convert to v4l2_subdev since i2c autoprobing will disappear. Changes since the last version: - removed the card definition's has_saa6588 bitfield, but added a comment in the header that it should be added if needed. - update has_saa6588 in the bttv struct with the probe result and removed sd_saa6588. This makes it possible to use has_saa6588 if we need to check for the presence of a saa6588. - replaced the three msp3400, tda7432 and tvaudio options by a single audiodev option for 'no audio', 'autodetect', 'msp3400', 'tda7432' and 'tvaudio'. All review comments have been incorporated in this tree, so I think it is ready to be merged now. Added this small one as well: - bttv: tda9875 is no longer used by bttv, so remove from bt8xx/Kconfig. Thanks, Hans Thanks, Hans diffstat: bt8xx/bttv-cards.c | 187 +++- bt8xx/bttv-driver.c | 43 +-- bt8xx/bttv-i2c.c| 52 +- bt8xx/bttv.h|7 + bt8xx/bttvp.h |5 - tvaudio.c | 158 ++- 6 files changed, 341 insertions(+), 111 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PATCH] Implement V4L2_CAP_STREAMING for zr364xx driver
Em Saturday 28 March 2009, Hans de Goede escreveu: On 03/28/2009 11:11 AM, Lamarque Vieira Souza wrote: This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by converting the driver to use videobuf. Tested with Creative PC-CAM 880. It basically: . implements V4L2_CAP_STREAMING using videobuf; . re-implements V4L2_CAP_READWRITE using videobuf; . copies cam-udev-product to the card field of the v4l2_capability struct. That gives more information to the users about the webcam; . moves the brightness setting code from before requesting a frame (in read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is executed only when the application requests a change in brightness and not before every frame read; . comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype + libv4l do not work. Note that this may make things work, but is not correct, applications which properly honor the field value may get bitten by this. The correct fix is to unconditionally set the field value to V4L2_FIELD_NONE. The part of zr364xx_vidioc_try_fmt_vid_cap which was commented was the if that checks the field value, now the driver does not do the check, it always set the field value to V4L2_FIELD_NONE, since that is the only value that the card accepts. This patch fixes zr364xx for applications such as mplayer, Kopete+libv4l and Skype+libv4l can make use of the webcam that comes with zr364xx chip. Signed-off-by: Lamarque V. Souzalamar...@gmail.com snip Regards, Hans -- Lamarque V. Souza http://www.geographicguide.com/brazil.htm Linux User #57137 - http://counter.li.org/ -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - saa7134: fix RTD Embedded Technologies VFG7350 support. - cs53l32a: remove legacy support. - dst_ca: fix compile warning. - dabusb: fix compile warning. Thanks, Hans diffstat: dvb/bt8xx/dst_ca.c |9 + video/cs53l32a.c| 10 +++--- video/dabusb.c |2 +- video/saa7134/saa6752hs.c |2 +- video/saa7134/saa7134-cards.c |8 video/saa7134/saa7134-core.c|5 +++-- video/saa7134/saa7134-empress.c |3 +-- video/saa7134/saa7134.h |1 + 8 files changed, 23 insertions(+), 17 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://linuxtv.org/hg/~anttip/ce6230/
Hi, Antti, 2009/3/25 Antti Palosaari cr...@iki.fi: Hello Mauro, Please pull http://linuxtv.org/hg/~anttip/ce6230/ for the following: zl10353: add support for Intel CE6230 and Intel CE6231 Add driver for Intel CE6230 DVB-T USB2.0 I've modified this code (hacking a little bit blindly) to handle the USB ID of the Avermedia A310 DVB-T tuner integrated in my Acer 6530G laptop. I knew it was based on the intel reference design for CE6230, and I can confirm that it seems to work correctly with the current code, altough I didn't perform extensive tests. w_scan finds the channels and Totem is able to change channels and show TV broadcasts. I'd like to have this USB ID supported out of the box when the driver gets upstream: Bus 003 Device 004: ID 07ca:a310 AVerMedia Technologies, Inc. Best regards, and lots of thanks, Juan Jesus. -- 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: [PULL] http://linuxtv.org/hg/~anttip/ce6230/
moikka Juan, Juan Jesús García de Soria Lucena wrote: I'd like to have this USB ID supported out of the box when the driver gets upstream: Bus 003 Device 004: ID 07ca:a310 AVerMedia Technologies, Inc. Thank you for reporting this. I will add this USB ID soon. regards Antti -- http://palosaari.fi/ -- 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: [linux-dvb] Patch: IR-support for Tevii s460
On 26 March 2009 21:02:40 Bernd Strauß wrote: The remote control which comes with this card doesn't work out of the box. This patch changes that. Works with LIRC and /dev/input/eventX. ___ DSL zum Nulltarif + 20 Euro ExtraprДmie bei Online-Bestellung Эber die DSL Freundschaftswerbung! http://dsl.web.de/?ac=OM.AD.AD008K15279B7069a Did you see my repository? Oh, I'm shure, you did! It is here quite some time already. Also TeVii s420. However, I'm not against it, only want my name being mentioned :) -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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
[Patch] IR support for TeVii S460 DVB-S card
changeset: 11251:58f9585b7d94
tag: tip
user:root
date:Sat Mar 28 15:19:20 2009 +0100
files: linux/drivers/media/common/ir-keymaps.c
linux/drivers/media/video/cx88/cx88-input.c linux/include/media/ir-common.h
description:
IR support for TeVii S460
From: Bernd Strauss no...@web.de
The remote control that comes with this card doesn't work out of the box.
This patch fixes that. Works with LIRC and /dev/input/eventX.
Priority: normal
Signed-off-by: Bernd Strauss no...@web.de
diff -r 2adf4a837334 linux/drivers/media/common/ir-keymaps.c
--- a/linux/drivers/media/common/ir-keymaps.c Sat Mar 28 06:55:35 2009 -0300
+++ b/linux/drivers/media/common/ir-keymaps.c Sat Mar 28 15:15:04 2009 +0100
@@ -2800,3 +2800,59 @@
[0x1b] = KEY_B, /*recall*/
};
EXPORT_SYMBOL_GPL(ir_codes_dm1105_nec);
+
+/* TeVii S460 DVB-S/S2
+ Bernd Strauss no...@web.de
+*/
+IR_KEYTAB_TYPE ir_codes_tevii_s460[IR_KEYTAB_SIZE] = {
+ [0x0a] = KEY_POWER,
+ [0x0c] = KEY_MUTE,
+ [0x11] = KEY_1,
+ [0x12] = KEY_2,
+ [0x13] = KEY_3,
+ [0x14] = KEY_4,
+ [0x15] = KEY_5,
+ [0x16] = KEY_6,
+ [0x17] = KEY_7,
+ [0x18] = KEY_8,
+ [0x19] = KEY_9,
+ [0x1a] = KEY_LAST, /* 'recall' / 'event info' */
+ [0x10] = KEY_0,
+ [0x1b] = KEY_FAVORITES,
+
+ [0x09] = KEY_VOLUMEUP,
+ [0x0f] = KEY_VOLUMEDOWN,
+ [0x05] = KEY_TUNER, /* 'live mode' */
+ [0x07] = KEY_PVR, /* 'play mode' */
+ [0x08] = KEY_CHANNELUP,
+ [0x06] = KEY_CHANNELDOWN,
+ [0x00] = KEY_UP,
+ [0x03] = KEY_LEFT,
+ [0x1f] = KEY_OK,
+ [0x02] = KEY_RIGHT,
+ [0x01] = KEY_DOWN,
+ [0x1c] = KEY_MENU,
+ [0x1d] = KEY_BACK,
+
+ [0x40] = KEY_PLAYPAUSE,
+ [0x1e] = KEY_REWIND,/* '' */
+ [0x4d] = KEY_FASTFORWARD, /* '' */
+ [0x44] = KEY_EPG,
+ [0x04] = KEY_RECORD,
+ [0x0b] = KEY_TIME, /* 'timer' */
+ [0x0e] = KEY_OPEN,
+ [0x4c] = KEY_INFO,
+ [0x41] = KEY_AB,/* 'A/B' */
+ [0x43] = KEY_AUDIO,
+ [0x45] = KEY_SUBTITLE,
+ [0x4a] = KEY_LIST,
+ [0x46] = KEY_F1,/* 'F1' / 'satellite' */
+ [0x47] = KEY_F2,/* 'F2' / 'provider' */
+ [0x5e] = KEY_F3,/* 'F3' / 'transp' */
+ [0x5c] = KEY_F4,/* 'F4' / 'favorites' */
+ [0x52] = KEY_F5,/* 'F5' / 'all' */
+ [0x5a] = KEY_F6,
+ [0x56] = KEY_SWITCHVIDEOMODE, /* 'mon' */
+ [0x58] = KEY_ZOOM, /* 'FS' */
+};
+EXPORT_SYMBOL_GPL(ir_codes_tevii_s460);
diff -r 2adf4a837334 linux/drivers/media/video/cx88/cx88-input.c
--- a/linux/drivers/media/video/cx88/cx88-input.c Sat Mar 28 06:55:35
2009 -0300
+++ b/linux/drivers/media/video/cx88/cx88-input.c Sat Mar 28 15:15:04
2009 +0100
@@ -330,6 +330,11 @@
ir-mask_keycode = 0x7e;
ir-polling = 100; /* ms */
break;
+ case CX88_BOARD_TEVII_S460:
+ ir_codes = ir_codes_tevii_s460;
+ ir_type = IR_TYPE_PD;
+ ir-sampling = 0xff00; /* address */
+ break;
}
if (NULL == ir_codes) {
@@ -436,6 +441,7 @@
switch (core-boardnr) {
case CX88_BOARD_TERRATEC_CINERGY_1400_DVB_T1:
case CX88_BOARD_DNTV_LIVE_DVB_T_PRO:
+ case CX88_BOARD_TEVII_S460:
ircode = ir_decode_pulsedistance(ir-samples, ir-scount, 1, 4);
if (ircode == 0x) { /* decoding error */
diff -r 2adf4a837334 linux/include/media/ir-common.h
--- a/linux/include/media/ir-common.h Sat Mar 28 06:55:35 2009 -0300
+++ b/linux/include/media/ir-common.h Sat Mar 28 15:15:04 2009 +0100
@@ -162,6 +162,7 @@
extern IR_KEYTAB_TYPE ir_codes_kworld_plus_tv_analog[IR_KEYTAB_SIZE];
extern IR_KEYTAB_TYPE ir_codes_kaiomy[IR_KEYTAB_SIZE];
extern IR_KEYTAB_TYPE ir_codes_dm1105_nec[IR_KEYTAB_SIZE];
+extern IR_KEYTAB_TYPE ir_codes_tevii_s460[IR_KEYTAB_SIZE];
#endif
/*
__
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
ausländische Netze zum gleichen Preis!
https://produkte.web.de/webde_sms/sms
--
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: V4L2 Advanced Codec questions
Hans Verkuil wrote: On Thursday 26 March 2009 16:59:11 Steven Toth wrote: Hello! I want to open a couple of HVR22xx items up for discussion. The HVR-22xx analog encoder is capable of encoded to all kinds of video and audio codecs in various containers formats. From memory, wm9, mpeg4, mpeg2, divx, AAC, AC3, Windows audio codecs in asf, ts, ps, avi containers, depending on various firmware license enablements and configuration options. Maybe more, maybe, I'll draw up a complete list when I begin to focus on analog. Any single encoder on the HVR22xx can produce (if licensed) any of the formats above. However, due to a lack of CPU horsepower in the RISC engine, the board is not completely symmetrical when the encoders are running concurrently. This is the main reason why Hauppauge have disabled these features in the windows driver. It's possible for example to get two concurrent MPEG2 PS streams but only if the bitrate is limited to 6Mbps, which we also do in the windows driver. Apart from the fact that we (the LinuxTV community) will need to determine what's possible concurrently, and what isn't, it does raise interesting issues for the V4L2 API. So, how do we expose this advanced codec and hardware encoder limitation information through v4l2 to the applications? Do we, don't we? Hi Steve, If I understand it correctly, then a single analog source can be encoded to multiple formats at the same time, right? No. Or is it that multiple analog sources can each be encoded to some format? Or a combination of both? Multiple analog sources can produce multiple formats, CPU power permitting. Is there a limit to the number of concurrent encoders (except for CPU horsepower)? Not that I'm aware of, yet. Basically, since you can have multiple encoders, you also need multiple videoX nodes, once for each encoder. And I would expect that an application can just setup each encoder. Whenever you start an encoder the driver might either accept it or return -ENOSPC if there aren't enough resources. This is fine, and expected. You have to document the restrictions in a document, but otherwise I don't see any reason why implementing this would cause any problems. Adding new containers and codecs is easy: just add the missing ones to enum v4l2_mpeg_stream_type, v4l2_mpeg_audio_encoding and v4l2_mpeg_video_encoding and add any additional controls that are needed to implement each codec/container. Ahh, this is the magic information I was looking for. In theory you can reduce the number of possible containers/codecs/bitrates in the controls according to the remaining resources. But I think that will be too complicated to do for too little gain, not only in the driver but also in the application. I think this is going to be the major issue and it will start to reflect itself through the API into the application. We'll see, maybe not. Thanks, Steve -- 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: V4L2 Advanced Codec questions
On Saturday 28 March 2009 18:03:47 Steven Toth wrote: Hans Verkuil wrote: On Thursday 26 March 2009 16:59:11 Steven Toth wrote: Hello! I want to open a couple of HVR22xx items up for discussion. The HVR-22xx analog encoder is capable of encoded to all kinds of video and audio codecs in various containers formats. From memory, wm9, mpeg4, mpeg2, divx, AAC, AC3, Windows audio codecs in asf, ts, ps, avi containers, depending on various firmware license enablements and configuration options. Maybe more, maybe, I'll draw up a complete list when I begin to focus on analog. Any single encoder on the HVR22xx can produce (if licensed) any of the formats above. However, due to a lack of CPU horsepower in the RISC engine, the board is not completely symmetrical when the encoders are running concurrently. This is the main reason why Hauppauge have disabled these features in the windows driver. It's possible for example to get two concurrent MPEG2 PS streams but only if the bitrate is limited to 6Mbps, which we also do in the windows driver. Apart from the fact that we (the LinuxTV community) will need to determine what's possible concurrently, and what isn't, it does raise interesting issues for the V4L2 API. So, how do we expose this advanced codec and hardware encoder limitation information through v4l2 to the applications? Do we, don't we? Hi Steve, If I understand it correctly, then a single analog source can be encoded to multiple formats at the same time, right? No. Or is it that multiple analog sources can each be encoded to some format? Or a combination of both? Multiple analog sources can produce multiple formats, CPU power permitting. So it is always: 'one source - one encoder', right? Never 'one source - multiple encoders'? Is there a limit to the number of concurrent encoders (except for CPU horsepower)? Not that I'm aware of, yet. There must be a limit to the number of sources? Or can this device act as a codec as well: you present it with raw video from memory and it compresses it to e.g. mpeg? Basically, since you can have multiple encoders, you also need multiple videoX nodes, once for each encoder. And I would expect that an application can just setup each encoder. Whenever you start an encoder the driver might either accept it or return -ENOSPC if there aren't enough resources. This is fine, and expected. You have to document the restrictions in a document, but otherwise I don't see any reason why implementing this would cause any problems. Adding new containers and codecs is easy: just add the missing ones to enum v4l2_mpeg_stream_type, v4l2_mpeg_audio_encoding and v4l2_mpeg_video_encoding and add any additional controls that are needed to implement each codec/container. Ahh, this is the magic information I was looking for. In theory you can reduce the number of possible containers/codecs/bitrates in the controls according to the remaining resources. But I think that will be too complicated to do for too little gain, not only in the driver but also in the application. I think this is going to be the major issue and it will start to reflect itself through the API into the application. We'll see, maybe not. The first step will be to get a single encoder going :-) At this stage I don't know enough about the capabilities of the hardware to tell how important it is to have such info available. I suspect any solution to this might well need something like a media controller device about which I've written before, which can be used to present such meta information. I'm ever more of the opinion that v4l needs such a top-level device as v4l hardware becomes more complex. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Dereferencing freed memory bugs
Dan Carpenter wrote: I added a check to smatch (http://repo.or.cz/w/smatch.git/) to check for when we dereference freed memory. drivers/dma/dmatest.c +410 dmatest_exit(7) 'dtc' drivers/dma/dmatest.c +412 dmatest_exit(9) 'dtc' Seems to be fixed by 7cbd4877e5b167b56a3d6033b926a9f925186e12: dmatest: fix use after free in dmatest_exit drivers/infiniband/hw/nes/nes_cm.c +563 nes_cm_timer_tick(121) 'cm_node' drivers/infiniband/hw/nes/nes_cm.c +621 nes_cm_timer_tick(179) 'cm_node' (...) drivers/usb/host/ehci-hcd.c +1661 itd_complete(79) 'stream' drivers/usb/host/ehci-hcd.c +2036 sitd_complete(64) 'stream' drivers/uwb/reset.c +193 __uwb_rc_cmd(26) 'cmd' (...) net/netfilter/xt_recent.c +273 recent_mt(69) 'e' (...) drivers/media/video/cpia_pp.c +777 cpia_pp_detach(28) 'cpia' (...) These are less obvious. Adding CCs. Please leave only one of openfabrics/linux-usb/netdev/linux-media in CCs when responding. ps: [s]itd_complete is in drivers/usb/host/ehci-sched.c -- 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
A question about Documentation/video4linux/gspca.txt
I notice that sq905.c and sq905c.c have now been added to the gspca tree. But now a question about the documentation. None of that has been addressed, as yet, neither for the sq905 nor for the sq905c cameras. The code has been added to the tree, but the accompanying documentation is, as yet, missing. I would be glad to provide it, but it seems to me that a policy question comes up, about just what to add. There are lots of cameras. Here is the problem: The sq905 module supports, as far as I know, the entire list of cameras which are supported by libgphoto2/camlibs/sq905, and probably more which I did not list there because I got tired of adding yet another camera when, in fact, functionally they were all pretty much equivalent (My bad. I know that I missed a few of them, but I was more inexperienced back then). In any event, the support for 24 cameras is explicitly listed there. The sq905c module supports, as far as I know, the entire list of cameras which are supported by libgphoto2/camlibs/digigr8. The support for 16 cameras (or 17, if the line in libgphoto2/camlibs/digigr8/library.c Sakar 28290 and 28292 Digital Concepts Styleshot which refers to two cameras differing only in the color of the case is counted as referring to two cameras). Thus, if the documentation would be provided in linux/Documentation/video4linux/gspca.txt it would amount to a total of 41 new entries, for these two new modules alone. Should all 41 of them be added? I would think that they all ought to be listed somewhere, but should the somewhere be there, or somewhere else? That is the question. One possibility might be to refer the curious reader to the existing list in the relevant file in libgphoto2, for example, since these are all dual-mode cameras. If that were done, then it would be only needed to put the USB Vendor:Product number into the gspca.txt file, along with a pointer to the full information. Theodore Kilgore -- 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: [PULL] http://linuxtv.org/hg/~anttip/ce6230/
On Sat, 28 Mar 2009 14:34:06 +0100 Juan Jesús García de Soria Lucena skanda...@gmail.com wrote: Hi, Antti, 2009/3/25 Antti Palosaari cr...@iki.fi: Hello Mauro, Please pull http://linuxtv.org/hg/~anttip/ce6230/ for the following: zl10353: add support for Intel CE6230 and Intel CE6231 Add driver for Intel CE6230 DVB-T USB2.0 I've modified this code (hacking a little bit blindly) to handle the USB ID of the Avermedia A310 DVB-T tuner integrated in my Acer 6530G laptop. I knew it was based on the intel reference design for CE6230, and I can confirm that it seems to work correctly with the current code, altough I didn't perform extensive tests. w_scan finds the channels and Totem is able to change channels and show TV broadcasts. I'd like to have this USB ID supported out of the box when the driver gets upstream: Bus 003 Device 004: ID 07ca:a310 AVerMedia Technologies, Inc. Best regards, and lots of thanks, So, please send the patch you did for analysis. Please submit it as explained at [1]. [1] http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches 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
[PATCH] to add new camera in gspca/mr97310a.c
The purpose of the following patch is to add another camera, with the new
USB Vendor:Product number 0x093a:0x010f to gspca/mr97310a.c. The camera
has also been added to the list of supported cameras in
Documentation/gspca.txt.
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
diff -uprN linuxa/Documentation/video4linux/gspca.txt
linuxb/Documentation/video4linux/gspca.txt
--- linuxa/Documentation/video4linux/gspca.txt 2009-03-28 11:48:44.0
-0500
+++ linuxb/Documentation/video4linux/gspca.txt 2009-03-28 16:12:07.0
-0500
@@ -209,6 +209,7 @@ sunplus 08ca:2050 Medion MD 41437
sunplus08ca:2060 Aiptek PocketDV5300
tv8532 0923:010f ICM532 cams
mars 093a:050f Mars-Semi Pc-Camera
+mr97310a 093a:010f Sakar Digital no. 77379
pac207 093a:2460 Qtec Webcam 100
pac207 093a:2461 HP Webcam
pac207 093a:2463 Philips SPC 220 NC
diff -uprN linuxa/drivers/media/video/gspca/mr97310a.c
linuxb/drivers/media/video/gspca/mr97310a.c
--- linuxa/drivers/media/video/gspca/mr97310a.c 2009-03-28 11:48:44.0
-0500
+++ linuxb/drivers/media/video/gspca/mr97310a.c 2009-03-28 15:58:59.0
-0500
@@ -321,6 +321,7 @@ static const struct sd_desc sd_desc = {
/* -- module initialisation -- */
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x08ca, 0x0111)},
+ {USB_DEVICE(0x093a, 0x010f)},
{}
};
MODULE_DEVICE_TABLE(usb, device_table);
--
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
Can't load firmware - HVR4000
Hi! I have recently moved my HVR4000 to a new machine, but now I can't load the firmware :-( I'm running Gentoo 2008.0, kernel 2.6.29 and I've tried both with the drivers included in the kernel and with v4l-drivers outside the kernel but I get the same result :-( When the machine starts up it loads the correct modules and I get a /dev/dvb/adapter0, but when I for example tries to do a scan I get an error message that it can't load the firmware (see the end of this mail) - what can I have done wrong, is there something with my kernel maybe? I have the firmware in /lib/firmware and I've tried with two different firmwares, one of them is the one I used eralier on the other installation ... Any hints? Best regards, Lars Fredriksson dmesg output; - [ 743.541920] cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)... [ 743.541927] i2c-adapter i2c-2: firmware: requesting dvb-fe-cx24116.fw [ 743.541945] [ cut here ] [ 743.541948] WARNING: at fs/sysfs/dir.c:462 sysfs_add_one+0x2a/0x36() [ 743.541950] Hardware name: M61SME-S2L [ 743.541952] sysfs: duplicate filename 'i2c-2' can not be created [ 743.541954] Modules linked in: cx22702 isl6421 cx24116 cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core wm8775 tuner_simple tuner_types tda9887 tda8290 tuner cx8800 cx88_alsa cx8802 cx88xx ir_common v4l2_common videodev v4l1_compat tveeprom videobuf_dma_sg videobuf_core btcx_risc [ 743.541972] Pid: 4043, comm: kdvb-ad-0-fe-0 Tainted: GW 2.6.29 #1 [ 743.541974] Call Trace: [ 743.541980] [c102580b] warn_slowpath+0x74/0x8a [ 743.541985] [c114cc4d] ? idr_get_empty_slot+0x155/0x230 [ 743.541989] [c114cdfe] ? ida_get_new_above+0xd6/0x153 [ 743.541993] [c108ef1b] ? wait_on_inode+0x24/0x2a [ 743.541996] [c108efd6] ? ifind+0x45/0x57 [ 743.542000] [c10bbbe1] sysfs_add_one+0x2a/0x36 [ 743.542014] [c10bc050] create_dir+0x43/0x68 [ 743.542017] [c10bc0a2] sysfs_create_dir+0x2d/0x41 [ 743.542021] [c114d772] ? kobject_get+0x12/0x17 [ 743.542024] [c114d827] kobject_add_internal+0xb0/0x154 [ 743.542027] [c114d976] kobject_add_varg+0x35/0x41 [ 743.542030] [c114dce8] kobject_add+0x49/0x4f [ 743.542034] [c11d8669] device_add+0x73/0x40d [ 743.542037] [c114d5a2] ? kobject_init_internal+0x12/0x28 [ 743.542040] [c114d60a] ? kobject_init+0x35/0x5a [ 743.542043] [c11d8a15] device_register+0x12/0x15 [ 743.542046] [c11dddbb] _request_firmware+0x177/0x346 [ 743.542051] [c11de003] request_firmware+0xa/0xc [ 743.542056] [f7d86525] cx24116_cmd_execute+0xa5/0x528 [cx24116] [ 743.542063] [c12a8d59] ? bit_xfer+0x391/0x39c [ 743.542067] [f7d870fd] cx24116_sleep+0x40/0x82 [cx24116] [ 743.542071] [f7d8f0b6] ? isl6421_set_voltage+0x5f/0x6c [isl6421] [ 743.542084] [f7d5e3bd] dvb_frontend_thread+0x44c/0x480 [dvb_core] [ 743.542089] [c1035405] ? autoremove_wake_function+0x0/0x33 [ 743.542099] [f7d5df71] ? dvb_frontend_thread+0x0/0x480 [dvb_core] [ 743.542103] [c1035331] kthread+0x3b/0x62 [ 743.542106] [c10352f6] ? kthread+0x0/0x62 [ 743.542110] [c10036cb] kernel_thread_helper+0x7/0x10 [ 743.542113] ---[ end trace 9ed00f8504e5c157 ]--- [ 743.542118] kobject_add_internal failed for i2c-2 with -EEXIST, don't try to register things with the same name in the same directory. [ 743.542122] Pid: 4043, comm: kdvb-ad-0-fe-0 Tainted: GW 2.6.29 #1 [ 743.542124] Call Trace: [ 743.542126] [c114d893] kobject_add_internal+0x11c/0x154 [ 743.542130] [c114d976] kobject_add_varg+0x35/0x41 [ 743.542133] [c114dce8] kobject_add+0x49/0x4f [ 743.542135] [c11d8669] device_add+0x73/0x40d [ 743.542138] [c114d5a2] ? kobject_init_internal+0x12/0x28 [ 743.542141] [c114d60a] ? kobject_init+0x35/0x5a [ 743.542144] [c11d8a15] device_register+0x12/0x15 [ 743.542147] [c11dddbb] _request_firmware+0x177/0x346 [ 743.542151] [c11de003] request_firmware+0xa/0xc [ 743.542155] [f7d86525] cx24116_cmd_execute+0xa5/0x528 [cx24116] [ 743.542159] [c12a8d59] ? bit_xfer+0x391/0x39c [ 743.542163] [f7d870fd] cx24116_sleep+0x40/0x82 [cx24116] [ 743.542166] [f7d8f0b6] ? isl6421_set_voltage+0x5f/0x6c [isl6421] [ 743.542175] [f7d5e3bd] dvb_frontend_thread+0x44c/0x480 [dvb_core] [ 743.542179] [c1035405] ? autoremove_wake_function+0x0/0x33 [ 743.542188] [f7d5df71] ? dvb_frontend_thread+0x0/0x480 [dvb_core] [ 743.542192] [c1035331] kthread+0x3b/0x62 [ 743.542195] [c10352f6] ? kthread+0x0/0x62 [ 743.542198] [c10036cb] kernel_thread_helper+0x7/0x10 [ 743.542201] i2c-adapter i2c-2: fw_register_device: device_register failed [ 743.542204] cx24116_firmware_ondemand: Waiting for firmware upload(2)... [ 743.542206] cx24116_firmware_ondemand: No firmware uploaded (timeout or file not found?) [ 743.542209] cx24116_cmd_execute(): Unable initialise the firmware - -- 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
Re: Can't load firmware - HVR4000
On Sat, Mar 28, 2009 at 11:12 PM, Lars Fredriksson l...@hansson.se wrote: Hi! I have recently moved my HVR4000 to a new machine, but now I can't load the firmware :-( I'm running Gentoo 2008.0, kernel 2.6.29 and I've tried both with the drivers included in the kernel and with v4l-drivers outside the kernel but I get the same result :-( When the machine starts up it loads the correct modules and I get a /dev/dvb/adapter0, but when I for example tries to do a scan I get an error message that it can't load the firmware (see the end of this mail) - what can I have done wrong, is there something with my kernel maybe? I have the firmware in /lib/firmware and I've tried with two different firmwares, one of them is the one I used eralier on the other installation ... Any hints? disable i2c-dev in the kernel ... or blacklist it from loading. Markus Best regards, Lars Fredriksson dmesg output; - [ 743.541920] cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)... [ 743.541927] i2c-adapter i2c-2: firmware: requesting dvb-fe-cx24116.fw [ 743.541945] [ cut here ] [ 743.541948] WARNING: at fs/sysfs/dir.c:462 sysfs_add_one+0x2a/0x36() [ 743.541950] Hardware name: M61SME-S2L [ 743.541952] sysfs: duplicate filename 'i2c-2' can not be created [ 743.541954] Modules linked in: cx22702 isl6421 cx24116 cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core wm8775 tuner_simple tuner_types tda9887 tda8290 tuner cx8800 cx88_alsa cx8802 cx88xx ir_common v4l2_common videodev v4l1_compat tveeprom videobuf_dma_sg videobuf_core btcx_risc [ 743.541972] Pid: 4043, comm: kdvb-ad-0-fe-0 Tainted: G W 2.6.29 #1 [ 743.541974] Call Trace: [ 743.541980] [c102580b] warn_slowpath+0x74/0x8a [ 743.541985] [c114cc4d] ? idr_get_empty_slot+0x155/0x230 [ 743.541989] [c114cdfe] ? ida_get_new_above+0xd6/0x153 [ 743.541993] [c108ef1b] ? wait_on_inode+0x24/0x2a [ 743.541996] [c108efd6] ? ifind+0x45/0x57 [ 743.542000] [c10bbbe1] sysfs_add_one+0x2a/0x36 [ 743.542014] [c10bc050] create_dir+0x43/0x68 [ 743.542017] [c10bc0a2] sysfs_create_dir+0x2d/0x41 [ 743.542021] [c114d772] ? kobject_get+0x12/0x17 [ 743.542024] [c114d827] kobject_add_internal+0xb0/0x154 [ 743.542027] [c114d976] kobject_add_varg+0x35/0x41 [ 743.542030] [c114dce8] kobject_add+0x49/0x4f [ 743.542034] [c11d8669] device_add+0x73/0x40d [ 743.542037] [c114d5a2] ? kobject_init_internal+0x12/0x28 [ 743.542040] [c114d60a] ? kobject_init+0x35/0x5a [ 743.542043] [c11d8a15] device_register+0x12/0x15 [ 743.542046] [c11dddbb] _request_firmware+0x177/0x346 [ 743.542051] [c11de003] request_firmware+0xa/0xc [ 743.542056] [f7d86525] cx24116_cmd_execute+0xa5/0x528 [cx24116] [ 743.542063] [c12a8d59] ? bit_xfer+0x391/0x39c [ 743.542067] [f7d870fd] cx24116_sleep+0x40/0x82 [cx24116] [ 743.542071] [f7d8f0b6] ? isl6421_set_voltage+0x5f/0x6c [isl6421] [ 743.542084] [f7d5e3bd] dvb_frontend_thread+0x44c/0x480 [dvb_core] [ 743.542089] [c1035405] ? autoremove_wake_function+0x0/0x33 [ 743.542099] [f7d5df71] ? dvb_frontend_thread+0x0/0x480 [dvb_core] [ 743.542103] [c1035331] kthread+0x3b/0x62 [ 743.542106] [c10352f6] ? kthread+0x0/0x62 [ 743.542110] [c10036cb] kernel_thread_helper+0x7/0x10 [ 743.542113] ---[ end trace 9ed00f8504e5c157 ]--- [ 743.542118] kobject_add_internal failed for i2c-2 with -EEXIST, don't try to register things with the same name in the same directory. [ 743.542122] Pid: 4043, comm: kdvb-ad-0-fe-0 Tainted: G W 2.6.29 #1 [ 743.542124] Call Trace: [ 743.542126] [c114d893] kobject_add_internal+0x11c/0x154 [ 743.542130] [c114d976] kobject_add_varg+0x35/0x41 [ 743.542133] [c114dce8] kobject_add+0x49/0x4f [ 743.542135] [c11d8669] device_add+0x73/0x40d [ 743.542138] [c114d5a2] ? kobject_init_internal+0x12/0x28 [ 743.542141] [c114d60a] ? kobject_init+0x35/0x5a [ 743.542144] [c11d8a15] device_register+0x12/0x15 [ 743.542147] [c11dddbb] _request_firmware+0x177/0x346 [ 743.542151] [c11de003] request_firmware+0xa/0xc [ 743.542155] [f7d86525] cx24116_cmd_execute+0xa5/0x528 [cx24116] [ 743.542159] [c12a8d59] ? bit_xfer+0x391/0x39c [ 743.542163] [f7d870fd] cx24116_sleep+0x40/0x82 [cx24116] [ 743.542166] [f7d8f0b6] ? isl6421_set_voltage+0x5f/0x6c [isl6421] [ 743.542175] [f7d5e3bd] dvb_frontend_thread+0x44c/0x480 [dvb_core] [ 743.542179] [c1035405] ? autoremove_wake_function+0x0/0x33 [ 743.542188] [f7d5df71] ? dvb_frontend_thread+0x0/0x480 [dvb_core] [ 743.542192] [c1035331] kthread+0x3b/0x62 [ 743.542195] [c10352f6] ? kthread+0x0/0x62 [ 743.542198] [c10036cb] kernel_thread_helper+0x7/0x10 [ 743.542201] i2c-adapter i2c-2: fw_register_device: device_register failed [ 743.542204] cx24116_firmware_ondemand: Waiting for firmware upload(2)... [ 743.542206] cx24116_firmware_ondemand: No firmware uploaded (timeout or file not found?) [ 743.542209]
Re: Can't load firmware - HVR4000
Thanks a lot! The firmware loads correctly now! Markus Rechberger skrev: On Sat, Mar 28, 2009 at 11:12 PM, Lars Fredriksson l...@hansson.se wrote: Hi! I have recently moved my HVR4000 to a new machine, but now I can't load the firmware :-( I'm running Gentoo 2008.0, kernel 2.6.29 and I've tried both with the drivers included in the kernel and with v4l-drivers outside the kernel but I get the same result :-( When the machine starts up it loads the correct modules and I get a /dev/dvb/adapter0, but when I for example tries to do a scan I get an error message that it can't load the firmware (see the end of this mail) - what can I have done wrong, is there something with my kernel maybe? I have the firmware in /lib/firmware and I've tried with two different firmwares, one of them is the one I used eralier on the other installation ... Any hints? disable i2c-dev in the kernel ... or blacklist it from loading. Markus Best regards, Lars Fredriksson dmesg output; - [ 743.541920] cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)... [ 743.541927] i2c-adapter i2c-2: firmware: requesting dvb-fe-cx24116.fw [ 743.541945] [ cut here ] [ 743.541948] WARNING: at fs/sysfs/dir.c:462 sysfs_add_one+0x2a/0x36() [ 743.541950] Hardware name: M61SME-S2L [ 743.541952] sysfs: duplicate filename 'i2c-2' can not be created [ 743.541954] Modules linked in: cx22702 isl6421 cx24116 cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core wm8775 tuner_simple tuner_types tda9887 tda8290 tuner cx8800 cx88_alsa cx8802 cx88xx ir_common v4l2_common videodev v4l1_compat tveeprom videobuf_dma_sg videobuf_core btcx_risc [ 743.541972] Pid: 4043, comm: kdvb-ad-0-fe-0 Tainted: GW 2.6.29 #1 [ 743.541974] Call Trace: [ 743.541980] [c102580b] warn_slowpath+0x74/0x8a [ 743.541985] [c114cc4d] ? idr_get_empty_slot+0x155/0x230 [ 743.541989] [c114cdfe] ? ida_get_new_above+0xd6/0x153 [ 743.541993] [c108ef1b] ? wait_on_inode+0x24/0x2a [ 743.541996] [c108efd6] ? ifind+0x45/0x57 [ 743.542000] [c10bbbe1] sysfs_add_one+0x2a/0x36 [ 743.542014] [c10bc050] create_dir+0x43/0x68 [ 743.542017] [c10bc0a2] sysfs_create_dir+0x2d/0x41 [ 743.542021] [c114d772] ? kobject_get+0x12/0x17 [ 743.542024] [c114d827] kobject_add_internal+0xb0/0x154 [ 743.542027] [c114d976] kobject_add_varg+0x35/0x41 [ 743.542030] [c114dce8] kobject_add+0x49/0x4f [ 743.542034] [c11d8669] device_add+0x73/0x40d [ 743.542037] [c114d5a2] ? kobject_init_internal+0x12/0x28 [ 743.542040] [c114d60a] ? kobject_init+0x35/0x5a [ 743.542043] [c11d8a15] device_register+0x12/0x15 [ 743.542046] [c11dddbb] _request_firmware+0x177/0x346 [ 743.542051] [c11de003] request_firmware+0xa/0xc [ 743.542056] [f7d86525] cx24116_cmd_execute+0xa5/0x528 [cx24116] [ 743.542063] [c12a8d59] ? bit_xfer+0x391/0x39c [ 743.542067] [f7d870fd] cx24116_sleep+0x40/0x82 [cx24116] [ 743.542071] [f7d8f0b6] ? isl6421_set_voltage+0x5f/0x6c [isl6421] [ 743.542084] [f7d5e3bd] dvb_frontend_thread+0x44c/0x480 [dvb_core] [ 743.542089] [c1035405] ? autoremove_wake_function+0x0/0x33 [ 743.542099] [f7d5df71] ? dvb_frontend_thread+0x0/0x480 [dvb_core] [ 743.542103] [c1035331] kthread+0x3b/0x62 [ 743.542106] [c10352f6] ? kthread+0x0/0x62 [ 743.542110] [c10036cb] kernel_thread_helper+0x7/0x10 [ 743.542113] ---[ end trace 9ed00f8504e5c157 ]--- [ 743.542118] kobject_add_internal failed for i2c-2 with -EEXIST, don't try to register things with the same name in the same directory. [ 743.542122] Pid: 4043, comm: kdvb-ad-0-fe-0 Tainted: GW 2.6.29 #1 [ 743.542124] Call Trace: [ 743.542126] [c114d893] kobject_add_internal+0x11c/0x154 [ 743.542130] [c114d976] kobject_add_varg+0x35/0x41 [ 743.542133] [c114dce8] kobject_add+0x49/0x4f [ 743.542135] [c11d8669] device_add+0x73/0x40d [ 743.542138] [c114d5a2] ? kobject_init_internal+0x12/0x28 [ 743.542141] [c114d60a] ? kobject_init+0x35/0x5a [ 743.542144] [c11d8a15] device_register+0x12/0x15 [ 743.542147] [c11dddbb] _request_firmware+0x177/0x346 [ 743.542151] [c11de003] request_firmware+0xa/0xc [ 743.542155] [f7d86525] cx24116_cmd_execute+0xa5/0x528 [cx24116] [ 743.542159] [c12a8d59] ? bit_xfer+0x391/0x39c [ 743.542163] [f7d870fd] cx24116_sleep+0x40/0x82 [cx24116] [ 743.542166] [f7d8f0b6] ? isl6421_set_voltage+0x5f/0x6c [isl6421] [ 743.542175] [f7d5e3bd] dvb_frontend_thread+0x44c/0x480 [dvb_core] [ 743.542179] [c1035405] ? autoremove_wake_function+0x0/0x33 [ 743.542188] [f7d5df71] ? dvb_frontend_thread+0x0/0x480 [dvb_core] [ 743.542192] [c1035331] kthread+0x3b/0x62 [ 743.542195] [c10352f6] ? kthread+0x0/0x62 [ 743.542198] [c10036cb] kernel_thread_helper+0x7/0x10 [ 743.542201] i2c-adapter i2c-2: fw_register_device: device_register failed [ 743.542204] cx24116_firmware_ondemand: Waiting for firmware upload(2)... [ 743.542206] cx24116_firmware_ondemand: No firmware uploaded (timeout or file not found?) [ 743.542209]
Re: read() behavior
On Sat, 2009-03-28 at 16:00 -0700, Steve Harrington wrote: In general read(2) is not guaranteed to return a complete record. Especially in non-blocking I/O mode. For section reads from the demux device the amount of data returned will almost certainly be less than requested. I've never seen a section longer than a single TS packet and the recommended length for a read is 4096 bytes. The questions: are the v4l-dvb drivers guaranteed to return a complete section for each read? Well, the spec says it *tries* to return 1 whole one. From the Linux DVB API spec, Section 3.2.3 read() (from the demux): When returning section data the driver always tries to return a complete single section (even though buf would provide buffer space for more data). If the size of the buffer is smaller than the section as much as possible will be returned, and the remaining data will be provided in subsequent calls. The size of the internal buffer is 2 * 4096 bytes (the size of two maximum sized sections) by default. If not, is there a preferred method to reassemble split sections? 1. Open the device node in non-blocking IO mode. 2. In a loop select() or poll() for when the device has data available. It may be prudent to set a timeout here, so your program won't hang forever, if something goes wrong. 3. Read() as much data as you can or care to read, when the device is ready. Don't forget trap error conditions: select() timed out, select() was interrupted, read() was interrupted, read() was at the end-of-file/stream, or all the other wonderful errno's on the read() man page. 4. Shovel the data somewhere, keeping track of the bytes you've read in. (buffer management happens here in your program) 5. Call a function to check if you have enough bytes to do something useful (i.e. a section's worth). 6. If you've got enough bytes to do something useful, call the function to drain off some of the bytes you've captured and do something useful with the bytes. (buffer management happens here in your program) 7. Go back to the beginning of the loop (#2) or check some exit condition that you care about and drop out of the loop. Nothing sepcial; just textbook, single-threaded, Unix. Regards, Andy -- 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
[pull] http://linuxtv.org/hg/~tap/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~tap/v4l-dvb for the following 14 changesets: 01/14: build: Fix kernel output directory support http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=346bab8698ea 02/14: v4l2-ioctl: Check format for S_PARM and G_PARM http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=44632c5fe5b2 03/14: saa7146: Remove buffer type check from vidioc_g_parm http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c879e8f8c32b 04/14: bttv: Remove buffer type check from vidioc_g_parm http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=935d095cbc31 05/14: gspca: Stop setting buffer type, and avoid memset in querycap http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=089aaa41d473 06/14: omap24xxcam: Remove buffer type check from vidioc_s/g_parm http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c545d5d1afcc 07/14: stkwebcam: Remove buffer type check from g_parm and q/dq/reqbufs http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=fb30bf07ca40 08/14: vino: Remove code for things already done by video_ioctl2 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=900a6e99e7b0 09/14: cafe_ccic: Remove buffer type check from XXXbuf http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=e698f5e2e1db 10/14: cx23885-417: Don't need to zero ioctl parameter fields http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=76e7154479e4 11/14: cx88-blackbird: Stop setting buffer type in XXX_fmt_vid_cap http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=ea402dd306a6 12/14: meye: Remove buffer type checks from XXX_fmt_vid_cap, XXXbuf http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=1d2ae100255d 13/14: usbvision: Remove buffer type checks from enum_fmt_vid_cap, XXXbuf http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=5dd6945acfc3 14/14: zr364xx: Remove code for things already done by video_ioctl2 http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=406c54139ea6 linux/drivers/media/common/saa7146_video.c|4 linux/drivers/media/video/bt8xx/bttv-driver.c |3 linux/drivers/media/video/cafe_ccic.c | 14 linux/drivers/media/video/cx23885/cx23885-417.c | 29 - linux/drivers/media/video/cx88/cx88-blackbird.c |5 linux/drivers/media/video/gspca/gspca.c |5 linux/drivers/media/video/meye.c | 32 - linux/drivers/media/video/omap24xxcam.c |7 linux/drivers/media/video/stk-webcam.c| 11 linux/drivers/media/video/usbvision/usbvision-video.c | 10 linux/drivers/media/video/v4l2-ioctl.c|7 linux/drivers/media/video/vino.c | 335 +++--- linux/drivers/media/video/zr364xx.c | 16 v4l/Makefile |3 14 files changed, 158 insertions(+), 323 deletions(-) Thanks, Trent -- 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: Problems with Hauppauge HVR 1600 and cx18 driver
On Mon, 2009-03-23 at 06:52 -0700, Corey Taylor wrote: Andy, I am noticing an improvement in pixelation by setting the bufsize to 64k. I will monitor over the next week and report back. I am running 3 HVR-1600s and the IRQs are coming up shared with the USB which also supports my HD PVR capture device. Monday nights are usually one of the busier nights for recording so I will know how well this holds up. Thanks for the tip! Brandon Hi Andy and Brandon, I too tried various different bufsizes as suggested and I still see very noticeable pixelation/tearing regardless of the setting. I even upgraded my motherboard this past weekend to an Asus AM2+ board with Phenon II X3 CPU. Still the same problems with the card in a brand new setup. I also tried modifying the cx18 source code as Andy suggested and that made more debug warning show up in my syslog, but still did not resolve the issue. Haven't tried this yet with the new motherboard though. Is it possible that this card is more sensitive to hiccups in the signal coming from the cable line? Or interference from other close-by cables and electronic equipment? When recording/watching Live TV through MythTV, I see that ffmpeg is constantly outputting various errors related to the video stream. I can post those here if you think it's relevant. Shoud I just return this card and get one with a different chipset? Or do you think driver updates can solve the issue? I'm happy to hold on to this card if it means I can contribute in some way to fixing the problem, if it's fixable : ) Corey and Brandon, I found a race condition between the cx driver and the CX23418 firmware. I have a patch that mitigates the problem here: http://linuxtv.org/hg/~awalls/cx18/rev/9f5f44e0ce6c I think the final form of the patch could be better. However, this patch essentially eliminated any artifacts I was getting playing back digital TV. I also had positive results running mplayer without the -cache command line for both digital and analog captures. I haven't tested on a single processor machine, nor in a multicard setup, but things looked good enough that I thought it ready for test by others. Let me know if it helps or not. Regards, Andy -- 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
