Re: [PATCH] [0905_14] Siano: USB - move the device id table to the cards module
Em Thu, 14 May 2009 12:29:35 -0700 (PDT)
Uri Shkolnik uri...@yahoo.com escreveu:
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1242325466 -10800
# Node ID fe5ecbb828340406923d06b4ea93a210aafb5c7e
# Parent 5a6de44c39c9198bc1af79f5901dc769690885de
[0905_14] Siano: USB - move the device id table to the cards module
From: Uri Shkolnik u...@siano-ms.com
The card modules is the component which handles various targets,
so the IDs table should reside within it.
The idea of moving it to sms-cards.c is interesting, however, I don't think
this will work fine, since having the usb probing code at one module and the
table on another will break for udev.
Also, by applying this patch, module loader would be broken:
WARNING: smsusb_id_table [/home/v4l/master/v4l/smsusb.ko] undefined!
I can see a few alternatives:
1) keep as-is;
2) move usb init code to sms-cards;
3) break sms-cards into smaller files, like sms-cards-usb (for usb devices);
4) having the table declared as static into some header file.
Due to that, I'll have to skip a few patches that are ok (the ones that are
just adding newer devices at the table).
Cheers,
Mauro.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 5a6de44c39c9 -r fe5ecbb82834 linux/drivers/media/dvb/siano/sms-cards.c
--- a/linux/drivers/media/dvb/siano/sms-cards.c Thu May 14 21:14:46
2009 +0300
+++ b/linux/drivers/media/dvb/siano/sms-cards.c Thu May 14 21:24:26
2009 +0300
@@ -18,6 +18,51 @@
*/
#include sms-cards.h
+
+struct usb_device_id smsusb_id_table[] = {
+ { USB_DEVICE(0x187f, 0x0010),
+ .driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
+ { USB_DEVICE(0x187f, 0x0100),
+ .driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
+ { USB_DEVICE(0x187f, 0x0200),
+ .driver_info = SMS1XXX_BOARD_SIANO_NOVA_A },
+ { USB_DEVICE(0x187f, 0x0201),
+ .driver_info = SMS1XXX_BOARD_SIANO_NOVA_B },
+ { USB_DEVICE(0x187f, 0x0300),
+ .driver_info = SMS1XXX_BOARD_SIANO_VEGA },
+ { USB_DEVICE(0x2040, 0x1700),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_CATAMOUNT },
+ { USB_DEVICE(0x2040, 0x1800),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_OKEMO_A },
+ { USB_DEVICE(0x2040, 0x1801),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_OKEMO_B },
+ { USB_DEVICE(0x2040, 0x2000),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
+ { USB_DEVICE(0x2040, 0x2009),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2 },
+ { USB_DEVICE(0x2040, 0x200a),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
+ { USB_DEVICE(0x2040, 0x2010),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
+ { USB_DEVICE(0x2040, 0x2011),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
+ { USB_DEVICE(0x2040, 0x2019),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD },
+ { USB_DEVICE(0x2040, 0x5500),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+ { USB_DEVICE(0x2040, 0x5510),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+ { USB_DEVICE(0x2040, 0x5520),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+ { USB_DEVICE(0x2040, 0x5530),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+ { USB_DEVICE(0x2040, 0x5580),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+ { USB_DEVICE(0x2040, 0x5590),
+ .driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(usb, smsusb_id_table);
static int sms_dbg;
module_param_named(cards_dbg, sms_dbg, int, 0644);
diff -r 5a6de44c39c9 -r fe5ecbb82834 linux/drivers/media/dvb/siano/sms-cards.h
--- a/linux/drivers/media/dvb/siano/sms-cards.h Thu May 14 21:14:46
2009 +0300
+++ b/linux/drivers/media/dvb/siano/sms-cards.h Thu May 14 21:24:26
2009 +0300
@@ -45,6 +45,8 @@ struct sms_board {
struct sms_board *sms_get_board(int id);
+extern struct usb_device_id smsusb_id_table[];
+
int sms_board_setup(struct smscore_device_t *coredev);
#define SMS_LED_OFF 0
diff -r 5a6de44c39c9 -r fe5ecbb82834 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.c Thu May 14 21:14:46 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsusb.c Thu May 14 21:24:26 2009 +0300
@@ -488,53 +488,6 @@ static int smsusb_resume(struct usb_inte
return 0;
}
-struct usb_device_id smsusb_id_table[] = {
-#ifdef CONFIG_DVB_SIANO_SMS1XXX_SMS_IDS
- { USB_DEVICE(0x187f, 0x0010),
- .driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
- { USB_DEVICE(0x187f, 0x0100),
- .driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
- { USB_DEVICE(0x187f, 0x0200),
- .driver_info =
Re: [PATCH]saa7134-video.c: poll method lose race condition
On Mon, 2009-05-18 at 08:28 +0200, Guennadi Liakhovetski wrote: Guennadi hi,Guennadi, I am sorry that it is my mistake. Figo.zhang -- 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 - Capturing uncompressed data
It depends on the camera. ...and the driver. I don't know much about various _web_cameras and their drivers, but I could well imagine, that you're asking for an unsupported YUV variation, whereas some other format would be supported. Why don't you use VIDIOC_ENUM_FMT to list all supported formats? Or even look in the driver source - it's open Hi, Thanks for your answer. I didn't try ENUM_FMT but I tried to set every available format of V4L2 (that we can found in the videodev2.h), but the only one possible is the compressed JPEG Format. You said to look in the driver source, but where exactly do I have to look for ? Thank you for your time, Regards, Guillaume. -- 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] [0905_23] Siano: gpio - use new implementation
Em Sun, 17 May 2009 01:57:45 -0700 (PDT)
Uri Shkolnik uri...@yahoo.com escreveu:
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1242331325 -10800
# Node ID 415ca02f74b960c02ddfa7ee719cf87726d97490
# Parent 8b645aa2ab13f22b8d4dcd8e6353fce2c976cd34
[0905_23] Siano: gpio - use new implementation
From: Uri Shkolnik u...@siano-ms.com
Start using the corrected gpio implementation
Hmm...
WARNING: smscore_configure_gpio [/home/v4l/master/v4l/sms1xxx.ko] undefined!
WARNING: smscore_set_gpio [/home/v4l/master/v4l/sms1xxx.ko] undefined!
Those functions weren't defined on any module. It seems that you forgot to
submit a previous patch.
Also, since Hauppauge complained about the gpio changes, I'd like to have
Michael's ack, especially if the patch affects the behavior of the existing
Hauppauge supported boards.
Cheers,
Mauro.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 8b645aa2ab13 -r 415ca02f74b9 linux/drivers/media/dvb/siano/sms-cards.c
--- a/linux/drivers/media/dvb/siano/sms-cards.c Thu May 14 22:28:38
2009 +0300
+++ b/linux/drivers/media/dvb/siano/sms-cards.c Thu May 14 23:02:05
2009 +0300
@@ -17,6 +17,7 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include smscoreapi.h
#include sms-cards.h
#include smsir.h
@@ -155,6 +156,174 @@ struct sms_board *sms_get_board(int id)
}
EXPORT_SYMBOL_GPL(sms_get_board);
+static inline void sms_gpio_assign_11xx_default_led_config(
+ struct smscore_gpio_config *pGpioConfig) {
+ pGpioConfig-Direction = SMS_GPIO_DIRECTION_OUTPUT;
+ pGpioConfig-InputCharacteristics =
+ SMS_GPIO_INPUTCHARACTERISTICS_NORMAL;
+ pGpioConfig-OutputDriving = SMS_GPIO_OUTPUTDRIVING_4mA;
+ pGpioConfig-OutputSlewRate = SMS_GPIO_OUTPUTSLEWRATE_0_45_V_NS;
+ pGpioConfig-PullUpDown = SMS_GPIO_PULLUPDOWN_NONE;
+}
+
+int sms_board_event(struct smscore_device_t *coredev,
+ enum SMS_BOARD_EVENTS gevent) {
+ int board_id = smscore_get_board_id(coredev);
+ struct sms_board *board = sms_get_board(board_id);
+ struct smscore_gpio_config MyGpioConfig;
+
+ sms_gpio_assign_11xx_default_led_config(MyGpioConfig);
+
+ switch (gevent) {
+ case BOARD_EVENT_POWER_INIT: /* including hotplug */
+ switch (board_id) {
+ case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
+ /* set I/O and turn off all LEDs */
+ smscore_gpio_configure(coredev,
+ board-board_cfg.leds_power,
+ MyGpioConfig);
+ smscore_gpio_set_level(coredev,
+ board-board_cfg.leds_power, 0);
+ smscore_gpio_configure(coredev, board-board_cfg.led0,
+ MyGpioConfig);
+ smscore_gpio_set_level(coredev,
+ board-board_cfg.led0, 0);
+ smscore_gpio_configure(coredev, board-board_cfg.led1,
+ MyGpioConfig);
+ smscore_gpio_set_level(coredev,
+ board-board_cfg.led1, 0);
+ break;
+ case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
+ case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD:
+ /* set I/O and turn off LNA */
+ smscore_gpio_configure(coredev,
+ board-board_cfg.foreign_lna0_ctrl,
+ MyGpioConfig);
+ smscore_gpio_set_level(coredev,
+ board-board_cfg.foreign_lna0_ctrl,
+ 0);
+ break;
+ }
+ break; /* BOARD_EVENT_BIND */
+
+ case BOARD_EVENT_POWER_SUSPEND:
+ switch (board_id) {
+ case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
+ smscore_gpio_set_level(coredev,
+ board-board_cfg.leds_power, 0);
+ smscore_gpio_set_level(coredev,
+ board-board_cfg.led0, 0);
+ smscore_gpio_set_level(coredev,
+ board-board_cfg.led1, 0);
+ break;
+ case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
+ case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD:
+ smscore_gpio_set_level(coredev,
+ board-board_cfg.foreign_lna0_ctrl,
+ 0);
+ break;
+ }
+ break; /* BOARD_EVENT_POWER_SUSPEND */
+
+ case BOARD_EVENT_POWER_RESUME:
+ switch (board_id) {
+ case
Re: [PATCH 0/8] ir-kbd-i2c conversion to the new i2c binding model (v3)
On Sun, 17 May 2009 16:55:54 -0500 (CDT), Mike Isely wrote: On Wednesday 13 of May 2009 at 21:45:59, Jean Delvare wrote: Here comes an update of my conversion of ir-kbd-i2c to the new i2c binding model. I've split it into 8 pieces for easier review. Firstly there is 1 preliminary patch: (...) I tried the all-in-one patch here on a PVR-USB2 24xxx model (slightly older v4l-dvb repo and 2.6.27.13 vanilla kernel) and it worked fine. I'll add an acked-by to the corresponding (trivial) pvrusb2 patch that you've posted. Thanks for the testing Mike. Mauro, I think it's time to add these patches to the v4l-dvb repository so that they get broader testing. -- Jean Delvare -- 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 - Capturing uncompressed data
Guillaume Kowaio at gmail.com writes: I just tried the ENUM_FMT, and there is only 1 format, the JPEG one. But I don't understand one thing. The webcam displays compressed Jpeg data. OK. But before that compression, the data aren't in uncompressed data ? It's the driver or something which is doing that compression directly during the capture, but there really are no chance to get that uncompressed data before compression in JPEG ? -- 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] cx23885: support for card Mygica X8506 DMB-TH
This patch add cx23885 support for card Mygica X8506 DMB-TH.
It should work on Magic-Pro ProHDTV Extreme as well, as they are
same hardware with different branding.
Cheers,
David T.L. Wong
diff -r c9e2fbabed11 linux/drivers/media/video/cx23885/cx23885-cards.c
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c Mon May 18 15:14:03 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c Mon May 18 15:53:25 2009 +0800
@@ -198,6 +198,10 @@
.name = Hauppauge WinTV-HVR1210,
.portc = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_MYGICA_X8506] = {
+ .name = Mygica X8506 DMB-TH,
+ .portb = CX23885_MPEG_DVB,
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -317,6 +321,10 @@
.subvendor = 0x0070,
.subdevice = 0x2295,
.card = CX23885_BOARD_HAUPPAUGE_HVR1210,
+ }, {
+ .subvendor = 0x14f1,
+ .subdevice = 0x8651,
+ .card = CX23885_BOARD_MYGICA_X8506,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -707,6 +715,15 @@
mdelay(20);
cx23885_gpio_set(dev, GPIO_9);
break;
+ case CX23885_BOARD_MYGICA_X8506:
+ /* GPIO-1 reset XC5000 */
+ /* GPIO-2 reset LGS8GL5 */
+ cx_set(GP0_IO, 0x0006);
+ cx_clear(GP0_IO, 0x0006);
+ mdelay(100);
+ cx_set(GP0_IO, 0x00060006);
+ mdelay(100);
+ break;
}
}
@@ -810,6 +827,11 @@
ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts2-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
+ case CX23885_BOARD_MYGICA_X8506:
+ ts1-gen_ctrl_val = 0x5; /* Parallel */
+ ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
+ ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+ break;
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_HAUPPAUGE_HVR1500:
case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
diff -r c9e2fbabed11 linux/drivers/media/video/cx23885/cx23885-dvb.c
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c Mon May 18 15:14:03 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c Mon May 18 15:53:25 2009 +0800
@@ -50,6 +50,7 @@
#include lnbh24.h
#include cx24116.h
#include cimax2.h
+#include lgs8gxx.h
#include netup-eeprom.h
#include netup-init.h
#include lgdt3305.h
@@ -417,10 +418,29 @@
.demod_address = 0x05,
};
+static struct lgs8gxx_config mygica_x8506_lgs8gl5_config = {
+ .prod = LGS8GXX_PROD_LGS8GL5,
+ .demod_address = 0x19,
+ .serial_ts = 0,
+ .ts_clk_pol = 1,
+ .ts_clk_gated = 1,
+ .if_clk_freq = 30400, /* 30.4 MHz */
+ .if_freq = 5380, /* 5.38 MHz */
+ .if_neg_center = 1,
+ .ext_adc = 0,
+ .adc_signed = 0,
+ .if_neg_edge = 0,
+};
+
+static struct xc5000_config mygica_x8506_xc5000_config = {
+ .i2c_address = 0x61,
+ .if_khz = 5380,
+};
+
static int dvb_register(struct cx23885_tsport *port)
{
struct cx23885_dev *dev = port-dev;
- struct cx23885_i2c *i2c_bus = NULL;
+ struct cx23885_i2c *i2c_bus = NULL, *i2c_bus2 = NULL;
struct videobuf_dvb_frontend *fe0;
int ret;
@@ -742,6 +762,19 @@
break;
}
break;
+ case CX23885_BOARD_MYGICA_X8506:
+ i2c_bus = dev-i2c_bus[0];
+ i2c_bus2 = dev-i2c_bus[1];
+ fe0-dvb.frontend = dvb_attach(lgs8gxx_attach,
+ mygica_x8506_lgs8gl5_config,
+ i2c_bus-i2c_adap);
+ if (fe0-dvb.frontend != NULL) {
+ dvb_attach(xc5000_attach,
+fe0-dvb.frontend,
+i2c_bus2-i2c_adap,
+mygica_x8506_xc5000_config);
+ }
+ break;
default:
printk(KERN_INFO %s: The frontend of your DVB/ATSC card
isn't supported yet\n,
diff -r c9e2fbabed11 linux/drivers/media/video/cx23885/cx23885.h
--- a/linux/drivers/media/video/cx23885/cx23885.h Mon May 18 15:14:03 2009 +0800
+++ b/linux/drivers/media/video/cx23885/cx23885.h Mon May 18 15:53:25 2009 +0800
@@ -76,6 +76,7 @@
#define CX23885_BOARD_HAUPPAUGE_HVR127519
#define CX23885_BOARD_HAUPPAUGE_HVR125520
#define CX23885_BOARD_HAUPPAUGE_HVR121021
+#define CX23885_BOARD_MYGICA_X8506 22
#define GPIO_0 0x0001
#define GPIO_1 0x0002
Re: [PATCH] cx23885: support for card Mygica X8506 DMB-TH
Sign-off-by: David T.L. Wong davidtlw...@gmail.com On Mon, May 18, 2009 at 4:25 PM, David Wong davidtlw...@gmail.com wrote: This patch add cx23885 support for card Mygica X8506 DMB-TH. It should work on Magic-Pro ProHDTV Extreme as well, as they are same hardware with different branding. Cheers, David T.L. Wong -- 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
SNR Signal Strength an d BER
I have the good fortune to be the 'lucky' owner of an stb0899/stb6100 based DVB card. Whilst the performance of the card is fine, at least as good as the two other s1 TT cards I have, I find it really frustrating that I can't use it in the way that I can the other two. I use them, together with the femon and rotor plugins, to tune up my roof mounted dishes. with the s1 cards I can see that I am getting closer from the displays, but with the s2.. nothing. I have been keeping my eye on the list for ages hoping that there will be some advancement in this area and although there was quite some discussion in March about the right way to interpret these stats., that dried up at the end of March with nothing further since. I am only a User having no development skills so can't help in that area but I do know that I want measurements that get bigger as dish alignment gets better. I really don't give a knack what units are used. I don't want to start world war 3 ( or even another interminable and seemingly fruitless discussion ) but can someone in the development team tell me what is being done, if anything, to incorporate SNR SS and BER in STB0899/STB6100 drivers. Lets face it these drivers have been around for quite some time and my guess would be that Technotrend cards represent a fair proportion of the total out there. Regards Mike -- 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 - Capturing uncompressed data
Hi Guillaume, On Monday 18 May 2009 09:32:53 Guillaume wrote: Guillaume Kowaio at gmail.com writes: I just tried the ENUM_FMT, and there is only 1 format, the JPEG one. But I don't understand one thing. The webcam displays compressed Jpeg data. OK. But before that compression, the data aren't in uncompressed data ? It's the driver or something which is doing that compression directly during the capture, but there really are no chance to get that uncompressed data before compression in JPEG ? The video stream is compressed directly by the webcam and sent to the host in compressed form. Best regards, Laurent Pinchart -- 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 - Capturing uncompressed data
Laurent Pinchart laurent.pinchart at skynet.be writes: The video stream is compressed directly by the webcam and sent to the host in compressed form. Best regards, Laurent Pinchart I spoke with my supervisor. He'll try to get a camera which allow uncompressed format. In the meantime, and in order to do stop-motion in the application, I need to get the best quality possible of the webcam in one 'shot' (not video, just picture). Is there any way to get the value of compression of the jpeg by the V4L2 in order to do a software extrapolation after. For instance, with some webcams (1.3 millions pixels), you can capture a 640*480 resolution in video mode but some allow pictures in 800*600 by extrapolation. So in order to do that extrapolation, I need the value of compression of the JPEG use by V4L2. Is it always the same, or it depends on the camera ? And can v4l2 get and modify this value ? -- 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: SNR Signal Strength an d BER
Mike Booth schrieb: I am only a User having no development skills so can't help in that area but I do know that I want measurements that get bigger as dish alignment gets better. I really don't give a knack what units are used. Just want to say, that I want SNR and BER, too. I don't care what is displayed, as long as MORE means BETTER and LESS means WORSE. That is enough to set up my dish... Frank -- 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
xc5000 users: new firmware required!
The new xc5000 code was merged this morning, which requires users to update their firmware. If you updated to the latest v4l-dvb and your card stopped working, please download the updated firmware from this location, and install into the same directory as your previous version (typically /lib/firmware). http://www.kernellabs.com/firmware/xc5000/ Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
Hauppauge Nova-TD-500 vs. T-500
Hello, Like many others, I have some problems with the Hauppauge Nova-TD-500. I have been running a Fedora system with one Hauppauge Nova-T-500 (-T-, with one input connector, not -TD-) quite successfully for 2 years. I just built another Fedora system and ordered two T-500 but I actually received two TD-500 (the one with two input connectors). So, I now have another Fedora box with two Hauppauge Nova-TD-500 and it does not work quite well. The two systems (the first one with one T-500 and the second one with two TD-500) are running the same O/S version, same drivers, same firmware: - Fedora 10, up-to-date as of 2009-05-17 - Kernel 2.6.27.21-170.2.56.fc10.i686 - Latest V4L-DVB mercurial tree, same date - Firmware dvb-usb-dib0700-1.20.fw You will find below some outputs of dmesg, lspci, etc for the two systems. I use custom signal monitoring applications, no TV watching apps. The same application is used in both systems, same antenna input (roof antenna and wall socket, not the small antenna that comes with the cards). The application continuously reads the complete transport stream for analysis. From time to time, it tunes to some frequency, then another, etc. With the two TD-500, the 4 adapters are created under /dev/dvb. Using them works more or less. As far as I tested now, I do not have any reported error, no error message. But the input is not good: many packets are corrupted. This does not happen all the time. Sometimes, the input is reasonably correct (a few packets seems incorrect) and sometimes it is a mess (most packets are incorrect, the result of the analysis report many non-existing PIDs, weird content, etc). I guess that most of you will say most probably an application pb... But the same application is working fine with: 1) Linux + Hauppauge Nova-T-500 2) Linux + Hauppauge Nova-T Stick 3) Linux + Pinnacle PCTV stick 72e 4) Windows + the two above sticks 4) Windows + Terratec Cinergy T USB XE Rev 2 (not supported on Linux) Of course, on Windows, the input module is a custom DirectShow capture filter instead of Linux DVB API but the rest of the application is identical. Another weird behaviour: After running the monitoring application, ioctl (frontend_fd, FE_GET_INFO, ...) returns No such device errno. Example: 1) Run tool to get dvb device info, ie. ioctl FE_GET_INFO, right after system boot: /dev/dvb/adapter0 (DiBcom 7000PC, DVB-T) Status: Bit error rate . 2,097,151 (0%) Signal/noise ratio . 0 (0%) Signal strength 0 (0%) Uncorrected blocks . 0 Frequencies: Current .. 0 Hz Min . 45,000,000 Hz Max 860,000,000 Hz Step 62,500 Hz Tolerance 0 Hz Spectral inversion .. auto Bandwidth .. 8-MHz FEC (high priority) .. 1/2 FEC (low priority) ... 1/2 Constellation ... QPSK Transmission mode . 2K Guard interval .. 1/32 Hierarchy ... none 2) Run monitoring application. OK, with corrupted packets. 3) Run previous tool doing ioctl FE_GET_INFO: error getting info on /dev/dvb/adapter0/frontend0: No such device Note: this error is reported by ioctl, opening the device is OK. 4) # ls -l /dev/dvb/adapter0/frontend0 crw-rw+ 1 tlelegard video 212, 3 2009-05-18 15:59 /dev/dvb/adapter0/frontend0 5) Run monitoring application. OK, with corrupted packets. Is there any new development regarding TD-500 ? Any test I could make ? Thanks in advance for your assistance. -Thierry - dmesg - one T-500 - # dmesg | grep -i -e dvb -e dib dib0700: loaded with support for 9 different device-types dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware firmware: requesting dvb-usb-dib0700-1.20.fw dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' dib0700: firmware started successfully. dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 0 frontend 0 (DiBcom 3000MC/P)... dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)... dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. usbcore: registered new interface driver
[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:Mon May 18 19:00:07 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11824:315bc4b65b4f gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc4-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc4-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc4-armv5-omap2: WARNINGS 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: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc4-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc4-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc4-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc4-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: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-rc4-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc4): OK 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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]saa7134-video.c: poll method lose race condition
Hi Figo Zhang,
On Monday 18 of May 2009 at 04:13:13, figo.zhang wrote:
saa7134-video.c: poll method lose race condition
Signed-off-by: Figo.zhang figo.zh...@kolorific.com
---
drivers/media/video/saa7134/saa7134-video.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-video.c
b/drivers/media/video/saa7134/saa7134-video.c index 493cad9..95733df 100644
--- a/drivers/media/video/saa7134/saa7134-video.c
+++ b/drivers/media/video/saa7134/saa7134-video.c
@@ -1423,11 +1423,13 @@ video_poll(struct file *file, struct
poll_table_struct *wait) {
struct saa7134_fh *fh = file-private_data;
struct videobuf_buffer *buf = NULL;
+ unsigned int rc = 0;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type)
return videobuf_poll_stream(file, fh-vbi, wait);
if (res_check(fh,RESOURCE_VIDEO)) {
+ mutex_lock(fh-cap.vb_lock);
if (!list_empty(fh-cap.stream))
buf = list_entry(fh-cap.stream.next, struct
videobuf_buffer, stream);
} else {
@@ -1446,13 +1448,14 @@ video_poll(struct file *file, struct
poll_table_struct *wait) }
if (!buf)
- return POLLERR;
+ rc = POLLERR;
Just one note (I don't know the future and meaning of this patch). The line
above will change the meaning of the buf==NULL check. It will not return
immediately, but call poll_wait with buf-done instead - NULL pointer access.
Cheers,
Oldrich.
poll_wait(file, buf-done, wait);
if (buf-state == VIDEOBUF_DONE ||
buf-state == VIDEOBUF_ERROR)
- return POLLIN|POLLRDNORM;
- return 0;
+ rc = POLLIN|POLLRDNORM;
+ mutex_unlock(fh-cap.vb_lock);
+ return rc;
err:
mutex_unlock(fh-cap.vb_lock);
--
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
--
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
[DVB] compiling av7110 firmware into driver fails
I always compile the current av7110 firmware into my driver, so that I can have different driver/firmware versions to test with. This used to work by doing CONFIG_DVB_AV7110_FIRMWARE=y CONFIG_DVB_AV7110_FIRMWARE_FILE=/home/kls/vdr/firmware/FW.current in the v4l/.config file (where FW.current is a symlink to the current firmware version). With driver version c29ce3e2fc6a (2009-04-25) this still worked, but with 0018ed9bbca3 (2009-05-16) it doesn't work any more. Am I doing something wrong, or has this been broken? Klaus -- 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
no tuning with an hvr-1700
Hello all, I can't find digital channels with an hvr-1700. dvb-scan -a2 /usr/share/dvb/dvb-t/fr-Tours outputs no channel info, only some tuning failed messages. Two hvr-3000 in the same box work flawlessly (both dvb-t and dvb-s). I run v4l-sources (last saturday's snapshot), on a 2.6.28-gentoo-r5 x64 host. The card is recognized as /dev/dvb/adapter2 and firmwares are loaded. I also tried with the hvr-1700 alone and got the same result. Here is some dmesg output with debugging enabled, this shows activity from modprobe and dvb-scan. May 18 22:00:02 hesa3 cx23885 driver version 0.0.2 loaded May 18 22:00:02 hesa3 cx23885 :04:00.0: PCI INT A - Link[LN2A] - GSI 18 (level, low) - IRQ 18 May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_dev_setup() Memory configured for PCIe bridge type 885 May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_init_tsport(portno=2) May 18 22:00:02 hesa3 CORE cx23885[0]: subsystem: 0070:8101, board: Hauppauge WinTV-HVR1700 [card=8,autodetected] May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_pci_quirks() May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_dev_setup() tuner_type = 0x0 tuner_addr = 0x0 May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_dev_setup() radio_type = 0x0 radio_addr = 0x0 May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_reset() May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [VID A] May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch2] May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [TS1 B] May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch4] May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch5] May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup() Configuring channel [TS2 C] May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch7] May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch8] May 18 22:00:02 hesa3 cx23885[0]/0: cx23885_sram_channel_setup() Erasing channel [ch9] May 18 22:00:02 hesa3 tveeprom 7-0050: Hauppauge model 81519, rev B2E9, serial# 6177447 May 18 22:00:02 hesa3 tveeprom 7-0050: MAC address is 00-0D-FE-5E-42-A7 May 18 22:00:02 hesa3 tveeprom 7-0050: tuner model is Philips 18271_8295 (idx 149, type 54) May 18 22:00:02 hesa3 tveeprom 7-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) May 18 22:00:02 hesa3 tveeprom 7-0050: audio processor is CX23885 (idx 39) May 18 22:00:02 hesa3 tveeprom 7-0050: decoder processor is CX23885 (idx 33) May 18 22:00:02 hesa3 tveeprom 7-0050: has no radio May 18 22:00:02 hesa3 cx23885[0]: hauppauge eeprom: model=81519 May 18 22:00:02 hesa3 cx25840 9-0044: cx25 0-21 found @ 0x88 (cx23885[0]) May 18 22:00:02 hesa3 cx25840 9-0044: firmware: requesting v4l-cx23885- avcore-01.fw May 18 22:00:03 hesa3 cx25840 9-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) May 18 22:00:03 hesa3 cx23885_dvb_register() allocating 1 frontend(s) May 18 22:00:03 hesa3 cx23885[0]: cx23885 based dvb card May 18 22:00:03 hesa3 tda829x 8-0042: type set to tda8295 May 18 22:00:03 hesa3 tda18271 8-0060: creating new instance May 18 22:00:03 hesa3 TDA18271HD/C1 detected @ 8-0060 May 18 22:00:05 hesa3 DVB: registering new adapter (cx23885[0]) May 18 22:00:05 hesa3 DVB: registering adapter 2 frontend 0 (NXP TDA10048HN DVB-T)... May 18 22:00:05 hesa3 cx23885_dev_checkrevision() Hardware revision = 0xb0 May 18 22:00:05 hesa3 cx23885[0]/0: found at :04:00.0, rev: 2, irq: 18, latency: 0, mmio: 0xfe80 May 18 22:00:05 hesa3 cx23885 :04:00.0: setting latency timer to 64 -- dvbscan starts here May 18 22:01:55 hesa3 tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... May 18 22:01:55 hesa3 cx23885 :04:00.0: firmware: requesting dvb- fe-tda10048-1.0.fw May 18 22:01:55 hesa3 tda10048_firmware_upload: firmware read 24878 bytes. May 18 22:01:55 hesa3 tda10048_firmware_upload: firmware uploading May 18 22:01:58 hesa3 tda10048_firmware_upload: firmware uploaded Any hints ? Cheers GoM -- 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
ads tech mini tv usb 0631:a371 lost cause or????
Ive been trying to get an ADS tech mini tv usb working with linux does anybody on the list know if this device works at all by any means under linux. Please note yes i have FGI i need current info as a reference im running kubuntu 9.04 and have a copy of WinXP pro dual booting the same machine. -- Robert L 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
LifeView LV3H still brick - some patches
It's more than a year I was triing to help with this hybrid PCI card to get it working (http://lists-archives.org/video4linux/21688-cx88-xc3028-tests-are-required-was-when-xc3028-xc2028-will-be-supported.html). We've got stuck at firmware extraction, which was somehow troublesome, but it was probably not the main problem. The difference to date is that card is identified under linux as Geniatech X8000-MT DVBT which is perfectly fine, as this is OEM Geniatech, but the card is still dead with all those Incorrect readback of firmware version. Some time ago lifeview itself posted on their pages a package they claim is a linux driver for Fedora Core 6 only. http://www.notonlytv.net/download/driver/lv3hlv3afedora.rar Acctually it is a modified snapshot of experimental v4l mercurial repo from 7. Apr 2007. What I did is I compared this package with repo from 7.4.2007 and there seem to be - at least for my unexperienced eyes - some useful things done. See attached diff. My question is - did someone already took a look at it? Make those changes sense? Or.. are they already incorporated upstream? Are they completely outdated/useless now? Thanks for anybody spending a minute looking at it. Adam Pribyl patch2.diff.gz Description: Binary data
Re: no tuning with an hvr-1700
Guillaume Laurès wrote: Hello all, I can't find digital channels with an hvr-1700. dvb-scan -a2 /usr/share/dvb/dvb-t/fr-Tours outputs no channel info, only some tuning failed messages. Two hvr-3000 in the same box work flawlessly (both dvb-t and dvb-s). I run v4l-sources (last saturday's snapshot), on a 2.6.28-gentoo-r5 x64 host. The card is recognized as /dev/dvb/adapter2 and firmwares are loaded. I also tried with the hvr-1700 alone and got the same result. Here is some dmesg output with debugging enabled, this shows activity from modprobe and dvb-scan. ... Any hints ? Clone this tree and try again: http://kernellabs.com/hg/~stoth/tda10048-merge Better, or not? -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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: no tuning with an hvr-1700
Le 18 mai 09 à 23:35, Steven Toth a écrit : Clone this tree and try again: http://kernellabs.com/hg/~stoth/tda10048-merge Better, or not? Unfortunately not :-( dmesg is exactly the same. Thanks, GoM-- 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: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Hi, [snip] From: Benoit Istin beis...@gmail.com There are several months my hvr1110 stop working. This is very simple to fix, for my card revision at least, by setting a missing field to the hauppauge_hvr_1110_config. Hello I see, what i don't remember is, when searching for good parameters for this card (1110), AGC and Co was not necessary... correct me if i'm wrong : patch from Anders impacts cards with .tuner_config=1 what i can do : step 1 : see if we really need .tuner_config = 1 on hvr_1110_config otherwise change to .tuner_config = 0 step 2 : if needed, apply the patch from Anders and look if it's better or not both on analogic and dvb step 3 : report this results others ideas ? Seems I can't find any details about Benoit's eventually different card version in the mail archives. If it turns out we have revisions with LNA and without, we might try to provide a separate entry for the LNA version. Usually on Hauppauge cards we find means doing so. PS : i need times because my multimedia box is on production and i prefer test this on another pc, you know : why change when all is good ? Thanks for your time and no need for hurry. If you keep your old media modules folder, you just can put it back in place later again and depmod -a and you are done. Do make rmmod and delete the new media modules folder previously and you should be 100% back. Cheers, Hermann -- 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] media: one kconfig controls them all
From: Randy Dunlap randy.dun...@oracle.com Add a kconfig symbol that allows someone to disable all multimedia config options at one time. Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/Kconfig | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) --- lnx-2630-rc3.orig/drivers/media/Kconfig +++ lnx-2630-rc3/drivers/media/Kconfig @@ -2,8 +2,14 @@ # Multimedia device configuration # -menu Multimedia devices +menuconfig MEDIA_SUPPORT + tristate Multimedia support depends on HAS_IOMEM + help + If you want to use Video for Linux, DVB for Linux, or DAB adapters, + enable this option and other options below. + +if MEDIA_SUPPORT comment Multimedia core support @@ -136,4 +142,4 @@ config USB_DABUSB module will be called dabusb. endif # DAB -endmenu +endif # MEDIA_SUPPORT -- 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 v2]saa7134-video.c: poll method lose race condition for capture video
saa7134-video.c: poll method lose race condition for capture video.
In v2, when buf == NULL, it will goto err, return PULLERR
immediately.
Signed-off-by: Figo.zhang figo.zh...@kolorific.com
---
drivers/media/video/saa7134/saa7134-video.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-video.c
b/drivers/media/video/saa7134/saa7134-video.c
index 493cad9..b1c2dbd 100644
--- a/drivers/media/video/saa7134/saa7134-video.c
+++ b/drivers/media/video/saa7134/saa7134-video.c
@@ -1423,11 +1423,13 @@ video_poll(struct file *file, struct poll_table_struct
*wait)
{
struct saa7134_fh *fh = file-private_data;
struct videobuf_buffer *buf = NULL;
+ unsigned int rc = 0;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type)
return videobuf_poll_stream(file, fh-vbi, wait);
if (res_check(fh,RESOURCE_VIDEO)) {
+ mutex_lock(fh-cap.vb_lock);
if (!list_empty(fh-cap.stream))
buf = list_entry(fh-cap.stream.next, struct
videobuf_buffer, stream);
} else {
@@ -1446,13 +1448,14 @@ video_poll(struct file *file, struct poll_table_struct
*wait)
}
if (!buf)
- return POLLERR;
+ goto err;
poll_wait(file, buf-done, wait);
if (buf-state == VIDEOBUF_DONE ||
buf-state == VIDEOBUF_ERROR)
- return POLLIN|POLLRDNORM;
- return 0;
+ rc = POLLIN|POLLRDNORM;
+ mutex_unlock(fh-cap.vb_lock);
+ return rc;
err:
mutex_unlock(fh-cap.vb_lock);
--
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 get the firmware dvb-usb-dw3101.fw
I have a usb dvb-c box. But where to get the firmware? I search by google ,but no result __ Information from ESET Smart Security, version of virus signature database 4085 (20090519) __ The message was checked by ESET Smart Security. http://www.eset.com -- 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: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Am Dienstag, den 19.05.2009, 01:04 +0200 schrieb hermann pitton: Hi, [snip] From: Benoit Istin beis...@gmail.com There are several months my hvr1110 stop working. This is very simple to fix, for my card revision at least, by setting a missing field to the hauppauge_hvr_1110_config. Hello I see, what i don't remember is, when searching for good parameters for this card (1110), AGC and Co was not necessary... correct me if i'm wrong : patch from Anders impacts cards with .tuner_config=1 what i can do : step 1 : see if we really need .tuner_config = 1 on hvr_1110_config otherwise change to .tuner_config = 0 step 2 : if needed, apply the patch from Anders and look if it's better or not both on analogic and dvb step 3 : report this results others ideas ? Seems I can't find any details about Benoit's eventually different card version in the mail archives. If it turns out we have revisions with LNA and without, we might try to provide a separate entry for the LNA version. Usually on Hauppauge cards we find means doing so. PS : i need times because my multimedia box is on production and i prefer test this on another pc, you know : why change when all is good ? Thanks for your time and no need for hurry. If you keep your old media modules folder, you just can put it back in place later again and depmod -a and you are done. Do make rmmod and delete the new media modules folder previously and you should be 100% back. ( Guys, please. It looks like this still can go on for some while. I don't have the time and have zero income from all of this. Does the new entity, kernellabs.com, Devin, Mike and Steven for now, do confirm that this bug is assigned to them? (PCTV and Hauppauge) Or do you prefer to have it further drifting over the lists and call Hartmut and me for it? Cheers, Hermann -- 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 00/10 v2] soc-camera conversions
On Fri, May 15, 2009 at 07:18:45PM +0200, Guennadi Liakhovetski wrote: this is the next round of soc-camera conversions. Run-tested on i.MX31, PXA270, SH7722, compile-tested only for i.MX1. It should have been a straight-forward port of the previous version to a more current tree, but then I started converting soc_camera_platform, and things became a bit more complex... As a bonus, now soc-camera can handle not only i2c subdevices, and we can even drop the CONFIG_I2C dependency again. I'll also upload a comlpete stack somewhere a bit later, for example for those, wishing to test it on i.MX31, otherwise the series will not apply cleanly. I'd like to push the first 8 of them asap, 9 and 10 will still have to be reworked Paul, I put you on cc on all patches, because, unfortunately, several of them affect arch/sh. But I'll mention it explicitly in each such patch. Looks ok to me, there shouldn't be any problems with taking these all through the v4l tree. Feel free to add my Acked-by if you like. I guess we will find out in -next if there are any conflicts or not :-) -- 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: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
On Mon, May 18, 2009 at 10:45 PM, hermann pitton hermann-pit...@arcor.de wrote: Guys, please. It looks like this still can go on for some while. I don't have the time and have zero income from all of this. Does the new entity, kernellabs.com, Devin, Mike and Steven for now, do confirm that this bug is assigned to them? (PCTV and Hauppauge) Or do you prefer to have it further drifting over the lists and call Hartmut and me for it? Cheers, Hermann Hello Hermann, I believe it makes sense for me to clarify this point: Kernel Labs is not affiliated with Hauppauge or PCTV in any way. We have not received any money from either company for Linux support for their products. One of Kernel Lab's long-term goals is indeed to find a way to provide some form of commercial support for devices such as this. It is probably fair to say that the three of us tend to focus on products by those vendors because of easy access to sample hardware, not because of any commercial arrangement. That said, Kernel Labs is about as responsible for fixing the problem as you are. ;-) Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
Hi Devin, [snip] That said, Kernel Labs is about as responsible for fixing the problem as you are. ;-) tell me more stories. But OK, heads up then I hope. Cheers, Hermann -- 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 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On
Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hello Hardik,
Reviewing your driver, I found something made me curious.
On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
snip
+/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
+ * called. This is used to setup buffers and return size and count of
+ * buffers allocated. After the call to this buffer, videobuf layer will
+ * setup buffer queue depending on the size and count of buffers
+ */
+static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
*count,
+ unsigned int *size)
+{
+ struct omap_vout_device *vout = q-priv_data;
+ int startindex = 0, i, j;
+ u32 phy_addr = 0, virt_addr = 0;
+
+ if (!vout)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
+ return -EINVAL;
+
+ startindex = (vout-vid == OMAP_VIDEO1) ?
+ video1_numbuffers : video2_numbuffers;
+ if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
+ *count = startindex;
+
+ if ((rotation_enabled(vout-rotation)) *count 4)
+ *count = 4;
+
This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?
Cheers,
Nate
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it is
the userspace app responsability to check the value again, to confirm how many
of the requested buffers are actually available.
Regards,
Sergio--
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 3/3] OMAP2/3 V4L2 Display Driver
Hi Sergio,
Thank you for your explanation . I learned much from that.
Cheers,
Nate
On Tue, May 19, 2009 at 2:22 PM, Aguirre Rodriguez, Sergio Alberto
saagui...@ti.com wrote:
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh
R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hello Hardik,
Reviewing your driver, I found something made me curious.
On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
snip
+/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
+ * called. This is used to setup buffers and return size and count of
+ * buffers allocated. After the call to this buffer, videobuf layer will
+ * setup buffer queue depending on the size and count of buffers
+ */
+static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
*count,
+ unsigned int *size)
+{
+ struct omap_vout_device *vout = q-priv_data;
+ int startindex = 0, i, j;
+ u32 phy_addr = 0, virt_addr = 0;
+
+ if (!vout)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
+ return -EINVAL;
+
+ startindex = (vout-vid == OMAP_VIDEO1) ?
+ video1_numbuffers : video2_numbuffers;
+ if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
+ *count = startindex;
+
+ if ((rotation_enabled(vout-rotation)) *count 4)
+ *count = 4;
+
This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?
Cheers,
Nate
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it
is the userspace app responsability to check the value again, to confirm how
many of the requested buffers are actually available.
Regards,
Sergio
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.com
--
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 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
-Original Message-
From: Aguirre Rodriguez, Sergio Alberto
Sent: Tuesday, May 19, 2009 10:52 AM
To: Dongsoo, Nathaniel Kim; Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R;
Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh
R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hello Hardik,
Reviewing your driver, I found something made me curious.
On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
snip
+/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
+ * called. This is used to setup buffers and return size and count of
+ * buffers allocated. After the call to this buffer, videobuf layer will
+ * setup buffer queue depending on the size and count of buffers
+ */
+static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
*count,
+ unsigned int *size)
+{
+ struct omap_vout_device *vout = q-priv_data;
+ int startindex = 0, i, j;
+ u32 phy_addr = 0, virt_addr = 0;
+
+ if (!vout)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
+ return -EINVAL;
+
+ startindex = (vout-vid == OMAP_VIDEO1) ?
+ video1_numbuffers : video2_numbuffers;
+ if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
+ *count = startindex;
+
+ if ((rotation_enabled(vout-rotation)) *count 4)
+ *count = 4;
+
This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?
[Shah, Hardik] Rotation requires the VRFB contexts and limited number of
contexts are available. So maximum number of buffers is fixed to 4 when
rotation is enabled.
Thanks,
Hardik
Cheers,
Nate
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it
is the userspace app responsability to check the value again, to confirm how
many of the requested buffers are actually available.
Regards,
Sergio
--
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 3/3] OMAP2/3 V4L2 Display Driver
Hi Hardik,
According to earlier mail from Sergio, I could be noticed that it is
totally ok to restrict number of buffers by driver. As matter of fact,
I was always considering about the H/W restriction and could find the
answer from his mail.
By the way, thank you for your answer.
Cheers,
Nate
On Tue, May 19, 2009 at 2:28 PM, Shah, Hardik hardik.s...@ti.com wrote:
Hi Nate,
-Original Message-
From: Aguirre Rodriguez, Sergio Alberto
Sent: Tuesday, May 19, 2009 10:52 AM
To: Dongsoo, Nathaniel Kim; Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh
R;
Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
I have 1 input regarding your question:
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
Sent: Tuesday, May 19, 2009 7:53 AM
To: Shah, Hardik
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh
R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hello Hardik,
Reviewing your driver, I found something made me curious.
On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah hardik.s...@ti.com wrote:
snip
+/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
+ * called. This is used to setup buffers and return size and count of
+ * buffers allocated. After the call to this buffer, videobuf layer will
+ * setup buffer queue depending on the size and count of buffers
+ */
+static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
*count,
+ unsigned int *size)
+{
+ struct omap_vout_device *vout = q-priv_data;
+ int startindex = 0, i, j;
+ u32 phy_addr = 0, virt_addr = 0;
+
+ if (!vout)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
+ return -EINVAL;
+
+ startindex = (vout-vid == OMAP_VIDEO1) ?
+ video1_numbuffers : video2_numbuffers;
+ if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
+ *count = startindex;
+
+ if ((rotation_enabled(vout-rotation)) *count 4)
+ *count = 4;
+
This seems to be weird to me. If user requests multiple buffers more
than 4, user cannot recognize that the number of buffers requested is
forced to change into 4. I'm not sure whether this could be serious or
not, but it is obvious that user can have doubt about why if user have
no information about the OMAP H/W.
Is it really necessary to be configured to 4?
[Shah, Hardik] Rotation requires the VRFB contexts and limited number of
contexts are available. So maximum number of buffers is fixed to 4 when
rotation is enabled.
Thanks,
Hardik
Cheers,
Nate
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it
is the userspace app responsability to check the value again, to confirm how
many of the requested buffers are actually available.
Regards,
Sergio
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.com
--
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
