Re: About VIDIOC_G_OUTPUT/S_OUTPUT ?
Hello Hans, I took a look into ivtv driver but the VIDEO_SELECT_SOURCE doesn't fit in the feature that I was explaining. ivtv_passthrough_mode seems to be all about selecting input source not output. Am I right? But in my case, I have (1)external camera, (2)memory for input source and (1)memory, (2)LCD FIFO(like overlay) for output. It means that use case can be established like this: (A) using external camera for input and memory for output = memcpy the memory to framebuffer to display preview (B) using external camera for input and memory for output = memcpy the memory and save as a file (recording or snapshot). maybe the same case as (A) (C) using external camera for input and LCD FIFO for output = turn on the camera and will se preview with doing nothing further in userspace (like memcpy) (D) using memory for input source and memory for output = actually in this case we can use rotator feature of camera interface. so let the multimedia file go through the camera interface and rotate orientation. (E) using memory for input source and LCD FIFO for output = rotate multimedia file and display direct to LCD. So in this case, should I use VIDIOC_S_INPUT to select input and VIDIOC_S_OUTPUT to select output device? or I got in the wrong way in the first place(if VIDEO_SELECT_SOURCE is the right one for me) If the concept above fits in VIDIOC_S_OUTPUT then I think we need more type define because I think any of type defined is not matching feature of output to memory. Cheers, Nate 2009/5/22 Dongsoo Kim dongsoo@gmail.com: Hi Hans, 2009. 05. 22, 오후 9:40, Hans Verkuil 작성: On Friday 22 May 2009 04:05:47 Dongsoo, Nathaniel Kim wrote: Hi Hans, On Thu, May 21, 2009 at 9:07 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Wednesday 20 May 2009 13:48:08 Dongsoo, Nathaniel Kim wrote: Hello everyone, Doing a new camera interface driver job of new AP from Samsung, a single little question doesn't stop making me confused. The camera IP in Samsung application processor supports for two of output paths, like to memory and to LCD FIFO. It seems to be VIDIOC_G_OUTPUT/S_OUTPUT which I need to use (just guessing), but according to Hans's ivtv driver the output of G_OUTPUT/S_OUTPUT is supposed to mean an actually and physically separated real output path like Composite, S-Video and so on. Do you think that memory or LCD FIFO can be an output device in this case? Because in earlier version of my driver, I assumed that the LCD FIFO is a kind of OVERLAY device, so I didn't even need to use G_OUTPUT and S_OUTPUT to route output device. I'm just not sure about which idea makes sense. or maybe both of them could make sense indeed... When you select to memory, then the video from the camera is DMAed to the CPU, right? But selecting to LCD means that the video is routed internally to the LCD without any DMA to the CPU taking place, right? Yes definitely right. This is similar to the passthrough mode of the ivtv driver. This header: linux/dvb/video.h contains an ioctl called VIDEO_SELECT_SOURCE, which can be used to select either memory or a demuxer (or in this case, the camera) as the source of the output (the LCD in this case). It is probably the appropriate ioctl to implement for this. So, in user space we should call VIDIO_SELECT_SOURCE ioctl? Yes. The video.h header is shared between v4l and dvb and contains several ioctls meant to handle output. It is poorly documented and I think it should be merged into the v4l2 API and properly documented/cleaned up. I agree with you. Anyway, camera interface is not a DVB device but supporting this source routing feature means that we also need this API in v4l2. It's valid to use VIDEO_SELECT_SOURCE in an v4l2 driver. It's currently used by ivtv. It's an historical accident that these ioctls ended up in the dvb header. Oh, I'll look into the driver. Cheers. Note that overlays are meant for on-screen displays. Usually these are associated with a framebuffer device. Your hardware may implement such an OSD as well, but that is different from this passthrough feature. Sorry Hans, I'm not sure that I'm following this part. Can I put it in the way like this? The OSD feature in Samsung AP should be handled separated with the selecting source feature (camera-to-FB and camera-to-memory). So that I should implement both of them. (overlay feature and select source feature) Am I following? Please let me know if there is something wrong. Yes, that's correct. BTW, my 5M camera driver which is including the new V4L2 API proposal I gave a talk in SF couldn't have approval from my bosses to be opened to the public. But I'll try to make another camera device driver which can cover must of the API I proposed. That's a shame. Erm, just to make it clear for your bosses: any v4l2 driver that uses any of the videobuf_*, v4l2_i2c_*, v4l2_device_* or v4l2_int_* functions must be a GPL driver, and thus has to be made
Re: About VIDIOC_G_OUTPUT/S_OUTPUT ?
Thank you Hans, Thanks to you I got the point of selecting input and output is that only physical connection can make it. It is really helping. BTW, more I work on v4l2 more I need for decent documentation. I should rather make some porting guide and technical documents for other developers. Actually V4L2 specification should be serving more detailed information indeed. When I see some sort of [?] things in the API specification document, thousands of question marks starts floating in my brain ;-O Cheers, Nate 2009/5/26 Hans Verkuil hverk...@xs4all.nl: On Tuesday 26 May 2009 08:32:00 Dongsoo, Nathaniel Kim wrote: Hello Hans, I took a look into ivtv driver but the VIDEO_SELECT_SOURCE doesn't fit in the feature that I was explaining. ivtv_passthrough_mode seems to be all about selecting input source not output. Am I right? But in my case, I have (1)external camera, (2)memory for input source and (1)memory, (2)LCD FIFO(like overlay) for output. It means that use case can be established like this: (A) using external camera for input and memory for output = memcpy the memory to framebuffer to display preview (B) using external camera for input and memory for output = memcpy the memory and save as a file (recording or snapshot). maybe the same case as (A) This is the same as A. (C) using external camera for input and LCD FIFO for output = turn on the camera and will se preview with doing nothing further in userspace (like memcpy) For this you need VIDEO_SELECT_SOURCE. (D) using memory for input source and memory for output = actually in this case we can use rotator feature of camera interface. so let the multimedia file go through the camera interface and rotate orientation. (E) using memory for input source and LCD FIFO for output = rotate multimedia file and display direct to LCD. Do D and E both go through the rotator feature of the camera interface? Anyway D sounds more like the proposed omap scaler device: basically a codec device. Anyway, based on this description S_INPUT has only one input: the camera. And S_OUTPUT has only the LCD as it's output. Those are the only physical connections. VIDEO_SELECT_SOURCE allows you to shortcut the two. It does not have anything to do with selecting the input or output. It just tells the driver to not use memory as its source/destination (which is the default behavior at all times), but connect the input and output together internally. Hope this helps. Regards, Hans So in this case, should I use VIDIOC_S_INPUT to select input and VIDIOC_S_OUTPUT to select output device? or I got in the wrong way in the first place(if VIDEO_SELECT_SOURCE is the right one for me) If the concept above fits in VIDIOC_S_OUTPUT then I think we need more type define because I think any of type defined is not matching feature of output to memory. Cheers, Nate 2009/5/22 Dongsoo Kim dongsoo@gmail.com: Hi Hans, 2009. 05. 22, 오후 9:40, Hans Verkuil 작성: On Friday 22 May 2009 04:05:47 Dongsoo, Nathaniel Kim wrote: Hi Hans, On Thu, May 21, 2009 at 9:07 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Wednesday 20 May 2009 13:48:08 Dongsoo, Nathaniel Kim wrote: Hello everyone, Doing a new camera interface driver job of new AP from Samsung, a single little question doesn't stop making me confused. The camera IP in Samsung application processor supports for two of output paths, like to memory and to LCD FIFO. It seems to be VIDIOC_G_OUTPUT/S_OUTPUT which I need to use (just guessing), but according to Hans's ivtv driver the output of G_OUTPUT/S_OUTPUT is supposed to mean an actually and physically separated real output path like Composite, S-Video and so on. Do you think that memory or LCD FIFO can be an output device in this case? Because in earlier version of my driver, I assumed that the LCD FIFO is a kind of OVERLAY device, so I didn't even need to use G_OUTPUT and S_OUTPUT to route output device. I'm just not sure about which idea makes sense. or maybe both of them could make sense indeed... When you select to memory, then the video from the camera is DMAed to the CPU, right? But selecting to LCD means that the video is routed internally to the LCD without any DMA to the CPU taking place, right? Yes definitely right. This is similar to the passthrough mode of the ivtv driver. This header: linux/dvb/video.h contains an ioctl called VIDEO_SELECT_SOURCE, which can be used to select either memory or a demuxer (or in this case, the camera) as the source of the output (the LCD in this case). It is probably the appropriate ioctl to implement for this. So, in user space we should call VIDIO_SELECT_SOURCE ioctl? Yes. The video.h header is shared between v4l and dvb and contains several ioctls meant to handle output. It is poorly documented and I think it should be merged into the v4l2 API and properly documented/cleaned up.
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Mauro, On Mon, 25 May 2009, Mauro Carvalho Chehab wrote: Em Wed, 20 May 2009 11:27:18 +0200 (CEST) Patrick Boettcher patrick.boettc...@desy.de escreveu: Hi Mauro, please pull from my repository for hte following changesets: Committed, thanks. Yet, I saw a few minor issues on one of your patch. Please fix and submit me later a cleanup. - Rewrote frontend-attach mechanism to gain noise-less deactivation of submodules This patch do also a good CodingStyle fixes. That's good (although it is generally better to have the codingsyle specific changes on a separate patch). It wasn't me to do the codingstyle changes. I didn't see the \'s in diff and I actually don't know why I didn't see them. Thanks for the other comments, I'll take them into consideration. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PULL request - http://linuxtv.org/hg/~pb/v4l-dvb/
Hi Trent, On Mon, 25 May 2009, Trent Piepho wrote: On Mon, 25 May 2009, Mauro Carvalho Chehab wrote: + if (params-frequency = 4800 params-frequency = 15400) \ + bs = 0x09; + if (params-frequency = 16100 params-frequency = 43900) \ + bs = 0x0a; + if (params-frequency = 44700 params-frequency = 86300) \ + bs = 0x08; Just remove the backslash. You don't need they. The original code has this, but bs will be zero for a frequency between 154 MHz to 161 Mhz as welll as 439-447 MHz. Probably wrong. My guess is the data sheet says, low band 48 to 154 MHz, mid band 161 MHz to 439 MHz, etc., where 154 is the frequency of the last channel in the low band and 161 is the first channel in the mid band. Then someone translated this to code without really understanding what's going on. It should probably be: if (params-frequency 44300) bs = 0x08; else if (params-frequency 15750) bs = 0x0a; elsebs = 0x09; The tuner's limits should already be enforced elsewhere. Or just convert this to use dvb_pll. Thanks for pointing this out, can you please provide a patch for that? Preferably for the dvb_pll-solution? There seems only to be a handful of users which are really knowing that they are using this card and this driver to receive DVB-C in Linux, so testing it will be hard, but most likely it's not needed. regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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
gspca: Logitech QuickCam Messenger worked last with external gspcav1-20071224
Hi all I think it would be agood time now to get my Logitech QuickCam Messenger camera working with the current gspca driver. It used to work with gspcav1-20071224, here's dmesg output: /tmp/gspcav1-20071224/gspca_core.c: USB GSPCA camera found.(ZC3XX) /tmp/gspcav1-20071224/gspca_core.c: [spca5xx_probe:4275] Camera type JPEG /tmp/gspcav1-20071224/Vimicro/zc3xx.h: [zc3xx_config:669] Find Sensor HV7131R(c) with more USB related messages following. Now dmesg with some debug turned on looks like gspca: probing 046d:08da zc3xx: probe 2wr ov vga 0x zc3xx: probe sensor - 11 zc3xx: Find Sensor HV7131R(c) gspca: probe ok usbcore: registered new interface driver zc3xx zc3xx: registered and the camera is not working, the light on its case doesn't go on. If I try force_sensor=15 to match sensor tas5130cxx, as was detected by the old driver, dmesg reports gspca: probing 046d:08da zc3xx: probe 2wr ov vga 0x zc3xx: probe sensor - 11 zc3xx: sensor forced to 15 gspca: probe ok usbcore: registered new interface driver zc3xx zc3xx: registered and otherwise nothing changes. I could spend some time trying to find the problem, but I would prefer if someone could suggest some debugging, I am not familiar with gspca internals. Ideas anyone? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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
libv4l release: 0.5.98: the gamma correction release!
Hi All, This is probably the last test release for the 0.6.x series, the video processing code has been rewritten and works very nicely now. Please give this release a thorough testing! The software whitebalancing and gamma correction can make a very positive difference on the image quality given of by cheaper cams. libv4l now automatically enables fake controls to enable software white-balancing and gamma for most webcams (all those will will need conversion anyways). So when you startup v4l2ucp you should see a checkbox for whitebalance and a slider for gamma (the default setting of 1000 == 1.0 is no gamma correction). Now start your favorite webcam viewing app and play around with the 2 controls. If whitebalancing makes a *strongly noticable* positive difference for your webcam please mail me info about your cam (the usb id), then I can add it to the list of cams which will have the whitebalancing algorithm enabled by default. The same goes for cams which benefit from a significant gamma correction. For example this release sets the gamma to 1500 (1.5) for pac207 cams by default, resulting in a much improved image. libv4l-0.5.98 - * Add software gamma correction * Add software auto gain / exposure * Add support for separate vflipping and hflipping * Add fake controls controlling the software h- and v-flipping * Add ability to determine upside down cams based on DMI info * Add the capability to provide 320x240 to apps if the cam can only do 320x232 (some zc3xx cams) by adding black borders * Rewrite video processing code to make it easier to add more video filters (and with little extra processing cost). As part of this the normalize filter has been removed as it wasn't functioning satisfactory anyways * Support V4L2_CTRL_FLAG_NEXT_CTRL for fake controls by Adam Baker * Some makefile improvements by Gregor Jasny * Various small bugfixes and tweaks * The V4L2_ENABLE_ENUM_FMT_EMULATION v4l2_fd_open flag is obsolete, libv4l2 now *always* reports emulated formats through the ENUM_FMT ioctl Get it here: http://people.atrpms.net/~hdegoede/libv4l-0.5.98.tar.gz Regards, Hans -- 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: gspca: Logitech QuickCam Messenger worked last with external gspcav1-20071224
On 05/26/2009 01:44 PM, Guennadi Liakhovetski wrote: Hi all I think it would be agood time now to get my Logitech QuickCam Messenger camera working with the current gspca driver. It used to work with gspcav1-20071224, here's dmesg output: /tmp/gspcav1-20071224/gspca_core.c: USB GSPCA camera found.(ZC3XX) /tmp/gspcav1-20071224/gspca_core.c: [spca5xx_probe:4275] Camera type JPEG /tmp/gspcav1-20071224/Vimicro/zc3xx.h: [zc3xx_config:669] Find Sensor HV7131R(c) with more USB related messages following. Now dmesg with some debug turned on looks like gspca: probing 046d:08da zc3xx: probe 2wr ov vga 0x zc3xx: probe sensor - 11 zc3xx: Find Sensor HV7131R(c) gspca: probe ok usbcore: registered new interface driver zc3xx zc3xx: registered and the camera is not working, the light on its case doesn't go on. If I try force_sensor=15 to match sensor tas5130cxx, as was detected by the old driver, dmesg reports gspca: probing 046d:08da zc3xx: probe 2wr ov vga 0x zc3xx: probe sensor - 11 zc3xx: sensor forced to 15 gspca: probe ok usbcore: registered new interface driver zc3xx zc3xx: registered and otherwise nothing changes. I could spend some time trying to find the problem, but I would prefer if someone could suggest some debugging, I am not familiar with gspca internals. Ideas anyone? First of all, which app are you using to test the cam ? And are you using that app in combination with libv4l ? Also why do you say the original driver used to identify it as a tas5130cxx, the dmesg lines you pasted from gspcav1 also say it is a HV7131R Regards, Hans -- 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: gspca: Logitech QuickCam Messenger worked last with external gspcav1-20071224
On Tue, 26 May 2009, Hans de Goede wrote:
First of all, which app are you using to test the cam ? And are you using that
app in combination with libv4l ?
xawtv, no, it doesn't use libv4l, but it works with the old
gspcav1-20071224. Ok, maybe it used a different v4l version, but I have
v4l1_compat loaded.
Also why do you say the original driver used to identify it as a tas5130cxx,
the dmesg lines you pasted from gspcav1 also say it is a HV7131R
In the old sources you see
switch (vendor) {
...
case 0x046d:/* Logitech Labtec */
...
switch (product) {
...
case 0x08da:
spca50x-desc = QCmessenger;
spca50x-bridge = BRIDGE_ZC3XX;
spca50x-sensor = SENSOR_TAS5130CXX;
break;
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: gspca: Logitech QuickCam Messenger worked last with external gspcav1-20071224
On 05/26/2009 02:08 PM, Guennadi Liakhovetski wrote:
On Tue, 26 May 2009, Hans de Goede wrote:
First of all, which app are you using to test the cam ? And are you using that
app in combination with libv4l ?
xawtv, no, it doesn't use libv4l, but it works with the old
gspcav1-20071224. Ok, maybe it used a different v4l version, but I have
v4l1_compat loaded.
xawtv has known bugs making it not work with gspca (or many other
properly implemented v4l drivers that is). Now those bugs are fixed in
some distro's but this might very well be the cause. Try using ekiga
(together with LD_PRELOAD=/v4l1compat.so)
Also why do you say the original driver used to identify it as a tas5130cxx,
the dmesg lines you pasted from gspcav1 also say it is a HV7131R
In the old sources you see
switch (vendor) {
...
case 0x046d:/* Logitech Labtec */
...
switch (product) {
...
case 0x08da:
spca50x-desc = QCmessenger;
spca50x-bridge = BRIDGE_ZC3XX;
spca50x-sensor = SENSOR_TAS5130CXX;
break;
Hmm, weird it still prints that other message then. Anyways please
try with another application both with and without the force_sensor
parameter.
Regards,
Hans
p.s.
I've attached a patch to xawtv which I use in Fedora's packages.
diff -Nrbu xawtv-3.95/libng/plugins/drv0-v4l2.c
xawtv-3.95-OK/libng/plugins/drv0-v4l2.c
--- xawtv-3.95/libng/plugins/drv0-v4l2.c2005-02-11 20:56:24.0
+0300
+++ xawtv-3.95-OK/libng/plugins/drv0-v4l2.c 2008-08-26 19:27:18.0
+0400
@@ -91,6 +91,7 @@
struct ng_video_fmtfmt_me;
struct v4l2_requestbuffers reqbufs;
struct v4l2_buffer buf_v4l2[WANTED_BUFFERS];
+intbuf_v4l2_size[WANTED_BUFFERS];
struct ng_video_bufbuf_me[WANTED_BUFFERS];
unsigned int queue,waiton;
@@ -166,7 +167,7 @@
int rc;
rc = ioctl(fd,cmd,arg);
-if (0 == rc ng_debug 2)
+if (rc = 0 ng_debug 2)
return rc;
if (mayfail errno == mayfail ng_debug 2)
return rc;
@@ -768,6 +769,7 @@
/* get it */
memset(buf,0,sizeof(buf));
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+buf.memory = V4L2_MEMORY_MMAP;
if (-1 == xioctl(h-fd,VIDIOC_DQBUF,buf, 0))
return -1;
h-waiton++;
@@ -812,6 +814,7 @@
h-buf_v4l2[i].memory = V4L2_MEMORY_MMAP;
if (-1 == xioctl(h-fd, VIDIOC_QUERYBUF, h-buf_v4l2[i], 0))
return -1;
+ h-buf_v4l2_size[i] = h-buf_v4l2[i].length;
h-buf_me[i].fmt = h-fmt_me;
h-buf_me[i].size = h-buf_me[i].fmt.bytesperline *
h-buf_me[i].fmt.height;
@@ -865,12 +868,16 @@
ng_waiton_video_buf(h-buf_me[i]);
if (ng_debug)
print_bufinfo(h-buf_v4l2[i]);
- if (-1 == munmap(h-buf_me[i].data,h-buf_me[i].size))
+ if (-1 == munmap(h-buf_me[i].data, h-buf_v4l2_size[i]))
perror(munmap);
}
h-queue = 0;
h-waiton = 0;
+/* unrequest buffers (only needed for some drivers) */
+h-reqbufs.count = 0;
+xioctl(h-fd, VIDIOC_REQBUFS, h-reqbufs, EINVAL);
+
/* turn on preview (if needed) */
if (h-ov_on != h-ov_enabled) {
h-ov_on = h-ov_enabled;
@@ -907,6 +914,17 @@
fmt-width= h-fmt_v4l2.fmt.pix.width;
fmt-height = h-fmt_v4l2.fmt.pix.height;
fmt-bytesperline = h-fmt_v4l2.fmt.pix.bytesperline;
+/* struct v4l2_format.fmt.pix.bytesperline is bytesperline for the
+ main plane for planar formats, where as we want it to be the total
+ bytesperline for all planes */
+switch (fmt-fmtid) {
+case VIDEO_YUV422P:
+ fmt-bytesperline *= 2;
+ break;
+case VIDEO_YUV420P:
+ fmt-bytesperline = fmt-bytesperline * 3 / 2;
+ break;
+}
if (0 == fmt-bytesperline)
fmt-bytesperline = fmt-width * ng_vfmt_to_depth[fmt-fmtid] / 8;
h-fmt_me = *fmt;
Re: gspca: Logitech QuickCam Messenger worked last with external gspcav1-20071224
On Tue, 26 May 2009, Hans de Goede wrote: On 05/26/2009 02:08 PM, Guennadi Liakhovetski wrote: On Tue, 26 May 2009, Hans de Goede wrote: First of all, which app are you using to test the cam ? And are you using that app in combination with libv4l ? xawtv, no, it doesn't use libv4l, but it works with the old gspcav1-20071224. Ok, maybe it used a different v4l version, but I have v4l1_compat loaded. xawtv has known bugs making it not work with gspca (or many other properly implemented v4l drivers that is). Now those bugs are fixed in some distro's but this might very well be the cause. Try using ekiga (together with LD_PRELOAD=/v4l1compat.so) Coool! Loading the driver without parameters and using LD_LIBRARY_PATH=v4l2-apps/libv4l/libv4l1/:v4l2-apps/libv4l/libv4l2/:v4l2-apps/libv4l/libv4lconvert/ \ LD_PRELOAD=v4l2-apps/libv4l/libv4l1/v4l1compat.so mplayer tv:// -tv \ driver=v4l:device=/dev/video0 -vo x11 started the video! Thanks a million, Hans! Cheers 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
v4l-dvb and old kernels
It would compile today's snapshot of v4l-dvb with an old kernel version (for example 2.6.16)? (or is better to upgrade the kernel?) Trying to compile today's mercurial snapshot in a SuSE 10.1 (2.6.16-21), give the next errors: /root/v4l-dvb/v4l/bttv-i2c.c: In function 'init_bttv_i2c': /root/v4l-dvb/v4l/bttv-i2c.c:411: error: storage size of 'info' isn't known /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:427: error: implicit declaration of function 'i2c_new_probed_device' /root/v4l-dvb/v4l/bttv-i2c.c:411: warning: unused variable 'info' make[5]: *** [/root/v4l-dvb/v4l/bttv-i2c.o] Error 1 Greetings. -- 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: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
On Mon, 25 May 2009, Pete Zaitcev wrote: On Mon, 25 May 2009 13:25:55 +0100, David da...@unsolicited.net wrote: I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select in arch/x86/Kconfig). Strange that it started happening now. That is enabled. I'll switch it off and give it another go. While CONFIG_HAVE_DMA_API_DEBUG was set, DMA_API_DEBUG was not, so I guess there's nothing I can do to test? I suppose so. I misunderstood how this worked. I guessed that the DMA API debugging was the culprit because its introduction coincided with the recent onset of this oops. Although usbmon does essentially illegal tricks to look at data already mapped for DMA, the code used to work for a few releases. Bisecting may help. I cannot be sure of it though, and it's going to take a lot of reboots. Unfortunately, although I have an Opteron, the issue does not occur here, so I'm at a loss for the moment. But I'll have to tackle it somehow. Not sure how though. Any suggestions are welcome. Try asking the people responsible for maintaining DMA support for help. And David is very good about testing new patches. Alan Stern -- 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] SDMC DM1105N not being detected
On 25 May 2009 22:50:39 Simon Kenyon wrote: Igor M. Liplianin wrote: On 20 May 2009 16:44:22 Simon Kenyon wrote: mp3geek wrote: Not even being detected in Linux 2.6.29.1, I have the modules dm1105 loaded, but since its not even being detected by linux.. lspci -vv shows this (I'm assuming this is the card..), dmesg shows nothing dvb being loaded 00:0b.0 Ethernet controller: Device 195d:1105 (rev 10) Subsystem: Device 195d:1105 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 30 (4000ns min, 8000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 5 Region 0: I/O ports at 9400 [size=256] The chip says the following, SDMC DM1105N, EasyTV-DVBS V1.0B (2008-04-26), 0735 E280034 because i saw that there was a driver written by igor, i took a chance and bought a DM04 DVB-S card on ebay. it only cost ─20 (including shipping from HK to Ireland) so i reckoned nothing ventured, nothing gained on a windows box it runs rather nicely. granted that the software provided does not provide a BDA driver, so you are pretty much limited to the stuff that comes with the card. but a big me too on linux (which is what i bought it for) i similarly get an ethernet controller and nothing in the kernel log when i load the dm1105 module. what do i need to do to debug the situation and/or update the driver? regards -- simon It seems, one can find GPIO values for LNB power control. Do not forget about Vendor/Device ID's. I wrote code to support card with subsystem/device 195d/1105, but no one reported success, so I decided not to include it in commit :( It was more then one year ago http://liplianin.at.tut.by/dvblipl.tar.bz2 igor, i downloaded it and built it (after making a few small changes to make it compile with tip) it finds the hardware, but does not seem able to get a data stream kaffeine seems to show that there is signal - and it does seem to vary in a way that is consistent with a working card what do i need to do to help get this to work. i would like to as (under windows) it seems to work well and it is very, very cheap (13 euro on ebay) it is on a machine which i can dual boot into windows (if that is any use) regards -- simon The card is working with external LNB power supply, for example, through the loop out from another sat box. So, we need to know, which way to control LNB power on the board. Usually it is through GPIO pins. For example: Pins 112 and 111 for GPIO0, GPIO1. Also GPIO15 is at 65 pin. You can edit this lines in code: -*-*-*-*-*-*-*-*-*-*-*-*- /* GPIO's for LNB power control for Axess DM05 */ #define DM05_LNB_MASK 0xfffc // GPIO control #define DM05_LNB_13V0x3fffd // GPIO value #define DM05_LNB_18V0x3fffc // GPIO value -*-*-*-*-*-*-*-*-*-*-*-*- BTW: Bit value 0 for GPIOCTL means output, 1 - input. Bit value for GPIOVAL - read/write. GPIO pins count is 18. Bits over 18 affect nothing. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-dvb and old kernels
Hello, Antonio On Tue, May 26, 2009 at 5:03 PM, Antonio Beamud Montero antonio.bea...@gmail.com wrote: It would compile today's snapshot of v4l-dvb with an old kernel version (for example 2.6.16)? (or is better to upgrade the kernel?) Not long time ago v4l-dvb community had discussions about dropping support for kernels older than 2.6.22. And community decided to support kernels 2.6.22 - 2.6.30+. One of the reason that it's big work to support code to make it compiles and works in old kernels. Well, developers want to spend more time working on new code. So, the best way to you is to upgrade your kernel. Second way to correct mistakes. Probably developers can help you here. One more way, probably you can take old snapshot of v4l-dvb repository that compiles and work on 2.6.16 if you need. Someone can point to link to it (i don' know). Trying to compile today's mercurial snapshot in a SuSE 10.1 (2.6.16-21), give the next errors: /root/v4l-dvb/v4l/bttv-i2c.c: In function 'init_bttv_i2c': /root/v4l-dvb/v4l/bttv-i2c.c:411: error: storage size of 'info' isn't known /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:425: error: invalid application of 'sizeof' to incomplete type 'struct i2c_board_info' /root/v4l-dvb/v4l/bttv-i2c.c:427: error: implicit declaration of function 'i2c_new_probed_device' /root/v4l-dvb/v4l/bttv-i2c.c:411: warning: unused variable 'info' make[5]: *** [/root/v4l-dvb/v4l/bttv-i2c.o] Error 1 Well, this mistakes appear in v4l-dvb daily build too. -- Best regards, Klimov Alexey -- 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 -next] v4l2: handle unregister for non-I2C builds
Em Fri, 22 May 2009 17:55:54 +1000 Stephen Rothwell s...@canb.auug.org.au escreveu: On Fri, 22 May 2009 14:48:47 +0900 Paul Mundt let...@linux-sh.org wrote: On Mon, May 11, 2009 at 09:37:41AM -0700, Randy Dunlap wrote: From: Randy Dunlap randy.dun...@oracle.com Build fails when CONFIG_I2C=n, so handle that case in the if block: drivers/built-in.o: In function `v4l2_device_unregister': (.text+0x157821): undefined reference to `i2c_unregister_device' Signed-off-by: Randy Dunlap randy.dun...@oracle.com This patch still has not been applied as far as I can tell, and builds are still broken as a result, almost 2 weeks after the fact. In fact there has been no updates to the v4l-dvb tree at all since May 11. Mauro? Sorry, this email were got by a wrong filtering rule here. Only today I noticed it. Anyway, the tree were updated yesterday, with Randy's patch. Sorry for the mess. I have reverted the patch that caused the build breakage ... (commit d5bc7940d39649210f1affac1fa32f253cc45a81 V4L/DVB (11673): v4l2-device: unregister i2c_clients when unregistering the v4l2_device). [By the way, an alternative fix might be to just define V4L2_SUBDEV_FL_IS_I2C to be zero if CONFIG_I2C and CONFIG_I2C_MODULE are not defined (gcc should then just elide the offending code).] Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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:Tue May 26 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11853:142fd6020df3 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-rc7-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-rc7-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc7-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-rc7-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-rc7-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-rc7-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-rc7-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-rc7-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc7): 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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: [linux-dvb] EPG (Electronic Program Guide) Tools
On Tue, May 26, 2009 at 1:51 PM, Chris Capon ttab...@gmail.com wrote: Hi: I've installed an HVR-1600 card in a Debian system to receive ATSC digital broadcasts here in Canada. Everything works great. scan /usr/share/dvb/atsc/us-ATSC-center-frequencies-8VSB channels.conf finds a complete list of broadcasters. azap -c channels.conf -r channel-name tunes in the stations and displays signal strength info. cp /dev/dvb/adapter0/dvr0 xx.mpg captures the output stream which can be played by mplayer. What I'm missing is information about the Electronic Program Guide (EPG). There doesn't seem to be much info on linuxtv.org on how to read it. Where does the EPG come from? Is it incorporated into the output stream through PID's some how or is it read from one of the other devices under adapter0? Are there simple command line tools to read it or do you have to write a custom program to interpret it somehow? Could someone please point me in the right direction to get started? If no tools exist, perhaps links to either api or lib docs/samples? Much appreciated. Chris. Hello Chris, The ATSC EPG is sent via the ATSC PSIP protocol. I do not know of any tools currently available to extract the information. MeTV has a working implementation (with some bugs I have seen), and I was looking at getting it to work in Kaffeine at some point. The spec is freely available here: http://www.atsc.org/standards/a_65cr1_with_amend_1.pdf If you have any questions, feel free to drop me a line. 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
EPG (Electronic Program Guide) Tools
Hi: I've installed an HVR-1600 TV card in a Debian system to receive ATSC digital broadcasts here in Canada. Everything works great. scan /usr/share/dvb/atsc/us-ATSC-center-frequencies-8VSB channels.conf finds a complete list of broadcasters. azap -c channels.conf -r channel-name tunes in the stations and displays signal strength info. cp /dev/dvb/adapter0/dvr0 xx.mpg captures the output stream which can be played by mplayer. What I'm missing is information about the Electronic Program Guide (EPG). There doesn't seem to be much info on linuxtv.org on how to read it. Googling hasn't produced meaningful clues. Where does the EPG come from? Is it incorporated into the output stream through PID's some how or is it read from one of the other devices under adapter0? Are there simple command line tools to read it or do you have to write a custom program to interpret it somehow? Could someone please point me in the right direction to get started? If no tools exist, perhaps links to either api or lib docs/samples? Much appreciated. Chris. -- 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] Add QAM64 support for hvr-950q (au8522)
On Mon, May 25, 2009 at 7:27 PM, Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Mon, May 25, 2009 at 6:03 PM, Frank Dischner phaedrus...@googlemail.com wrote: While I'm at it, I thought I'd go ahead and make a patch to remove the top bits from the vsb table, but I've got a question about that. I think the first four entries are unnecessary. I'm pretty sure 8090 and 8091 have to do with the 8522's i2c controller and 4092 is a status register. I have no idea what 2005 is, but the new code would change it to A005 and I don't remember seeing either in any of the traces I did (though I never did a vsb trace). Is this correct or am I missing something? If I make a patch, can you or someone else test it for me? (can't get a signal here) Yeah, I noticed the 4092 entry. The 4 means it's a read operation so it almost certainly shouldn't be in the table. I just haven't taken the time to look closer at a Windows trace to see if it was *really* a register read operation that got stuck into the table or whether it was supposed to be a write operation. I haven't reviewed the VSB table yes, so I am not sure about the other entries. Devin -- From my experience it seems that 2 in 0x2005 resets the 8522 demod. All demod register setting appear to be lost after accessing any registers in the 0x2xxx range (you really, just that bit needs to be set on a i2c bus access). I am a little surprised that 0x2000 is not written to the bus to for each modulation mode. Tim -- 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 4/6] dvb/dvb-usb: prepare for FIRMWARE_NAME_MAX removal
On Tue, May 26, 2009 at 1:40 PM, Samuel Ortiz sa...@linux.intel.com wrote:
From: Samuel Ortiz sa...@linux.intel.com
To: Mauro Carvalho Chehab mche...@infradead.org
We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid any
firmware name length restriction.
This patch changes the dvb_usb_device_properties firmware field accordingly.
Signed-off-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/media/dvb/dvb-usb/dvb-usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h
===
--- iwm-2.6.orig/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-05-26
17:24:36.0 +0200
+++ iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-05-26 17:25:19.0
+0200
@@ -196,7 +196,7 @@ struct dvb_usb_device_properties {
#define CYPRESS_FX2 3
int usb_ctrl;
int (*download_firmware) (struct usb_device *, const struct
firmware *);
- const char firmware[FIRMWARE_NAME_MAX];
+ const char *firmware;
int no_reconnect;
int size_of_priv;
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Samuel,
Your patch makes the following change:
- const char firmware[FIRMWARE_NAME_MAX];
+ const char *firmware;
Before your change, struct dvb_usb_device_properties actually contains
memory allocated for the firmware filename. After your change, this
is nothing but a pointer.
This will cause an OOPS.
Regards,
Mike Krufky
--
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 4/6] dvb/dvb-usb: prepare for FIRMWARE_NAME_MAX removal
On Tue, May 26, 2009 at 02:32:45PM -0400, Michael Krufky wrote:
On Tue, May 26, 2009 at 1:40 PM, Samuel Ortiz sa...@linux.intel.com wrote:
From: Samuel Ortiz sa...@linux.intel.com
To: Mauro Carvalho Chehab mche...@infradead.org
We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid any
firmware name length restriction.
This patch changes the dvb_usb_device_properties firmware field accordingly.
Signed-off-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/media/dvb/dvb-usb/dvb-usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h
===
--- iwm-2.6.orig/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-05-26
17:24:36.0 +0200
+++ iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-05-26
17:25:19.0 +0200
@@ -196,7 +196,7 @@ struct dvb_usb_device_properties {
#define CYPRESS_FX2 3
int usb_ctrl;
int (*download_firmware) (struct usb_device *, const struct
firmware *);
- const char firmware[FIRMWARE_NAME_MAX];
+ const char *firmware;
int no_reconnect;
int size_of_priv;
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Samuel,
Your patch makes the following change:
- const char firmware[FIRMWARE_NAME_MAX];
+ const char *firmware;
Before your change, struct dvb_usb_device_properties actually contains
memory allocated for the firmware filename. After your change, this
is nothing but a pointer.
This will cause an OOPS.
No, not if it's correctly initialized, as it seems to be for all the
dvb_usb_device_properties users right now.
Typically, you'd initialize your dvb_usb_device_properties like this:
static struct dvb_usb_device_properties a800_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = CYPRESS_FX2,
.firmware = dvb-usb-avertv-a800-02.fw,
[...]
And that's fine.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.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: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
Pete Zaitcev wrote: On Mon, 25 May 2009 13:25:55 +0100, David da...@unsolicited.net wrote: I suppose so. I misunderstood how this worked. I guessed that the DMA API debugging was the culprit because its introduction coincided with the recent onset of this oops. Although usbmon does essentially illegal tricks to look at data already mapped for DMA, the code used to work for a few releases. Bisecting may help. I cannot be sure of it though, and it's going to take a lot of reboots. Unfortunately, although I have an Opteron, the issue does not occur here, so I'm at a loss for the moment. But I'll have to tackle it somehow. Not sure how though. Any suggestions are welcome. -- Pete I've been doing a bit of random rebooting (I don't really have time to do a full bisect), and can reproduce the usbmon panic on this machine back to 2.6.24.. so it certainly hasn't appeared that recently. Cheers David -- 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] Add QAM64 support for hvr-950q (au8522)
On Tue, May 26, 2009 at 2:35 PM, Tim Mester ttmest...@gmail.com wrote: From my experience it seems that 2 in 0x2005 resets the 8522 demod. All demod register setting appear to be lost after accessing any registers in the 0x2xxx range (you really, just that bit needs to be set on a i2c bus access). I am a little surprised that 0x2000 is not written to the bus to for each modulation mode. Hmmm... I would have to look closer before I could comment intelligently. Resetting all the registers could be a bad idea if there are registers being programmed that are not in the modulation block (initialization parameters such as the IF setting). 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: [PATCH 4/6] dvb/dvb-usb: prepare for FIRMWARE_NAME_MAX removal
On Tue, May 26, 2009 at 2:42 PM, Samuel Ortiz sa...@linux.intel.com wrote:
On Tue, May 26, 2009 at 02:32:45PM -0400, Michael Krufky wrote:
On Tue, May 26, 2009 at 1:40 PM, Samuel Ortiz sa...@linux.intel.com wrote:
From: Samuel Ortiz sa...@linux.intel.com
To: Mauro Carvalho Chehab mche...@infradead.org
We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid
any
firmware name length restriction.
This patch changes the dvb_usb_device_properties firmware field
accordingly.
Signed-off-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/media/dvb/dvb-usb/dvb-usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h
===
--- iwm-2.6.orig/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-05-26
17:24:36.0 +0200
+++ iwm-2.6/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-05-26
17:25:19.0 +0200
@@ -196,7 +196,7 @@ struct dvb_usb_device_properties {
#define CYPRESS_FX2 3
int usb_ctrl;
int (*download_firmware) (struct usb_device *, const struct
firmware *);
- const char firmware[FIRMWARE_NAME_MAX];
+ const char *firmware;
int no_reconnect;
int size_of_priv;
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Samuel,
Your patch makes the following change:
- const char firmware[FIRMWARE_NAME_MAX];
+ const char *firmware;
Before your change, struct dvb_usb_device_properties actually contains
memory allocated for the firmware filename. After your change, this
is nothing but a pointer.
This will cause an OOPS.
No, not if it's correctly initialized, as it seems to be for all the
dvb_usb_device_properties users right now.
Typically, you'd initialize your dvb_usb_device_properties like this:
static struct dvb_usb_device_properties a800_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = CYPRESS_FX2,
.firmware = dvb-usb-avertv-a800-02.fw,
[...]
And that's fine.
You're right -- there is nothing wrong with the change -- my bad.
I traced though the code after posting that last mail. It looked
risky when I just looked at the patch, but in the end this is actually
cleaner and much better.
Sorry for the noise.
Acked /
Reviewed-by: Michael Krufky mkru...@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: [PATCH] Add QAM64 support for hvr-950q (au8522)
On Tue, May 26, 2009 at 1:45 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Tue, May 26, 2009 at 2:35 PM, Tim Mester ttmest...@gmail.com wrote: From my experience it seems that 2 in 0x2005 resets the 8522 demod. All demod register setting appear to be lost after accessing any registers in the 0x2xxx range (you really, just that bit needs to be set on a i2c bus access). I am a little surprised that 0x2000 is not written to the bus to for each modulation mode. Hmmm... I would have to look closer before I could comment intelligently. Resetting all the registers could be a bad idea if there are registers being programmed that are not in the modulation block (initialization parameters such as the IF setting). Devin Yep. Setting that rest will definitely clear out the IF registers settings. It would need to be one the first things done before setting any other of the 8522 registers. (Which it almost is for VSB right now). Tim -- 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: Problem with SCM/Viaccess CAM
Le Tuesday 26 May 2009 07:43:15 Tomer Barletz, vous avez écrit : Hi, When inserting a SCM/Viaccess CAM, I get the following message: dvb_ca adapter 0: DVB CAM did not respond :( According to this: http://linuxtv.org/hg/v4l-dvb/file/142fd6020df3/linux/Documentation/dvb/ci. txt this CAM should work. I'm using kernel 2.6.10. SCM CAMs are very slow to start up. I've submitted a patch to work-around this issue a few years ago. IIRC, this was around 2.6.14. So you should upgrade your kernel HTH -- 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: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
On Tue, 26 May 2009 19:42:00 +0100, David da...@unsolicited.net wrote: I've been doing a bit of random rebooting (I don't really have time to do a full bisect), and can reproduce the usbmon panic on this machine back to 2.6.24.. so it certainly hasn't appeared that recently. Actually that's good to know, thanks a lot. I can always just stub out any attempt to peek into the IOMMU on Opterons. This would bring us back into the days of 'D' returned from everything, although maybe not so bad as we've cut out some unnecessary usb_buffer use. At least, no more crashing. -- Pete -- 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] flexcop-pci: add suspend/resume support
Hi Patrick! Hi list!
This patch adds suspend/resume support to flexcop-pci driver.
I could only test this patch with the bare card, but without having a DVB-S
signal. I checked it with and without running szap (obviously getting no
lock).
It works fine here with suspend-to-disk on a tuxonice kernel.
Setting of hw-filter in resume is done the same way as the watchdog does it:
Just looping over fc-demux.feed_list and running flexcop_pid_feed_control.
Where I am unsure is the order at resume. For now hw filters get started
first, then dma is re-started.
Do I need to give special care to irq handling?
Regards
Matthias
Index: v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop-common.h
===
--- v4l-dvb.orig/linux/drivers/media/dvb/b2c2/flexcop-common.h
+++ v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop-common.h
@@ -117,6 +117,9 @@ int flexcop_device_initialize(struct fle
void flexcop_device_exit(struct flexcop_device *fc);
void flexcop_reset_block_300(struct flexcop_device *fc);
+void flexcop_device_suspend(struct flexcop_device *fc);
+void flexcop_device_resume(struct flexcop_device *fc);
+
/* from flexcop-dma.c */
int flexcop_dma_allocate(struct pci_dev *pdev,
struct flexcop_dma *dma, u32 size);
Index: v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/b2c2/flexcop.c
+++ v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop.c
@@ -292,6 +292,59 @@ void flexcop_device_exit(struct flexcop_
}
EXPORT_SYMBOL(flexcop_device_exit);
+void flexcop_device_suspend(struct flexcop_device *fc)
+{
+ /* flexcop_device_exit does only unregister objects
+ * so just stop streaming here */
+ struct dvb_demux_feed *feed;
+
+ /* copied from flexcop_pci_irq_check_work */
+ info(stopping pid feeds);
+ spin_lock_irq(fc-demux.lock);
+ list_for_each_entry(feed, fc-demux.feed_list,
+ list_head) {
+ flexcop_pid_feed_control(fc, feed, 0);
+ }
+ spin_unlock_irq(fc-demux.lock);
+}
+EXPORT_SYMBOL(flexcop_device_suspend);
+
+void flexcop_device_resume(struct flexcop_device *fc)
+{
+ /* copied from flexcop_device_initialize */
+ struct dvb_demux_feed *feed;
+ flexcop_reset(fc);
+
+ flexcop_sram_init(fc);
+ flexcop_hw_filter_init(fc);
+ flexcop_smc_ctrl(fc, 0);
+
+ /* do the MAC address reading after initializing the dvb_adapter */
+ /* TODO: need not reread MAC address, but status was not saved */
+ if (fc-get_mac_addr(fc, 0) == 0) {
+ u8 *b = fc-dvb_adapter.proposed_mac;
+ info(MAC address = %pM, b);
+ flexcop_set_mac_filter(fc, b);
+ flexcop_mac_filter_ctrl(fc, 1);
+ } else
+ warn(reading of MAC address failed.\n);
+
+ /* TODO: Is it fine to start streaming here,
+ * before DMA is re-initialized */
+
+ /* copied from flexcop_pci_irq_check_work */
+ info(restarting pid feeds);
+ spin_lock_irq(fc-demux.lock);
+ list_for_each_entry(feed, fc-demux.feed_list,
+ list_head) {
+ flexcop_pid_feed_control(fc, feed, 1);
+ }
+ spin_unlock_irq(fc-demux.lock);
+
+ flexcop_device_name(fc, resume of, complete);
+}
+EXPORT_SYMBOL(flexcop_device_resume);
+
static int flexcop_module_init(void)
{
info(DRIVER_NAME loaded successfully);
Index: v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop-pci.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/b2c2/flexcop-pci.c
+++ v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop-pci.c
@@ -319,8 +319,6 @@ static int flexcop_pci_init(struct flexc
pci_read_config_byte(fc_pci-pdev, PCI_CLASS_REVISION, card_rev);
info(card revision %x, card_rev);
- if ((ret = pci_enable_device(fc_pci-pdev)) != 0)
- return ret;
pci_set_master(fc_pci-pdev);
if ((ret = pci_request_regions(fc_pci-pdev, DRIVER_NAME)) != 0)
@@ -334,7 +332,6 @@ static int flexcop_pci_init(struct flexc
goto err_pci_release_regions;
}
- pci_set_drvdata(fc_pci-pdev, fc_pci);
spin_lock_init(fc_pci-irq_lock);
if ((ret = request_irq(fc_pci-pdev-irq, flexcop_pci_isr,
IRQF_SHARED, DRIVER_NAME, fc_pci)) != 0)
@@ -345,7 +342,6 @@ static int flexcop_pci_init(struct flexc
err_pci_iounmap:
pci_iounmap(fc_pci-pdev, fc_pci-io_mem);
- pci_set_drvdata(fc_pci-pdev, NULL);
err_pci_release_regions:
pci_release_regions(fc_pci-pdev);
err_pci_disable_device:
@@ -358,9 +354,7 @@ static void flexcop_pci_exit(struct flex
if (fc_pci-init_state FC_PCI_INIT) {
free_irq(fc_pci-pdev-irq, fc_pci);
pci_iounmap(fc_pci-pdev, fc_pci-io_mem);
- pci_set_drvdata(fc_pci-pdev, NULL);
pci_release_regions(fc_pci-pdev);
- pci_disable_device(fc_pci-pdev);
}
fc_pci-init_state = ~FC_PCI_INIT;
}
@@ -399,6 +393,11 @@ static int flexcop_pci_probe(struct pci_
/* bus specific part */
fc_pci-pdev = pdev;
+ ret = pci_enable_device(pdev);
+ if (ret != 0)
+ goto err_kfree;
+
+ pci_set_drvdata(pdev, fc_pci);
if ((ret = flexcop_pci_init(fc_pci)) != 0)
goto err_kfree;
@@ -428,6 +427,7 @@ err_fc_exit:
err_pci_exit:
Re: dvb_usb_nova_t_usb2: firmware is loaded too late
Le Monday 25 May 2009 22:11:49 Dominique Dumont, vous avez écrit : I have some trouble with the initialisation of dvb_usb_nova_t_usb2: the firmware is loaded about 1 minute after the module is registered by usbcore: Sorry, I forgot to mention my kernel version 2.6.29.3 (Debian/sid amd64 kernel) I did not have any loading problem with 2.6.28, the issue appeared only with 2.6.29. HTH -- 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] EPG (Electronic Program Guide) Tools
On Tuesday, May 26, 2009, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Tue, May 26, 2009 at 1:51 PM, Chris Capon ttab...@gmail.com wrote: Hi: I've installed an HVR-1600 card in a Debian system to receive ATSC digital broadcasts here in Canada. Everything works great. scan /usr/share/dvb/atsc/us-ATSC-center-frequencies-8VSB channels.conf finds a complete list of broadcasters. azap -c channels.conf -r channel-name tunes in the stations and displays signal strength info. cp /dev/dvb/adapter0/dvr0 xx.mpg captures the output stream which can be played by mplayer. What I'm missing is information about the Electronic Program Guide (EPG). There doesn't seem to be much info on linuxtv.org on how to read it. Where does the EPG come from? Is it incorporated into the output stream through PID's some how or is it read from one of the other devices under adapter0? Are there simple command line tools to read it or do you have to write a custom program to interpret it somehow? Could someone please point me in the right direction to get started? If no tools exist, perhaps links to either api or lib docs/samples? Much appreciated. Chris. Hello Chris, The ATSC EPG is sent via the ATSC PSIP protocol. I do not know of any tools currently available to extract the information. MeTV has a working implementation (with some bugs I have seen), and I was looking at getting it to work in Kaffeine at some point. Dvbstreamer supports atsc epg. That is what i use The spec is freely available here: http://www.atsc.org/standards/a_65cr1_with_amend_1.pdf If you have any questions, feel free to drop me a line. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ___ 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 -- ASUS m3a78 mothorboard AMD Athlon64 X2 Dual Core Processor 6000+ 3.1Ghz 4 Gigabytes of memory Gigabyte NVidia 9400gt Graphics adapter Kworld ATSC 110 TV Capture Card Kworld ATSC 115 TV Capture Card -- 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] EPG (Electronic Program Guide) Tools
On Tue, May 26, 2009 at 3:18 PM, Jonathan Isom jei...@gmail.com wrote: Dvbstreamer supports atsc epg. That is what i use Well, learn something new every day. I didn't realize dvbstreamer had ATSC support. 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: [linux-dvb] EPG (Electronic Program Guide) Tools
On Tue, May 26, 2009 at 2:31 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Tue, May 26, 2009 at 3:18 PM, Jonathan Isom jei...@gmail.com wrote: Dvbstreamer supports atsc epg. That is what i use Well, learn something new every day. I didn't realize dvbstreamer had ATSC support. Yep. Don't confuse with dvbstream. Separate apps. with dvbstreamer you have to cycle the channels with a script to fill the data for each channel. Later Jonathan Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- ASUS m3a78 mothorboard AMD Athlon64 X2 Dual Core Processor 6000+ 3.1Ghz 4 Gigabytes of memory Gigabyte NVidia 9400gt Graphics adapter Kworld ATSC 110 TV Capture Card Kworld ATSC 115 TV Capture Card -- 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] SDMC DM1105N not being detected
Igor M. Liplianin wrote: The card is working with external LNB power supply, for example, through the loop out from another sat box. So, we need to know, which way to control LNB power on the board. Usually it is through GPIO pins. For example: Pins 112 and 111 for GPIO0, GPIO1. Also GPIO15 is at 65 pin. You can edit this lines in code: -*-*-*-*-*-*-*-*-*-*-*-*- /* GPIO's for LNB power control for Axess DM05 */ #define DM05_LNB_MASK 0xfffc // GPIO control #define DM05_LNB_13V0x3fffd // GPIO value #define DM05_LNB_18V0x3fffc // GPIO value -*-*-*-*-*-*-*-*-*-*-*-*- BTW: Bit value 0 for GPIOCTL means output, 1 - input. Bit value for GPIOVAL - read/write. GPIO pins count is 18. Bits over 18 affect nothing. i will try to work out the correct values when i have done so (or given up trying) i will let you know thank you very much for your help -- simon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)
I should add that the picture quality is with all tested tuner types worse than with my PVR250/350. I don't know if a PVR150 is in generally worse than a PVR250. I can't call it really noisy, but in german I would say the picture is a little bit grobkörnig. It really needs a temporal filter setting of value 8 or more, while my other PVR cards have a nice quality even with value 0. I will test whatever you guys want me to test :-) But I am not a programmer, so I need detailled instructions what to patch. My next step will be testing an older v4l2 with an 2.6.27 kernel to see if the audio problem still exists. -- 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]V4L:some v4l drivers have error for video_register_device
For video_register_device(), it return zero means register success.It would be
return zero
or a negative number (on failure),it would not return a positive number.so it
have better to
use this to check err:
int err = video_register_device(vdev, VFL_TYPE_GRABBER, -1);
if (err != 0) {
/*err code*/
}
Signed-off-by: Figo.zhang figo1...@gmail.com
---
Documentation/video4linux/v4l2-framework.txt |2 +-
drivers/media/radio/radio-maestro.c |2 +-
drivers/media/radio/radio-si470x.c |2 +-
drivers/media/video/cafe_ccic.c |2 +-
drivers/media/video/cx231xx/cx231xx-video.c |2 +-
drivers/media/video/em28xx/em28xx-video.c|2 +-
drivers/media/video/et61x251/et61x251_core.c |2 +-
drivers/media/video/hdpvr/hdpvr-video.c |2 +-
drivers/media/video/ivtv/ivtv-streams.c |2 +-
drivers/media/video/sn9c102/sn9c102_core.c |2 +-
drivers/media/video/stk-webcam.c |2 +-
drivers/media/video/w9968cf.c|2 +-
drivers/media/video/zc0301/zc0301_core.c |2 +-
drivers/media/video/zr364xx.c|2 +-
sound/i2c/other/tea575x-tuner.c |2 +-
15 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/Documentation/video4linux/v4l2-framework.txt
b/Documentation/video4linux/v4l2-framework.txt
index 854808b..250232a 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -447,7 +447,7 @@ Next you register the video device: this will create the
character device
for you.
err = video_register_device(vdev, VFL_TYPE_GRABBER, -1);
- if (err) {
+ if (err != 0) {
video_device_release(vdev); /* or kfree(my_vdev); */
return err;
}
diff --git a/drivers/media/radio/radio-maestro.c
b/drivers/media/radio/radio-maestro.c
index 64d737c..b5e93c2 100644
--- a/drivers/media/radio/radio-maestro.c
+++ b/drivers/media/radio/radio-maestro.c
@@ -379,7 +379,7 @@ static int __devinit maestro_probe(struct pci_dev *pdev,
video_set_drvdata(dev-vdev, dev);
retval = video_register_device(dev-vdev, VFL_TYPE_RADIO, radio_nr);
- if (retval) {
+ if (retval != 0) {
v4l2_err(v4l2_dev, can't register video device!\n);
goto errfr1;
}
diff --git a/drivers/media/radio/radio-si470x.c
b/drivers/media/radio/radio-si470x.c
index bd945d0..edb520a 100644
--- a/drivers/media/radio/radio-si470x.c
+++ b/drivers/media/radio/radio-si470x.c
@@ -1740,7 +1740,7 @@ static int si470x_usb_driver_probe(struct usb_interface
*intf,
/* register video device */
retval = video_register_device(radio-videodev, VFL_TYPE_RADIO,
radio_nr);
- if (retval) {
+ if (retval != 0) {
printk(KERN_WARNING DRIVER_NAME
: Could not register video device\n);
goto err_all;
diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c
index c4d181d..fd93698 100644
--- a/drivers/media/video/cafe_ccic.c
+++ b/drivers/media/video/cafe_ccic.c
@@ -1974,7 +1974,7 @@ static int cafe_pci_probe(struct pci_dev *pdev,
/* cam-vdev.debug = V4L2_DEBUG_IOCTL_ARG;*/
cam-vdev.v4l2_dev = cam-v4l2_dev;
ret = video_register_device(cam-vdev, VFL_TYPE_GRABBER, -1);
- if (ret)
+ if (ret != 0)
goto out_smbus;
video_set_drvdata(cam-vdev, cam);
diff --git a/drivers/media/video/cx231xx/cx231xx-video.c
b/drivers/media/video/cx231xx/cx231xx-video.c
index a23ae73..14e5008 100644
--- a/drivers/media/video/cx231xx/cx231xx-video.c
+++ b/drivers/media/video/cx231xx/cx231xx-video.c
@@ -2382,7 +2382,7 @@ int cx231xx_register_analog_devices(struct cx231xx *dev)
/* register v4l2 video video_device */
ret = video_register_device(dev-vdev, VFL_TYPE_GRABBER,
video_nr[dev-devno]);
- if (ret) {
+ if (ret != 0) {
cx231xx_errdev(unable to register video device (error=%i).\n,
ret);
return ret;
diff --git a/drivers/media/video/em28xx/em28xx-video.c
b/drivers/media/video/em28xx/em28xx-video.c
index 882796e..dcc3aca 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -2013,7 +2013,7 @@ int em28xx_register_analog_devices(struct em28xx *dev)
/* register v4l2 video video_device */
ret = video_register_device(dev-vdev, VFL_TYPE_GRABBER,
video_nr[dev-devno]);
- if (ret) {
+ if (ret != 0) {
em28xx_errdev(unable to register video device (error=%i).\n,
ret);
return ret;
diff --git a/drivers/media/video/et61x251/et61x251_core.c
b/drivers/media/video/et61x251/et61x251_core.c
index d1c1e45..8a767e1 100644
Re: [ivtv-devel] tveeprom cannot autodetect tuner! (FQ1216LME MK5)
Andy Walls wrote: Hermann, There is an FQ1216LME MK3 data sheet here: http://dl.ivtvdriver.org/datasheets/tuners/FQ1216LME%20Mk3.pdf Is it safe to assume that the MK5 is not very different from the MK3? I am no expert on the subject, but I found this reference to the MK3 vs MK5: http://www.nxp.com/acrobat_download/other/products/rf/fq_mk5.pdf Where it says The FQ1200 MK5 family is identical in footprint to the FQ1200 MK3 series, ensuring a quick drop-in replacement. If the MK5 family is designed as a drop in replacement for the MK3 family, I would think there is a good chance it functions exactly the same. Anthony -- 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
