Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)
On Thursday 25 June 2009 04:40:11 Andy Walls wrote: > On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote: > > > On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote: > > > > > > There is already an s_gpio in the core ops. It would be simple to add a > > g_gpio as well if needed. > > Hans, > > As you probably know > > int (*s_gpio)(v4l2_subdev *sd, u32 val); > > is a little too simple for initial setup of GPIO pins. With the > collection of chips & cores supported by cx25840 module, setting the > GPIO configuration also requires: > > direction: In or Out > multiplexed pins: GPIO or some other function > > I could tack on direction as an argument to s_gpio(), but I think that > is a bit inconvenient.. I'd rather have a > > int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval); > > but that leaves out the method for multiplexed pin/pad configuration. > Perhaps explicity setting a GPIO direction to OUT could be an implicit > indication that a multiplexed pin should be set to it's GPIO function. > However, that doesn't help for GPIO inputs that might have their pins > multiplexed with other functions. > > Here's an idea on how to specify multiplexed pin configuration > information and it could involve pins that multiplex functions other > than GPIO (the CX25843 is quite flexible in this regard): > > int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function); > > The type checking ends up pretty weak, but I figured it was better than > a 'void *config' that had a subdev specific collection of pin > configuration information. > > Comments? Hi Andy, Is there any driver that needs to setup the multiplex functions? If not, then I would not add support for this at the moment. Adding unused code is a bad idea in general. In addition, such information should only be needed at initialization time, and since we now have the new v4l2_i2c_new_subdev_cfg function I think that that is the right way to do this. The same approach can be used for setting the gpio pin directions. That too is something you setup at config time. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
Hello! In a last ditch effort, I decided to try downloading a v4l driver snapshot from February back when I had my Pinnacle HD Pro Stick device working. To my amazement, the old drivers worked! By process of elimination (trying newer and newer drivers until my Pinnacle device was once again not recognized), it appears that changeset 11331 (http://linuxtv.org/hg/v4l-dvb/rev/00525b115901), from Mar. 31 2009, is the first one that causes my device to not be recognized. This is the changeset that updated the em28xx driver from 0.1.1 to 0.1.2. Here, again, is the dmesg output from a newer driver that does NOT work (this one from a driver set one day later, on Apr. 1, 2009): [ 50.028008] Vortex: init Linux video capture interface: v2.00 [ 50.300176] em28xx: New device Pinnacle Systems PCTV 800e @ 480 Mbps (2304:0227, interface 0, class 0) [ 50.312863] em28xx #0: Identified as Pinnacle PCTV HD Pro Stick (card=17) [ 50.325625] em28xx #0: chip ID is em2882/em2883 [ 50.539728] em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 27 02 d0 12 5c 03 8e 16 a4 1c [ 50.552582] em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 00 00 00 [ 50.565276] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 1c 00 00 [ 50.577939] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 50.590583] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 50.603076] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 50.615380] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 00 69 00 [ 50.627589] em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 [ 50.639651] em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 00 00 16 03 [ 50.651573] em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00 38 00 30 00 30 00 [ 50.663407] em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 36 00 31 00 30 00 30 00 [ 50.675144] em28xx #0: i2c eeprom b0: 31 00 30 00 33 00 39 00 34 00 34 00 32 00 00 00 [ 50.686680] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 50.698183] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 50.698187] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 50.698193] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 50.698197] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x2de5abbf [ 50.698198] em28xx #0: EEPROM info: [ 50.698199] em28xx #0: AC97 audio (5 sample rates) [ 50.698200] em28xx #0: 500mA max power [ 50.698201] em28xx #0: Table at 0x27, strings=0x168e, 0x1ca4, 0x246a [ 50.805990] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1a.7/usb7/7-3/input/input6 [ 50.901902] em28xx #0: Config register raw data: 0xd0 [ 50.913510] em28xx #0: AC97 vendor ID = 0x [ 50.924746] em28xx #0: AC97 features = 0x6a90 [ 50.935543] em28xx #0: Empia 202 AC97 audio processor detected [ 51.034109] em28xx #0: v4l2 driver version 0.1.2 [ 51.128411] em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 [ 51.139183] usbcore: registered new interface driver em28xx [ 51.149961] em28xx driver loaded [ 51.496978] xc2028 0-0061: creating new instance [ 51.521582] xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner [ 51.532725] em28xx #0/2: xc3028 attached [ 51.546910] DVB: registering new adapter (em28xx #0) [ 51.570086] DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3303 VSB/QAM Frontend)... [ 51.581731] Successfully loaded em28xx-dvb [ 51.593250] Em28xx: Initialized (Em28xx dvb Extension) extension and here is a successful dmesg using the changeset 11330 drivers from early morning Mar. 31, 2009, right before the em28xx version bump from 0.1.1 to 0.1.2 [ 48.484051] Linux video capture interface: v2.00 [ 48.597772] em28xx: New device Pinnacle Systems PCTV 800e @ 480 Mbps (2304:0227, interface 0, class 0) [ 48.610698] em28xx #0: Identified as Pinnacle PCTV HD Pro Stick (card=17) [ 48.623638] ACPI: PCI Interrupt :06:01.0[A] -> em28xx #0: chip ID is em2882/em2883 [ 48.877223] em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 27 02 d0 12 5c 03 8e 16 a4 1c [ 48.889807] em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 00 00 00 [ 48.902235] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 1c 00 00 [ 48.914771] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 48.927131] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 48.939329] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 48.951368] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 00 69 00 [ 48.963320] em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 [ 48.975173] em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00
[PATCH 06/19] drivers/media: Use PCI_VDEVICE
Signed-off-by: Joe Perches
---
drivers/media/video/bt8xx/bttv-driver.c | 12
drivers/media/video/meye.c |3 +--
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c
index 5eb1464..d8d3e1d 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -4591,14 +4591,10 @@ static int bttv_resume(struct pci_dev *pci_dev)
#endif
static struct pci_device_id bttv_pci_tbl[] = {
- {PCI_VENDOR_ID_BROOKTREE, PCI_DEVICE_ID_BT848,
-PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_BROOKTREE, PCI_DEVICE_ID_BT849,
-PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_BROOKTREE, PCI_DEVICE_ID_BT878,
-PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_BROOKTREE, PCI_DEVICE_ID_BT879,
-PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_VDEVICE(BROOKTREE, PCI_DEVICE_ID_BT848), 0},
+ {PCI_VDEVICE(BROOKTREE, PCI_DEVICE_ID_BT849), 0},
+ {PCI_VDEVICE(BROOKTREE, PCI_DEVICE_ID_BT878), 0},
+ {PCI_VDEVICE(BROOKTREE, PCI_DEVICE_ID_BT879), 0},
{0,}
};
diff --git a/drivers/media/video/meye.c b/drivers/media/video/meye.c
index 1d66855..d0765be 100644
--- a/drivers/media/video/meye.c
+++ b/drivers/media/video/meye.c
@@ -1915,8 +1915,7 @@ static void __devexit meye_remove(struct pci_dev *pcidev)
}
static struct pci_device_id meye_pci_tbl[] = {
- { PCI_VENDOR_ID_KAWASAKI, PCI_DEVICE_ID_MCHIP_KL5A72002,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+ { PCI_VDEVICE(KAWASAKI, PCI_DEVICE_ID_MCHIP_KL5A72002), 0 },
{ }
};
--
1.6.3.1.10.g659a0.dirty
--
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
v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)
On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote: > > On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote: > > > There is already an s_gpio in the core ops. It would be simple to add a > g_gpio as well if needed. Hans, As you probably know int (*s_gpio)(v4l2_subdev *sd, u32 val); is a little too simple for initial setup of GPIO pins. With the collection of chips & cores supported by cx25840 module, setting the GPIO configuration also requires: direction: In or Out multiplexed pins: GPIO or some other function I could tack on direction as an argument to s_gpio(), but I think that is a bit inconvenient.. I'd rather have a int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval); but that leaves out the method for multiplexed pin/pad configuration. Perhaps explicity setting a GPIO direction to OUT could be an implicit indication that a multiplexed pin should be set to it's GPIO function. However, that doesn't help for GPIO inputs that might have their pins multiplexed with other functions. Here's an idea on how to specify multiplexed pin configuration information and it could involve pins that multiplex functions other than GPIO (the CX25843 is quite flexible in this regard): int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function); The type checking ends up pretty weak, but I figured it was better than a 'void *config' that had a subdev specific collection of pin configuration information. Comments? 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
Re: [linux-dvb] Gigabyte GT-P8000 dvb-t / analog / fm radio - pci
Hi, Am Mittwoch, den 24.06.2009, 18:31 +0200 schrieb John Moodie: > > Hi, > > > > Am Mittwoch, den 24.06.2009, 01:36 +1000 schrieb c kuruwita: > >> Hi > >> > >> You could try using the "card=" option when loading the kernel module > >> and use the cardnumber of a similar supported saa7134 dvb card. > >> you can find a complete list of supported card saa713 dvb cards in > >> "Documentation/video4linux/CARDLIST.saa7134". > >> > > > > that might become a very frustrating experience and it is also not > > without some danger. At least you might get the card in a not further > > responding state and you might need a cold boot in between. > > > > Minimum further to know is the type of the digital demodulator these > > days! > > > > If it is for example a tda10048, there are currently only two cards to > > test on for DVB-T, but likely with slightly different hardware > > configuration. > > > > You also need to know if it needs firmware and which one. > > > > The saa7134 insmod option "i2c_scan=1" should be used to see if at least > > all chips are visible. You might need special gpio switching else to get > > them out of some power saving state. > > > > You also don't know if you need gate control enabled of the tda8290 > > analog IF demod built into the saa7131e to initialize and further > > program the tuner. > > > > Tuner, digital demod and analog demod can be on four different i2c > > addresses each. For dvb-t you need to know and set each of those > > addresses correctly. It makes no sense to try on cards having this not > > all the same. > > > > The eeprom, if it is correct on this, says tuner at 0x60, analog demod > > at 0x4b and digital demod at 0x08 in seven bit notation. The tuner at > > 0x60 is rather rare, if you look into saa7134-dvb.c. Makes no sense to > > test on other cards. > > > > Then we always want to have the antenna inputs reported. What shares > > with what an input and what is on a separate one? > > Only this way you can _eventually_ find a card with the same switching > > there and also correct FM switch. > > > > Next, most recent cards do have an additional RF LNA and there are > > different types. All must be correctly set up for analog and digital > > mode or you will have some unpleasant experiences. Seems there is no way > > for us currently to know, if there is one at all or which type of > > configuration it does need. > > > > You must also know or find out, if the card uses serial or parallel TS > > interface. > > > > Even if you succeed with all the above, and that is possible by working > > through step by step, especially with a tda10048 you might need a card > > specific configuration not yet covered by other cards. > > > > Blindly testing on cards without knowing on what you are testing > > exactly, unlikely has good results on recent hybrid cards. > > > > First of all you must know the type of digital demod on that card too. > > The fuzzy picture I found seems to say it has only 48 pins ... > > > > Always recommend to read further on the wiki about how to provide a good > > report for new hardware. > > > > Cheers, > > Hermann > > > > Hi, > > I did do some blind testing with the card= option, but the only one that > looked promising was card=112 [ASUSTeK P7131 Hybrid]. But dmesg reported > 'tda10046: chip is not answering. Giving up' that is what i meant. If you look closer you will find a tda10048 on your board and we have just these two cards for now. The HVR 1110r3 (card=156) in TS serial mode and LNA, specific gpios are in use, and the Leadtek DTV 1000S Mike has a testing repo for now in TS parallel, but without analog tuner support. At least no analog demod in the eeprom. Have a look at the related threads. Hauppauge HVR 1110 and DVB Leadtek Winfast DTV-1000S Both have links to firmware either from Steven or Terry. Maybe you can get it to load, but the other questions are still unanswered then. Cheers, Hermann > I have created a page for the card which can be found here: > http://linuxtv.org/wiki/index.php/Gigabyte_GT-P8000 > > Regards, > John > > >> > >> On Sat, May 23, 2009 at 6:42 AM, wrote: > >> > Does anyone have any information on the support status of this card? > >> Or > >> > perhaps any hints I might try to get it working? > >> > > >> > I have built and installed the latest V4L-DVB kernel driver modules, > >> but > >> > no luck. > >> > > >> > I noticed windows installs Philips 3xhybrid drivers if this helps... > >> > > >> > Product website: > >> > http://www.gigabyte.com.tw/Products/TVCard/Products_Spec.aspx?ClassValue=TV+Card&ProductID=2757&ProductName=GT-P8000 > >> > > >> > Tuner NXP 18271 > >> > Decoder NXP 7131E > >> > > >> > lspci -vnn: > >> > 00:09.0 Multimedia controller [0480]: Philips Semiconductors > >> > SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1) > >> >Subsystem: Giga-byte Technology Device [1458:9004] > >> >Flags: bus master, medium devsel, latency 32, IRQ 11 > >> >Memory at e600 (
[PATCH] mt9t031 - migration to sub device frame work
From: Muralidharan Karicheri
This patch migrates mt9t031 driver from SOC Camera interface to
sub device interface. This is sent to get a feedback about the
changes done since I am not sure if some of the functionality
that is removed works okay with SOC Camera bridge driver or
not. Following functions are to be discussed and added as needed:-
1) query bus parameters
2) set bus parameters
3) set crop
I have tested this with vpfe capture driver and I could capture
640x...@17fps and 2048x1...@12fps resolution frames from the sensor.
Reviewed by: Hans Verkuil
Reviewed by: Guennadi Liakhovetski
Signed-off-by: Murali Karicheri
---
drivers/media/video/mt9t031.c | 596 -
1 files changed, 293 insertions(+), 303 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index f72aeb7..0f32ff2 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -13,9 +13,9 @@
#include
#include
+#include
#include
#include
-#include
/* mt9t031 i2c address 0x5d
* The platform has to define i2c_board_info
@@ -52,33 +52,108 @@
#define MT9T031_VERTICAL_BLANK 25
#define MT9T031_COLUMN_SKIP32
#define MT9T031_ROW_SKIP 20
+#define MT9T031_DEFAULT_WIDTH 640
+#define MT9T031_DEFAULT_HEIGHT 480
#define MT9T031_BUS_PARAM (SOCAM_PCLK_SAMPLE_RISING | \
SOCAM_PCLK_SAMPLE_FALLING | SOCAM_HSYNC_ACTIVE_HIGH | \
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_HIGH | \
SOCAM_MASTER | SOCAM_DATAWIDTH_10)
-static const struct soc_camera_data_format mt9t031_colour_formats[] = {
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, "Debug level (0-1)");
+
+static const struct v4l2_fmtdesc mt9t031_formats[] = {
+ {
+ .index = 0,
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .description = "Bayer (sRGB) 10 bit",
+ .pixelformat = V4L2_PIX_FMT_SGRBG10,
+ },
+};
+static const unsigned int mt9t031_num_formats = ARRAY_SIZE(mt9t031_formats);
+
+static const struct v4l2_queryctrl mt9t031_controls[] = {
{
- .name = "Bayer (sRGB) 10 bit",
- .depth = 10,
- .fourcc = V4L2_PIX_FMT_SGRBG10,
- .colorspace = V4L2_COLORSPACE_SRGB,
+ .id = V4L2_CID_VFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = "Flip Vertically",
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_HFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = "Flip Horizontally",
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ }, {
+ .id = V4L2_CID_GAIN,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Gain",
+ .minimum= 0,
+ .maximum= 127,
+ .step = 1,
+ .default_value = 64,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Exposure",
+ .minimum= 1,
+ .maximum= 255,
+ .step = 1,
+ .default_value = 255,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ }, {
+ .id = V4L2_CID_EXPOSURE_AUTO,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = "Automatic Exposure",
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 1,
}
};
+static const unsigned int mt9t031_num_controls = ARRAY_SIZE(mt9t031_controls);
struct mt9t031 {
- struct i2c_client *client;
- struct soc_camera_device icd;
+ struct v4l2_subdev sd;
int model; /* V4L2_IDENT_MT9T031* codes from v4l2-chip-ident.h */
unsigned char autoexposure;
u16 xskip;
u16 yskip;
+ u32 width;
+ u32 height;
+ unsigned short x_min; /* Camera capabilities */
+ unsigned short y_min;
+ unsigned short x_current; /* Current window location */
+ unsigned short y_current;
+ unsigned short width_min;
+ unsigned short width_max;
+ unsigned short height_min;
+ unsigned short height_max;
+ unsigned short y_skip_top; /* Lines to skip at the top */
+ unsigne
Re: sub devices sharing same i2c address
On Wed, Jun 24, 2009 at 12:44:08PM -0500, Karicheri, Muralidharan wrote: > Any reason why this is not added to upstream ? I think this is exactly > what is needed to support this. IIRC it does not work reliably with the legacy i2c binding model, so this has to die first. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 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:Wed Jun 24 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12133:05e6c5c9bcb4 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-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-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS 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-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-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS sparse (linux-2.6.30): 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: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS 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: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec 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: sub devices sharing same i2c address
Daniel, Thanks for responding Any reason why this is not added to upstream ? I think this is exactly what is needed to support this. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com >-Original Message- >From: Daniel Glöckner [mailto:daniel...@gmx.net] >Sent: Tuesday, June 23, 2009 3:11 PM >To: Karicheri, Muralidharan >Cc: linux-media@vger.kernel.org >Subject: Re: sub devices sharing same i2c address > >On Tue, Jun 23, 2009 at 01:10:11PM -0500, Karicheri, Muralidharan wrote: >> I am having to switch between two sub devices that shares the same i2c >> address. First one is TVP5146 and the other is MT9T031. The second has >> a i2c switch and the evm has a data path switch. > >You could try Rodolfo Giometti's i2c bus multiplexing code: >http://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing > >It will create a new i2c_adapter for each output of the i2c switch >and the switch is handled transparently when accessing the devices. > > Daniel -- 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
capture usb dev "msi movie vox mini plus" (1d19:6901)
Hi there, recently I've bought an usb video capture device Msi movie vox mini plus. I's detected as: USB 2861 Video ID: 1d19:6901 It seems to be very similar to device 'USB Yakumo Movie Mixer'. The Yakumo device is supported by v4l. I tried to add id 1d19:6901 to em28xx driver and use movievox as 'Yakumo device' But id doesn't work. I can't get video from my movievox device. I was able to get UsbSnoop log from the windows driver. How can I use the usbsnoop log to get msi capture device working? Or is anyone already working on the support of this device? Martin Zibricky this is dmesg output when pretending that movievox is yakumo: -- usb 2-3: new full speed USB device using ohci_hcd and address 3 usb 2-3: not running at top speed; connect to a high speed hub usb 2-3: configuration #1 chosen from 1 choice Linux video capture interface: v2.00 em28xx: New device USB 2861 Video @ 12 Mbps (1d19:6901, interface 0, class 0) em28xx #0: Identified as Yakumo MovieMixer (card=38) em28xx #0: chip ID is em2860 em28xx #0: i2c eeprom 00: 1a eb 67 95 19 1d 01 69 50 00 11 03 6a 20 8a 0c em28xx #0: i2c eeprom 10: 00 00 24 57 0e 02 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 20: 02 00 01 00 f0 10 01 00 00 00 00 00 5b 00 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 36 00 31 00 20 00 56 00 em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 0c 03 30 00 38 00 em28xx #0: i2c eeprom 90: 30 00 36 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x5f3afec4 em28xx #0: EEPROM info: em28xx #0: AC97 audio (5 sample rates) em28xx #0: 500mA max power em28xx #0: Table at 0x24, strings=0x206a, 0x0c8a, 0x tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) em28xx #0: Config register raw data: 0x50 em28xx #0: AC97 vendor ID = 0x em28xx #0: AC97 features = 0x6a90 em28xx #0: Empia 202 AC97 audio processor detected tvp5150 1-005c: tvp5150am1 detected. em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 em28xx audio device (1d19:6901): interface 1, class 1 em28xx audio device (1d19:6901): interface 2, class 1 usbcore: registered new interface driver em28xx em28xx driver loaded usbcore: registered new interface driver snd-usb-audio tvp5150 1-005c: tvp5150am1 detected. - lsusb -v: - Bus 001 Device 006: ID 1d19:6901 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1d19 idProduct 0x6901 bcdDevice1.00 iManufacturer 0 iProduct1 USB 2861 Video iSerial 2 0806 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 555 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval
Re: [linux-dvb] Gigabyte GT-P8000 dvb-t / analog / fm radio - pci
> Hi, > > Am Mittwoch, den 24.06.2009, 01:36 +1000 schrieb c kuruwita: >> Hi >> >> You could try using the "card=" option when loading the kernel module >> and use the cardnumber of a similar supported saa7134 dvb card. >> you can find a complete list of supported card saa713 dvb cards in >> "Documentation/video4linux/CARDLIST.saa7134". >> > > that might become a very frustrating experience and it is also not > without some danger. At least you might get the card in a not further > responding state and you might need a cold boot in between. > > Minimum further to know is the type of the digital demodulator these > days! > > If it is for example a tda10048, there are currently only two cards to > test on for DVB-T, but likely with slightly different hardware > configuration. > > You also need to know if it needs firmware and which one. > > The saa7134 insmod option "i2c_scan=1" should be used to see if at least > all chips are visible. You might need special gpio switching else to get > them out of some power saving state. > > You also don't know if you need gate control enabled of the tda8290 > analog IF demod built into the saa7131e to initialize and further > program the tuner. > > Tuner, digital demod and analog demod can be on four different i2c > addresses each. For dvb-t you need to know and set each of those > addresses correctly. It makes no sense to try on cards having this not > all the same. > > The eeprom, if it is correct on this, says tuner at 0x60, analog demod > at 0x4b and digital demod at 0x08 in seven bit notation. The tuner at > 0x60 is rather rare, if you look into saa7134-dvb.c. Makes no sense to > test on other cards. > > Then we always want to have the antenna inputs reported. What shares > with what an input and what is on a separate one? > Only this way you can _eventually_ find a card with the same switching > there and also correct FM switch. > > Next, most recent cards do have an additional RF LNA and there are > different types. All must be correctly set up for analog and digital > mode or you will have some unpleasant experiences. Seems there is no way > for us currently to know, if there is one at all or which type of > configuration it does need. > > You must also know or find out, if the card uses serial or parallel TS > interface. > > Even if you succeed with all the above, and that is possible by working > through step by step, especially with a tda10048 you might need a card > specific configuration not yet covered by other cards. > > Blindly testing on cards without knowing on what you are testing > exactly, unlikely has good results on recent hybrid cards. > > First of all you must know the type of digital demod on that card too. > The fuzzy picture I found seems to say it has only 48 pins ... > > Always recommend to read further on the wiki about how to provide a good > report for new hardware. > > Cheers, > Hermann > Hi, I did do some blind testing with the card= option, but the only one that looked promising was card=112 [ASUSTeK P7131 Hybrid]. But dmesg reported 'tda10046: chip is not answering. Giving up' I have created a page for the card which can be found here: http://linuxtv.org/wiki/index.php/Gigabyte_GT-P8000 Regards, John >> >> On Sat, May 23, 2009 at 6:42 AM, wrote: >> > Does anyone have any information on the support status of this card? >> Or >> > perhaps any hints I might try to get it working? >> > >> > I have built and installed the latest V4L-DVB kernel driver modules, >> but >> > no luck. >> > >> > I noticed windows installs Philips 3xhybrid drivers if this helps... >> > >> > Product website: >> > http://www.gigabyte.com.tw/Products/TVCard/Products_Spec.aspx?ClassValue=TV+Card&ProductID=2757&ProductName=GT-P8000 >> > >> > Tuner NXP 18271 >> > Decoder NXP 7131E >> > >> > lspci -vnn: >> > 00:09.0 Multimedia controller [0480]: Philips Semiconductors >> > SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1) >> >Subsystem: Giga-byte Technology Device [1458:9004] >> >Flags: bus master, medium devsel, latency 32, IRQ 11 >> >Memory at e600 (32-bit, non-prefetchable) [size=2K] >> >Capabilities: [40] Power Management version 2 >> >Kernel driver in use: saa7134 >> >Kernel modules: saa7134 >> > >> > dmesg output: >> > [ 3089.801191] saa7130/34: v4l2 driver version 0.2.15 loaded >> > [ 3089.801419] saa7133[0]: found at :00:09.0, rev: 209, irq: 11, >> > latency: 32, mmio: 0xe600 >> > [ 3089.801443] saa7133[0]: subsystem: 1458:9004, board: >> UNKNOWN/GENERIC >> > [card=0,autodetected] >> > [ 3089.801656] saa7133[0]: board init: gpio is 4 >> > [ 3089.952088] saa7133[0]: i2c eeprom 00: 58 14 04 90 54 20 1c 00 43 >> 43 >> > a9 >> > 1c 55 d2 b2 92 >> > [ 3089.952125] saa7133[0]: i2c eeprom 10: ff ff ff ff ff 20 ff ff ff >> ff >> > ff >> > ff ff ff ff ff >> > [ 3089.952153] saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 01 03 08 >> ff >> > 00 >> > b3 ff ff ff ff >> > [ 3089.952180] saa
Re: [linux-dvb] how to code a driver for a tv tuner card??
There's a problem, though. Programming data for the chipsets seems not to be easily available. I would also love to be able to make a try at supporting a card (in my case, the HVR-2250 in analog mode) but to do so requires access to info that I could not get. -Carlos Christophe Thommeret @ 24/6/2009 11:23 UTC -0300 dixit: > Le Wednesday 24 June 2009 15:57:43 Julien Martin, vous avez écrit : >> Hello, >> >> I am posting today because I am VERY interested in learning more about how >> to code a driver for a tv tuner card. >> >> I am learning C and to a lesser extent Assembly. >> >> Could you be so kind as to answer the following questions: >> >> 1. What documentation do you suggest I read in order to start coding >> drivers for tv tuner cards for Linux? >> 2. What programming languages are used for the above purpose? >> 3. Do I need to know electronics? > > Browsing the v4l-dvb repository should answer most of your questions .. > -- Carlos G Mendioroz -- 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] how to code a driver for a tv tuner card??
Le Wednesday 24 June 2009 15:57:43 Julien Martin, vous avez écrit : > Hello, > > I am posting today because I am VERY interested in learning more about how > to code a driver for a tv tuner card. > > I am learning C and to a lesser extent Assembly. > > Could you be so kind as to answer the following questions: > > 1. What documentation do you suggest I read in order to start coding > drivers for tv tuner cards for Linux? > 2. What programming languages are used for the above purpose? > 3. Do I need to know electronics? Browsing the v4l-dvb repository should answer most of your questions .. -- Christophe Thommeret -- 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] soc-camera: two fixes and a v4l2-subdev extension
Hi Mauro, Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following 3 changesets: 01/03: v4l: add cropping prototypes to struct v4l2_subdev_video_ops http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=76dff0709a9f 02/03: soc_camera: Fix debug output of supported formats count http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b1534a8f9151 03/03: soc-camera: fix missing clean up on error path http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=514edb8642ae Of which two are minor bug-fixes (one relevant for debug and another one for an error path), and an API extension. Fixes can also go in after -rc1, the extension will, probably, not be eligible for that, but it's not a big problem if it only goes in with 2.6.32 either. So, no rush. drivers/media/video/soc_camera.c | 12 include/media/v4l2-subdev.h |3 +++ 2 files changed, 11 insertions(+), 4 deletions(-) Thanks, Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] Support for Compro VideoMate S350
Thanks Igor, I have tried the second version of the 12096 patch and it applied perfectly . Also I ran a make on the dvb drivers , and they all compiled without error . So everything is good now . Next step is to install the drivers and the Compro S350 card into the PC . One question please , I only need these new drivers to get the S350 working , so which .ko's do I need to install ? I am quite happy to have the other stuff such as webcams ...etc. from the kernel . Best Regards Milorad -- 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] dvb v4l code break webcam drivers
2009/6/23 jon bird : > I replaced my stock Linux V4l/dvb drivers with the versions from cvs on > linuxtv.org whilst attempting to resolve problems with my Nova-T stick > (a red herring as it happens). However what I've discovered since is > that they argue quite badly with drivers for the 2 webcams I have (of > course the webcam drivers themselves may be at fault here but I thought > it worth pointing out). > > Replacing the linux kernel modules (2.6.26) resolves the problem and > both these and the DVB side work. > > here's the log from the snapshot I took 2 days ago: > > Jun 22 17:17:55 fridge kernel: [ cut here ] > Jun 22 17:17:55 fridge kernel: WARNING: at > /opt2/data/kernel/v4l-dvb-6c50c4b2ef70/v4l/v4l2-dev.c:434 > video_register_device_index+0x3a/0x354 [videodev]() > Jun 22 17:17:55 fridge kernel: Modules linked in: gspca(+) videodev > v4l1_compat af_packet nfsd exportfs usbserial ppdev parport_pc lp > parport snd_pcm_oss snd_mixer_oss snd_via82xx snd_ac97_codec ac97_bus > snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi > snd_seq_device snd soundcore xt_TCPMSS xt_DSCP ipt_MASQUERADE ipt_LOG > ipt_REDIRECT xt_state joydev evdev dvb_usb_dib0700 dib7000p dib7000m > dvb_usb dvb_core firmware_class dib3000mc dibx000_common dib0070 > uhci_hcd ohci_hcd ehci_hcd usbcore ipv6 8139too mii ipt_REJECT > iptable_mangle iptable_nat nf_nat iptable_filter nf_conntrack_ipv4 > nf_conntrack ip_tables mt2060 i2c_core sata_via libata dock 8250 > serial_core > Jun 22 17:17:55 fridge kernel: Pid: 3853, comm: modprobe Not tainted > 2.6.26 #9 > Jun 22 17:17:55 fridge kernel: [warn_on_slowpath+62/91] > warn_on_slowpath+0x3e/0x5b > Jun 22 17:17:55 fridge kernel: [] warn_on_slowpath+0x3e/0x5b > Jun 22 17:17:55 fridge kernel: [__wake_up+15/21] __wake_up+0xf/0x15 > Jun 22 17:17:55 fridge kernel: [] __wake_up+0xf/0x15 > Jun 22 17:17:55 fridge kernel: [wake_up_klogd+43/45] > wake_up_klogd+0x2b/0x2d > Jun 22 17:17:55 fridge kernel: [] wake_up_klogd+0x2b/0x2d > Jun 22 17:17:55 fridge kernel: [] > usb_internal_control_msg+0x54/0x61 [usbcore] > Jun 22 17:17:55 fridge kernel: [] usb_control_msg+0x7e/0x8b > [usbcore] > Jun 22 17:17:55 fridge kernel: [printk+14/17] printk+0xe/0x11 > Jun 22 17:17:55 fridge kernel: [] printk+0xe/0x11 > Jun 22 17:17:55 fridge kernel: [] > spca5xx_getcapability+0xa2/0xad [gspca] > Jun 22 17:17:55 fridge kernel: [] > video_register_device_index+0x3a/0x354 [videodev] > Jun 22 17:17:55 fridge kernel: [] > video_register_device+0x7/0x9 [videodev] > Jun 22 17:17:55 fridge kernel: [] spca5xx_probe+0x1f4/0x287 > [gspca] > Jun 22 17:17:55 fridge kernel: [] > usb_probe_interface+0xb3/0xde [usbcore] > Jun 22 17:17:55 fridge kernel: [__driver_attach+0/85] > __driver_attach+0x0/0x55 > Jun 22 17:17:55 fridge kernel: [] __driver_attach+0x0/0x55 > Jun 22 17:17:55 fridge kernel: [really_probe+112/226] > really_probe+0x70/0xe2 > Jun 22 17:17:55 fridge kernel: [] really_probe+0x70/0xe2 > Jun 22 17:17:55 fridge kernel: [driver_probe_device+54/62] > driver_probe_device+0x36/0x3e > Jun 22 17:17:55 fridge kernel: [] > driver_probe_device+0x36/0x3e > Jun 22 17:17:55 fridge kernel: [__driver_attach+55/85] > __driver_attach+0x37/0x55 > Jun 22 17:17:55 fridge kernel: [] __driver_attach+0x37/0x55 > Jun 22 17:17:55 fridge kernel: [bus_for_each_dev+53/89] > bus_for_each_dev+0x35/0x59 > Jun 22 17:17:55 fridge kernel: [] bus_for_each_dev+0x35/0x59 > Jun 22 17:17:55 fridge kernel: [driver_attach+17/19] > driver_attach+0x11/0x13 > Jun 22 17:17:55 fridge kernel: [] driver_attach+0x11/0x13 > Jun 22 17:17:55 fridge kernel: [__driver_attach+0/85] > __driver_attach+0x0/0x55 > Jun 22 17:17:55 fridge kernel: [] __driver_attach+0x0/0x55 > Jun 22 17:17:55 fridge kernel: [bus_add_driver+138/306] > bus_add_driver+0x8a/0x132 > Jun 22 17:17:55 fridge kernel: [] bus_add_driver+0x8a/0x132 > Jun 22 17:17:55 fridge kernel: [driver_register+104/136] > driver_register+0x68/0x88 > Jun 22 17:17:55 fridge kernel: [] driver_register+0x68/0x88 > Jun 22 17:17:55 fridge kernel: [] > usb_register_driver+0x52/0x9c [usbcore] > Jun 22 17:17:55 fridge kernel: [] usb_spca5xx_init+0x14/0x31 > [gspca] > Jun 22 17:17:55 fridge kernel: [] sys_init_module+0x84/0x173 > Jun 22 17:17:55 fridge kernel: [syscall_call+7/11] syscall_call+0x7/0xb > Jun 22 17:17:55 fridge kernel: [] syscall_call+0x7/0xb > Jun 22 17:17:55 fridge kernel: === > Jun 22 17:17:55 fridge kernel: ---[ end trace be190c3dbfd1c67f ]--- > > > this happens with the spca5xx webcam driver and the old Logitech > quickcam express driver. > > > -- > == jon bird - software engineer > == > == > == posted as: news 'at' onastick 'dot' clara.co.uk > > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > I can confirm this behaviour on gsp
