Re: TBS 6980 Dual Tuner PCI-e card.....not in Wiki at all?
Another Sillyname wrote: Guys The TBS 6920 PCI-e card is in the Wiki and is a supported card. The TBS 6980 dual tuner PCI-e card is not in the Wiki at all, is there a reason for this given they have released a non GPL blob at least? Because the wiki relies upon user contributions. No contributions, no information. Simple as that. Also is there a reason that an indicative price for supported cards is not shown in the wiki? It would save a load of time rather then having to search on each card only to find out it's ridiculously priced at $1000. I for one am not particularly keen on inclusion of prices because: - prices are highly subject to temporal variance (i.e. what costs $150 now could be $80 in six months) - prices are often highly variant across broad geographical regions (i.e. what costs $70US in America could, after accounting for exchange rates, cost an equivalent of $100US within Canada) - prices are often highly variant within local geographical markets (i.e what costs $99 at the local big box Bestbuy store could easily cost $79 at the local mompop computer store) - prices require regular updating/maintenance in order for them to be in any way indicative ... the wiki relies upon user contributions ... ergo, I can already tell you in advance that its not going to happen (because its a time consuming endeavour, and there is no critical mass of contributors to keep the information relevant), and so, any original submissions will inevitably just end up suffering information rot (and, thus, end up not being indicative or of particular use for the end user). -- 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: ir-core multi-protocol decode and mceusb
On Sun, May 30, 2010 at 3:57 PM, Jarod Wilson ja...@wilsonet.com wrote: On Sun, May 30, 2010 at 10:02 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 29-05-2010 23:24, Jarod Wilson escreveu: On Sat, May 29, 2010 at 4:01 PM, Andy Walls awa...@md.metrocast.net wrote: ... We do have the option to disable all but the relevant protocol handler on a per-device basis though, if that's a problem. Hrm, the key tables also have a protocol tied to them, not sure if that's taken into account when doing matching... Still getting to know the code. :) It does not look like ir_keydown() ir_g_keycode_from_table() ir_getkeycode() bother to check the ir_type (e.g. IR_TYPE_NEC) of the keymap against the decoders type. Neither do the decoders themselves. If a decoder decodes something and thinks its valid, it tries to send a key event with ir_keydown(). ir_keydown() won't send a key event if the lookup comes back KEY_RESERVED, but it doesn't tell the decoder about the failure to find a key mapping. A decoder can come back saying it did it's job, without knowing whether or not the decoding corresponded to a valid key in the loaded keymap. :( You will have to deal with the case that two or more decoders may match and each sends an IR event. (Unless the ir-core already deals with this somehow...) Well, its gotta decode correctly to a value, and then match a value in the loaded key table for an input event to get sent through. At least for the RC6 MCE remotes, I haven't seen any of the other decoders take the signal and interpret it as valid -- which ought to be by design, if you consider that people use several different remotes with varying ir signals with different devices all receiving them all the time without problems (usually). And if we're not already, we could likely add some logic to give higher precedence to values arrived at using the protocol decoder that matches the key table we've got loaded for a given device. After looking at things, the only potential problem I can see right now is with the JVC decoder and NEC remotes. I think that problem is most easily eliminated either by a. having ir_keydown() (or the functions it calls) check to see that the decoder matches the loaded keymap, or b. only calling the decoder that matches the loaded keymap's protocol Of the above, b. saves processor cycles and frees up the global ir_raw_handler spin lock sooner. That spin lock is serializing pulse decoding for all the IR receivers in the system (pulse decoding can still be interleaved, just only one IR receiver's pulses are be processed at any time). What's the point of running decoders that should never match the loaded keymap? For the daily use case where a known-good keymap is in place, I'm coming to the conclusion that there's no point, we're only wasting resources. For initial figure out what this remote is type of stuff, running all decoders makes sense. One thought I had was that perhaps we start by running through the decoder that is listed in the keymap. If it decodes to a scancode and we find a valid key in the key table (i.e., not KEY_RESERVED), we're done. If decoding fails or we don't find a valid key, then try the other decoders. However, this is possibly also wasteful -- most people with any somewhat involved htpc setup are going to be constantly sending IR signals intended for other devices that we pick up and try to decode. So I'd say we go with your option b, and only call the decoder that matches the loaded keymap. One could either pass in a modparam or twiddle a sysfs attr or use ir-keytable to put the receiver into a mode that called all decoders -- i.e., set protocol to IR_TYPE_UNKNOWN, with the intention being to figure it out based on running all decoders, and create a new keymap where IR_TYPE_FOO is known. There's no need to extra parameters. Decoders can be disabled by userspace, per each rc sysfs node. Btw, the current version of ir-keytable already sets the enabled protocols based on the protocol reported by the rc keymap. What it makes sense is to add a patch at RC core that will properly enable/disable the protocols based on IR_TYPE, when the rc-map is stored in-kernel. Ah, yeah, that does make sense. And if we add that, ir-keytable doesn't actually have to worry about doing similar itself any longer. If you're not already working on it, I can try to whip something up, though I'm knee-deep in an ir-lirc-codec bridge right now... I've now got an ir-lirc-codec bridge passing data over to a completely unmodified lirc_dev, with the data then making its way out to the lircd userspace where its even getting properly decoded. I don't have the transmit side of things in ir-lirc-codec wired up just yet, but I'd like to submit what I've got (after some cleanup) tomorrow, and will then incrementally work on transmit. I'm pretty sure wiring up transmit is
Re: mt9m111 swap_rgb_red_blue
On Mon, 31 May 2010, Robert Jarzmik wrote: Sascha Hauer s.ha...@pengutronix.de writes: Hi Robert, I have digged around in the Datasheet and if I understand it correctly the PXA swaps red/blue in RGB mode. So if we do not use rgb mode but yuv (which should be a pass through) we should be able to support rgb on PXA aswell. Robert, can you confirm that with the following patch applied you still get an image but with red/blue swapped? I can confirm the color swap. If you want to follow that path, I would suggest instead : cicr1 |= CICR1_COLOR_SP_VAL(0); There is no difference from a processing point of view, it's just that CICR1_COLOR_SP_VAL(0) is raw colorspace, with means pass through, and that seems to be your goal here. That would be the default case in that switch, but raw only supports 8, 9, or 10 bpp, so, you'd have to use 8bpp but then fake the pixels-per-line field. But that would be the cleanest way, yes. Would that work like that? Note that the patch would have to be completed with the BGR565 into RGB565 conversion, if the sensor was to provide only BGR565. But that could very well be for another patch. 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Mon, 31 May 2010 00:03:10 +0200 Ondrej Zary li...@rainbow-software.org wrote: I would try extracting a JPEG header from one of the files captured by the camera in stand alone mode (either a JPEG still or MJPEG file), and put that header together with the image data from the USB capture. It may not look perfect, but hopefully you will get something you recognize. Just thought about the same thing so I uploaded a video file: http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi Attached was Theodore's first attempt of such a procedure with a header extracted from a standalone image file from my Jeilin based camera and USB snoop data from the same camera. It wasn't perfect, but it was recognizable. I could not believe it! I already tried the image as JPEG, but I got just big colored pixels. I changed the 'samples Y' from 21 to 22 and I got something coherent! Here is the same image as yesterday with JPEG 411 header, compression quality 80% and insertion of 0x00 after 0xff. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ attachment: image640.jpg
Re: [PATCH 1/3] Gspca-gl860 driver update
On Mon, 31 May 2010 00:24:21 +0200 Olivier Lorin olori...@gmail.com wrote: - Change of rounded image resolutions to the real ones - Fix for an irrelevant OV9655 image resolution identifier name - Extra spaces to align some variable names and a defined value Hi Olivier, If I can anticipate, the changes are too different. You should split this patch. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] Compro Videomate T750F Vista digital+analog support
HI! I just went to compro website and have seen that *f cards have some identical MCE-alike but also slightly different remotes, so we have to invent some better names to distinguish between them (compro itself might have some names for them) d. -- 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: mt9m111 swap_rgb_red_blue
On Mon, May 31, 2010 at 08:46:00AM +0200, Guennadi Liakhovetski wrote: On Mon, 31 May 2010, Robert Jarzmik wrote: Sascha Hauer s.ha...@pengutronix.de writes: Hi Robert, I have digged around in the Datasheet and if I understand it correctly the PXA swaps red/blue in RGB mode. So if we do not use rgb mode but yuv (which should be a pass through) we should be able to support rgb on PXA aswell. Robert, can you confirm that with the following patch applied you still get an image but with red/blue swapped? I can confirm the color swap. If you want to follow that path, I would suggest instead : cicr1 |= CICR1_COLOR_SP_VAL(0); There is no difference from a processing point of view, it's just that CICR1_COLOR_SP_VAL(0) is raw colorspace, with means pass through, and that seems to be your goal here. That would be the default case in that switch, but raw only supports 8, 9, or 10 bpp, so, you'd have to use 8bpp but then fake the pixels-per-line field. That's why I suggested yuv. I could leave a big comment why this is done, but I would implement it using raw mode aswell if that's prefered. But that would be the cleanest way, yes. Would that work like that? Note that the patch would have to be completed with the BGR565 into RGB565 conversion, if the sensor was to provide only BGR565. But that could very well be for another patch. Will do, I just wanted to see if this works at all. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Monday 31 May 2010, Jean-Francois Moine wrote: On Mon, 31 May 2010 00:03:10 +0200 Ondrej Zary li...@rainbow-software.org wrote: I would try extracting a JPEG header from one of the files captured by the camera in stand alone mode (either a JPEG still or MJPEG file), and put that header together with the image data from the USB capture. It may not look perfect, but hopefully you will get something you recognize. Just thought about the same thing so I uploaded a video file: http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi Attached was Theodore's first attempt of such a procedure with a header extracted from a standalone image file from my Jeilin based camera and USB snoop data from the same camera. It wasn't perfect, but it was recognizable. I could not believe it! I already tried the image as JPEG, but I got just big colored pixels. I changed the 'samples Y' from 21 to 22 and I got something coherent! Here is the same image as yesterday with JPEG 411 header, compression quality 80% and insertion of 0x00 after 0xff. That's great - that's what it should look like! It's a part of LCD monitor and a shelf above it. -- Ondrej Zary -- 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: Regarding OMAP 35xx ISP subsystem and SoC-Camera
Hi Manjunathan, On Friday 28 May 2010 15:54:57 manjunathan.pa...@wipro.com wrote: Dear Linux-media group I am a newbie and have recently started working on integration of a new camera sensor MT9M112 sensor with OMAP ISP Camera subsystem on a OMAP 3530 based custom board. So I checked in mainline kernel if driver is available for this camera sensor and I found it in the Linux/driver/media/video/mt9m11.c, this supports both MT9M111 and MT9M112. It is based on SoC-Camera framework. But unfortunately this is not compatible with OMAP 35xx Camera ISP subsystem as OMAP camera ISP subsystem is based on V4L2-INT. The OMAP3 ISP driver doesn't use the deprecated V4L2 int-device API anymore. The latest version of the driver can be found in the omap3camera tree on gitorious (make sure you checkout the devel branch). Also I got know that there are there are 3 different frameworks for camera sensor drivers in Linux a. V4L2-INT is deprecated but currently supported by OMAP35xx ISP Linux BSP b. SoC-Camera is also deprecated. c. Sub-Device is the current architecture supported from Open source community 1. Is this understanding correct ? That's correct. The OMAP35xx ISP driver in the Linux BSP is also deprecated :-) 2. Since V4L2-INT and SoC-Camera frameworks are deprecated, can you please let me know the roadmap for Sub-Device framework ? The soc-camera framework isn't deprecated, but it isn't used by the OMAP3 ISP driver either. 3. What is the best option/recommendation from community for me to integrate MT9M112 with Camera ISP system on OMAP 3530 based board ? The dependencies on the soc-camera framework in the MT9M112 driver need to be removed. I've CC'ed Guennadi Liakhovetski to this e-mail, he's the author of the soc-camera framework and should be able to provide information on what is required. 4. And lastly are there any other different camera sensors which have Sub- Device based drivers available in Mainline Linux? Not that I know of, but there's a video decoder driver (tvp5150). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 06/11] V4L/DVB: omap_vout: Storage class should be before const qualifier
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Tobias Klauser
Sent: Thursday, May 20, 2010 2:06 PM
To: mche...@infradead.org; linux-media@vger.kernel.org
Cc: kernel-janit...@vger.kernel.org; Tobias Klauser
Subject: [PATCH 06/11] V4L/DVB: omap_vout: Storage class should be before
const qualifier
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser tklau...@distanz.ch
---
drivers/media/video/omap/omap_vout.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 4c0ab49..d6a2ae1 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -128,7 +128,7 @@ module_param(debug, bool, S_IRUGO);
MODULE_PARM_DESC(debug, Debug level (0-1));
/* list of image formats supported by OMAP2 video pipelines */
-const static struct v4l2_fmtdesc omap_formats[] = {
+static const struct v4l2_fmtdesc omap_formats[] = {
{
/* Note: V4L2 defines RGB565 as:
*
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Thanks,
Vaibhav
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] libv4l1: Move VIDIOCGFBUF into libv4l1
From: Huzaifa Sidhpurwala huzai...@fedora-12.(none)
Move VIDIOCGFBUF into libv4l1
Signed-off-by: Huzaifa Sidhpurwala huzai...@redhat.com
---
lib/libv4l1/libv4l1.c | 45 +
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index e13feba..5b2dc29 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -804,6 +804,51 @@ int v4l1_ioctl(int fd, unsigned long int request, ...)
break;
}
+ case VIDIOCGFBUF: {
+ struct video_buffer *buffer = arg;
+ struct v4l2_framebuffer fbuf = { 0, };
+
+ result = v4l2_ioctl(fd, VIDIOC_G_FBUF, buffer);
+ if (result 0)
+ break;
+
+ buffer-base = fbuf.base;
+ buffer-height = fbuf.fmt.height;
+ buffer-width = fbuf.fmt.width;
+
+ switch (fbuf.fmt.pixelformat) {
+ case V4L2_PIX_FMT_RGB332:
+ buffer-depth = 8;
+ break;
+ case V4L2_PIX_FMT_RGB555:
+ buffer-depth = 15;
+ break;
+ case V4L2_PIX_FMT_RGB565:
+ buffer-depth = 16;
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ buffer-depth = 24;
+ break;
+ case V4L2_PIX_FMT_BGR32:
+ buffer-depth = 32;
+ break;
+ default:
+ buffer-depth = 0;
+ }
+
+ if (fbuf.fmt.bytesperline) {
+ buffer-bytesperline = fbuf.fmt.bytesperline;
+ if (!buffer-depth buffer-width)
+ buffer-depth = ((fbuf.fmt.bytesperline3)
+ + (buffer-width-1))
+ / buffer-width;
+ } else {
+ buffer-bytesperline =
+ (buffer-width * buffer-depth + 7) 7;
+ buffer-bytesperline = 3;
+ }
+ }
+
default:
/* Pass through libv4l2 for applications which are using v4l2
through
libv4l1 (this can happen with the v4l1compat.so wrapper
preloaded */
--
1.6.6.1
--
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: Regarding OMAP 35xx ISP subsystem and SoC-Camera
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, May 31, 2010 1:29 PM To: manjunathan.pa...@wipro.com; Guennadi Liakhovetski Cc: linux-media@vger.kernel.org Subject: Re: Regarding OMAP 35xx ISP subsystem and SoC-Camera Hi Manjunathan, On Friday 28 May 2010 15:54:57 manjunathan.pa...@wipro.com wrote: Dear Linux-media group I am a newbie and have recently started working on integration of a new camera sensor MT9M112 sensor with OMAP ISP Camera subsystem on a OMAP 3530 based custom board. So I checked in mainline kernel if driver is available for this camera sensor and I found it in the Linux/driver/media/video/mt9m11.c, this supports both MT9M111 and MT9M112. It is based on SoC-Camera framework. But unfortunately this is not compatible with OMAP 35xx Camera ISP subsystem as OMAP camera ISP subsystem is based on V4L2-INT. The OMAP3 ISP driver doesn't use the deprecated V4L2 int-device API anymore. The latest version of the driver can be found in the omap3camera tree on gitorious (make sure you checkout the devel branch). Also I got know that there are there are 3 different frameworks for camera sensor drivers in Linux a. V4L2-INT is deprecated but currently supported by OMAP35xx ISP Linux BSP b. SoC-Camera is also deprecated. c. Sub-Device is the current architecture supported from Open source community 1. Is this understanding correct ? That's correct. The OMAP35xx ISP driver in the Linux BSP is also deprecated :-) 2. Since V4L2-INT and SoC-Camera frameworks are deprecated, can you please let me know the roadmap for Sub-Device framework ? The soc-camera framework isn't deprecated, but it isn't used by the OMAP3 ISP driver either. 3. What is the best option/recommendation from community for me to integrate MT9M112 with Camera ISP system on OMAP 3530 based board ? The dependencies on the soc-camera framework in the MT9M112 driver need to be removed. I've CC'ed Guennadi Liakhovetski to this e-mail, he's the author of the soc-camera framework and should be able to provide information on what is required. 4. And lastly are there any other different camera sensors which have Sub- Device based drivers available in Mainline Linux? Not that I know of, but there's a video decoder driver (tvp5150). [Hiremath, Vaibhav] Also we have TVP514x video decoder driver. Thanks, Vaibhav -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Can not get EIT infi
Hello everybody! I a KWorld PlusTV Dual DVB-T Stick (DVB-T 399U) device, I use it on MythTV, the problem is that I can not get any EIT info fron this stick, I try wit other stick and it works. How can I try to get EIT? I can watch TV channels well. I use Debian Squeeze with dvb-usb-af9015.fw firmware. Thanks for all and regards. -- Josu Lazkano -- 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: ir-core multi-protocol decode and mceusb
On Mon, 2010-05-31 at 02:20 -0400, Jarod Wilson wrote: On Sun, May 30, 2010 at 3:57 PM, Jarod Wilson ja...@wilsonet.com wrote: On Sun, May 30, 2010 at 10:02 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 29-05-2010 23:24, Jarod Wilson escreveu: On Sat, May 29, 2010 at 4:01 PM, Andy Walls awa...@md.metrocast.net wrote: ... We do have the option to disable all but the relevant protocol handler on a per-device basis though, if that's a problem. Hrm, the key tables also have a protocol tied to them, not sure if that's taken into account when doing matching... Still getting to know the code. :) It does not look like ir_keydown() ir_g_keycode_from_table() ir_getkeycode() bother to check the ir_type (e.g. IR_TYPE_NEC) of the keymap against the decoders type. Neither do the decoders themselves. If a decoder decodes something and thinks its valid, it tries to send a key event with ir_keydown(). ir_keydown() won't send a key event if the lookup comes back KEY_RESERVED, but it doesn't tell the decoder about the failure to find a key mapping. A decoder can come back saying it did it's job, without knowing whether or not the decoding corresponded to a valid key in the loaded keymap. :( You will have to deal with the case that two or more decoders may match and each sends an IR event. (Unless the ir-core already deals with this somehow...) Well, its gotta decode correctly to a value, and then match a value in the loaded key table for an input event to get sent through. At least for the RC6 MCE remotes, I haven't seen any of the other decoders take the signal and interpret it as valid -- which ought to be by design, if you consider that people use several different remotes with varying ir signals with different devices all receiving them all the time without problems (usually). And if we're not already, we could likely add some logic to give higher precedence to values arrived at using the protocol decoder that matches the key table we've got loaded for a given device. After looking at things, the only potential problem I can see right now is with the JVC decoder and NEC remotes. I think that problem is most easily eliminated either by a. having ir_keydown() (or the functions it calls) check to see that the decoder matches the loaded keymap, or b. only calling the decoder that matches the loaded keymap's protocol Of the above, b. saves processor cycles and frees up the global ir_raw_handler spin lock sooner. That spin lock is serializing pulse decoding for all the IR receivers in the system (pulse decoding can still be interleaved, just only one IR receiver's pulses are be processed at any time). What's the point of running decoders that should never match the loaded keymap? For the daily use case where a known-good keymap is in place, I'm coming to the conclusion that there's no point, we're only wasting resources. For initial figure out what this remote is type of stuff, running all decoders makes sense. One thought I had was that perhaps we start by running through the decoder that is listed in the keymap. If it decodes to a scancode and we find a valid key in the key table (i.e., not KEY_RESERVED), we're done. If decoding fails or we don't find a valid key, then try the other decoders. However, this is possibly also wasteful -- most people with any somewhat involved htpc setup are going to be constantly sending IR signals intended for other devices that we pick up and try to decode. So I'd say we go with your option b, and only call the decoder that matches the loaded keymap. One could either pass in a modparam or twiddle a sysfs attr or use ir-keytable to put the receiver into a mode that called all decoders -- i.e., set protocol to IR_TYPE_UNKNOWN, with the intention being to figure it out based on running all decoders, and create a new keymap where IR_TYPE_FOO is known. There's no need to extra parameters. Decoders can be disabled by userspace, per each rc sysfs node. Btw, the current version of ir-keytable already sets the enabled protocols based on the protocol reported by the rc keymap. What it makes sense is to add a patch at RC core that will properly enable/disable the protocols based on IR_TYPE, when the rc-map is stored in-kernel. Ah, yeah, that does make sense. And if we add that, ir-keytable doesn't actually have to worry about doing similar itself any longer. If you're not already working on it, I can try to whip something up, though I'm knee-deep in an ir-lirc-codec bridge right now... I've now got an ir-lirc-codec bridge passing data over to a completely unmodified lirc_dev, with the data then making its way out to the lircd userspace where its even getting properly decoded. I don't have the transmit side of things in ir-lirc-codec wired up
RE: Regarding OMAP 35xx ISP subsystem and SoC-Camera
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, May 31, 2010 1:29 PM To: manjunathan.pa...@wipro.com; Guennadi Liakhovetski Cc: linux-media@vger.kernel.org Subject: Re: Regarding OMAP 35xx ISP subsystem and SoC-Camera Hi Manjunathan, [Hiremath, Vaibhav] Just clarifying some the things - On Friday 28 May 2010 15:54:57 manjunathan.pa...@wipro.com wrote: Dear Linux-media group I am a newbie and have recently started working on integration of a new camera sensor MT9M112 sensor with OMAP ISP Camera subsystem on a OMAP 3530 based custom board. So I checked in mainline kernel if driver is available for this camera sensor and I found it in the Linux/driver/media/video/mt9m11.c, this supports both MT9M111 and MT9M112. It is based on SoC-Camera framework. But unfortunately this is not compatible with OMAP 35xx Camera ISP subsystem as OMAP camera ISP subsystem is based on V4L2-INT. The OMAP3 ISP driver doesn't use the deprecated V4L2 int-device API anymore. The latest version of the driver can be found in the omap3camera tree on gitorious (make sure you checkout the devel branch). [Hiremath, Vaibhav] Manjunathan, Please note that this is based on Media controller concept which is new framework or interface we are working on. Also I got know that there are there are 3 different frameworks for camera sensor drivers in Linux a. V4L2-INT is deprecated but currently supported by OMAP35xx ISP Linux BSP b. SoC-Camera is also deprecated. c. Sub-Device is the current architecture supported from Open source community 1. Is this understanding correct ? That's correct. The OMAP35xx ISP driver in the Linux BSP is also deprecated :-) 2. Since V4L2-INT and SoC-Camera frameworks are deprecated, can you please let me know the roadmap for Sub-Device framework ? The soc-camera framework isn't deprecated, but it isn't used by the OMAP3 ISP driver either. [Hiremath, Vaibhav] Laurent, I believe going forward this SoC-Camera will get also deprecated and all drivers will be migrated to sub-device framework. Thanks, Vaibhav 3. What is the best option/recommendation from community for me to integrate MT9M112 with Camera ISP system on OMAP 3530 based board ? The dependencies on the soc-camera framework in the MT9M112 driver need to be removed. I've CC'ed Guennadi Liakhovetski to this e-mail, he's the author of the soc-camera framework and should be able to provide information on what is required. 4. And lastly are there any other different camera sensors which have Sub- Device based drivers available in Mainline Linux? Not that I know of, but there's a video decoder driver (tvp5150). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Regarding OMAP 35xx ISP subsystem and SoC-Camera
On Mon, 31 May 2010, Hiremath, Vaibhav wrote: 2. Since V4L2-INT and SoC-Camera frameworks are deprecated, can you please let me know the roadmap for Sub-Device framework ? The soc-camera framework isn't deprecated, but it isn't used by the OMAP3 ISP driver either. [Hiremath, Vaibhav] Laurent, I believe going forward this SoC-Camera will get also deprecated and all drivers will be migrated to sub-device framework. Vaibhav, I think you're misunderstanding. The soc-camera framework has been designed to fulfill two tasks: (1) create a standard interface between (SoC) camera hosts and video clients, and (2) to simplify implementation of new camera host drivers by taking a part of common for many SoC camera controllers functionality into the soc-camera core. The first task is being replaced by v4l2-subdev, that's correct. But I so far don't see a compelling reason to obsolete the 2nd task, which would migrate that common functionality into each camera host driver. New camera host driver authors are free to either use or not to use soc-camera. If they think, the functionality provided by soc-camera core fits well with their hardware, they can use it. If they think, it is imposing too many restrictions and their hardware is more complicated, than what soc-camera offers, then they can write a complete v4l2-device driver. 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: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Mon, 2010-05-31 at 09:19 +0200, Jean-Francois Moine wrote: On Mon, 31 May 2010 00:03:10 +0200 Ondrej Zary li...@rainbow-software.org wrote: I would try extracting a JPEG header from one of the files captured by the camera in stand alone mode (either a JPEG still or MJPEG file), and put that header together with the image data from the USB capture. It may not look perfect, but hopefully you will get something you recognize. Just thought about the same thing so I uploaded a video file: http://www.rainbow-software.org/linux_files/spca1528/sunp0003.avi Attached was Theodore's first attempt of such a procedure with a header extracted from a standalone image file from my Jeilin based camera and USB snoop data from the same camera. It wasn't perfect, but it was recognizable. I could not believe it! I already tried the image as JPEG, but I got just big colored pixels. I changed the 'samples Y' from 21 to 22 and I got something coherent! Here is the same image as yesterday with JPEG 411 header, compression quality 80% and insertion of 0x00 after 0xff. Very nice work! I think I understand the 'samples Y' change. According to ITU T.81, you changed the Vertical sampling factor in the Y component. So, I guess Luma is undersampled vertically for that mode of the camera (the camera only really has a 240 line sensor)? 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: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote: I2C-drivers can use the clientdata-pointer to point to private data. As I2C devices are not really unregistered, but merely detached from their driver, it used to be the drivers obligation to clear this pointer during remove() or a failed probe(). As a couple of drivers forgot to do this, it was agreed that it was cleaner if the i2c-core does this clearance when appropriate, as there is no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. This feature was added to the core with commit e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. As there is no need anymore to clear the clientdata-pointer, remove all current occurrences in the drivers to simplify the code and prevent confusion. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Acked-by: Mark Brown broo...@opensource.wolfsonmicro.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
dereferencing uninitialized variable in anysee_probe()
Hi I'm going through some smatch stuff and I had a question.
drivers/media/dvb/dvb-usb/anysee.c +482 anysee_probe(30)
warn: variable dereferenced before check 'd'
466 ret = dvb_usb_device_init(intf, anysee_properties,
THIS_MODULE, d,
467 adapter_nr);
If we're in a cold state then dvb_usb_device_init() can return
zero but d is uninitialized here.
468 if (ret)
469 return ret;
470
471 alt = usb_altnum_to_altsetting(intf, 0);
472 if (alt == NULL) {
473 deb_info(%s: no alt found!\n, __func__);
474 return -ENODEV;
475 }
476
477 ret = usb_set_interface(d-udev, alt-desc.bInterfaceNumber,
^^^
That would lead to an oops here.
478 alt-desc.bAlternateSetting);
I'm not sure how to fix this.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dereferencing uninitialized variable in anysee_probe()
Terve Dan,
On 05/31/2010 06:09 PM, Dan Carpenter wrote:
Hi I'm going through some smatch stuff and I had a question.
drivers/media/dvb/dvb-usb/anysee.c +482 anysee_probe(30)
warn: variable dereferenced before check 'd'
466 ret = dvb_usb_device_init(intf,anysee_properties,
THIS_MODULE,d,
467 adapter_nr);
If we're in a cold state then dvb_usb_device_init() can return
zero but d is uninitialized here.
Anysee is always warm. Its USB-bridge, Cypress FX2, uploads firmware
from eeprom and due to that it is never cold from the drivers point of view.
*cold means device needs firmware upload from driver
*warm means device is ready. Firmware is already uploaded or it is not
needed at all.
468 if (ret)
469 return ret;
470
471 alt = usb_altnum_to_altsetting(intf, 0);
472 if (alt == NULL) {
473 deb_info(%s: no alt found!\n, __func__);
474 return -ENODEV;
475 }
476
477 ret = usb_set_interface(d-udev, alt-desc.bInterfaceNumber,
^^^
That would lead to an oops here.
478 alt-desc.bAlternateSetting);
I'm not sure how to fix this.
After that answer, do you still see problem?
best regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tm6000: rewrite copy_streams
From: Stefan Ringel stefan.rin...@arcor.de
fusion function copy streams and copy_packets to new function copy_streams.
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-usb-isoc.h |5 +-
drivers/staging/tm6000/tm6000-video.c| 335 +++---
2 files changed, 122 insertions(+), 218 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-usb-isoc.h
b/drivers/staging/tm6000/tm6000-usb-isoc.h
index 5a5049a..138716a 100644
--- a/drivers/staging/tm6000/tm6000-usb-isoc.h
+++ b/drivers/staging/tm6000/tm6000-usb-isoc.h
@@ -39,7 +39,7 @@ struct usb_isoc_ctl {
int pos, size, pktsize;
/* Last field: ODD or EVEN? */
- int field;
+ int vfield;
/* Stores incomplete commands */
u32 tmp_buf;
@@ -47,7 +47,4 @@ struct usb_isoc_ctl {
/* Stores already requested buffers */
struct tm6000_buffer*buf;
-
- /* Stores the number of received fields */
- int nfields;
};
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index 2a61cc3..9746fe7 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -186,234 +186,145 @@ const char *tm6000_msg_type[] = {
/*
* Identify the tm5600/6000 buffer header type and properly handles
*/
-static int copy_packet(struct urb *urb, u32 header, u8 **ptr, u8 *endp,
- u8 *out_p, struct tm6000_buffer **buf)
-{
- struct tm6000_dmaqueue *dma_q = urb-context;
- struct tm6000_core *dev = container_of(dma_q, struct tm6000_core, vidq);
- u8 c;
- unsigned int cmd, cpysize, pktsize, size, field, block, line, pos = 0;
- int rc = 0;
- /* FIXME: move to tm6000-isoc */
- static int last_line = -2, start_line = -2, last_field = -2;
-
- /* FIXME: this is the hardcoded window size
-*/
- unsigned int linewidth = (*buf)-vb.width 1;
-
- if (!dev-isoc_ctl.cmd) {
- c = (header 24) 0xff;
-
- /* split the header fields */
- size = ((header 0x7e) 1);
-
- if (size 0)
- size -= 4;
-
- block = (header 7) 0xf;
- field = (header 11) 0x1;
- line = (header 12) 0x1ff;
- cmd = (header 21) 0x7;
-
- /* Validates header fields */
- if(size TM6000_URB_MSG_LEN)
- size = TM6000_URB_MSG_LEN;
-
- if (cmd == TM6000_URB_MSG_VIDEO) {
- if ((block+1)*TM6000_URB_MSG_LENlinewidth)
- cmd = TM6000_URB_MSG_ERR;
-
- /* FIXME: Mounts the image as field0+field1
-* It should, instead, check if the user selected
-* entrelaced or non-entrelaced mode
-*/
- pos= ((line1)+field)*linewidth +
- block*TM6000_URB_MSG_LEN;
-
- /* Don't allow to write out of the buffer */
- if (pos+TM6000_URB_MSG_LEN (*buf)-vb.size) {
- dprintk(dev, V4L2_DEBUG_ISOC,
- ERR: size=%d, num=%d, line=%d,
- field=%d\n,
- size, block, line, field);
-
- cmd = TM6000_URB_MSG_ERR;
- }
- } else {
- pos=0;
- }
-
- /* Prints debug info */
- dprintk(dev, V4L2_DEBUG_ISOC, size=%d, num=%d,
-line=%d, field=%d\n,
- size, block, line, field);
-
- if ((last_line!=line)(last_line+1!=line)
- (cmd != TM6000_URB_MSG_ERR) ) {
- if (cmd != TM6000_URB_MSG_VIDEO) {
- dprintk(dev, V4L2_DEBUG_ISOC, cmd=%d,
- size=%d, num=%d, line=%d, field=%d\n,
- cmd, size, block, line, field);
- }
- if (start_line0)
- start_line=last_line;
- /* Prints debug info */
- dprintk(dev, V4L2_DEBUG_ISOC, lines= %d-%d,
- field=%d\n,
- start_line, last_line, field);
-
- if ((start_line6 last_line200)
- (last_field != field) ) {
-
- dev-isoc_ctl.nfields++;
- if (dev-isoc_ctl.nfields=2) {
-
question about v4l2_subdev
Hi,
I am currently working on the atmel video driver, and I am facing a issue.
I have written a driver for the ov2640 omnivison sensor(enclosed). In
the ov2640 driver I am using the v4l2_subdev API. The point is I don't
how how can I access it in my video driver?
How to register the subdev struct in the atmel driver, so I could access
the s_ftm function for instance.
Regards,
Sedji
/*
* Omnivision ov2640 Camera driver
*
* Copyright (C) 2006 Atmel Corporation
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include linux/clk.h
#include linux/delay.h
#include linux/err.h
#include linux/i2c.h
#include linux/init.h
#include linux/kernel.h
#include linux/module.h
#include linux/slab.h
#include mach/gpio.h
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
#include media/v4l2-i2c-drv.h
#include media/atmel-isi.h
#include ov2640.h
static char mclk_name[32] = isi_clk;
module_param_string(mclk, mclk_name, sizeof(mclk_name), 0644);
MODULE_PARM_DESC(mclk, Name of the clock used as camera clock input);
MODULE_PARM_DESC(mclk, Name of mclk parent clock);
struct ov2640 {
struct v4l2_subdev sd;
struct mutexmutex;
u8 miscel_ctrl;
u16 pll_avr_ctrl;
struct clk *mclk;
struct i2c_client client;
struct atmel_isi_camera cam;
};
#define to_ov2640(cam) container_of(cam, struct ov2640, cam)
/*
* OV2640 register configuration for all combinations of pixel format and
* image size(for the moment only qvga YUV...)
*/
static struct ov2640_reg dump_list[] = {
{ OV2640_REG_TERM, OV2640_VAL_TERM }
};
/* YUV configs */
const static struct ov2640_reg qqcif_yuv[] = { };
const static struct ov2640_reg qqvga_yuv[] = { };
const static struct ov2640_reg sqcif_yuv[] = {
{ OV2640_REG_TERM, OV2640_VAL_TERM }
};
const static struct ov2640_reg qcif_yuv[] = {
{0xff, 0x01},{0x12, 0x80},{0xff, 0x00},{0x2c, 0xff},{0x2e, 0xdf},
{0xff, 0x01},{0x3c, 0x32},{0x11, 0x00},{0x09, 0x02},{0x04, 0x28},
{0x13, 0xe5},{0x14, 0x48},{0x2c, 0x0c},{0x33, 0x78},{0x3a, 0x33},
{0x3b, 0xfb},{0x3e, 0x00},{0x43, 0x11},{0x16, 0x10},{0x39, 0x02},
{0x35, 0x88},{0x22, 0x0a},{0x37, 0x40},{0x23, 0x00},{0x34, 0xa0},
{0x36, 0x1a},{0x06, 0x02},{0x07, 0xc0},{0x0d, 0xb7},{0x0e, 0x01},
{0x4c, 0x00},{0x4a, 0x81},{0x21, 0x99},{0x24, 0x3a},{0x25, 0x32},
{0x26, 0x82},{0x5c, 0x00},{0x63, 0x00},{0x5d, 0x55},{0x5e, 0x7d},
{0x5f, 0x7d},{0x60, 0x55},{0x61, 0x70},{0x62, 0x80},{0x7c, 0x05},
{0x20, 0x80},{0x28, 0x30},{0x6c, 0x00},{0x6d, 0x80},{0x6e, 0x00},
{0x70, 0x02},{0x71, 0x94},{0x73, 0xc1},{0x3d, 0x34},{0x5a, 0x57},
{0x4f, 0xbb},{0x50, 0x9c},{0xff, 0x00},{0xe5, 0x7f},{0xf9, 0xc0},
{0x41, 0x24},{0xe0, 0x14},{0x76, 0xff},{0x33, 0xa0},{0x42, 0x20},
{0x43, 0x18},{0x4c, 0x00},{0x87, 0xd0},{0x88, 0x3f},{0xd7, 0x03},
{0xd9, 0x10},{0xd3, 0x82},{0xc8, 0x08},{0xc9, 0x80},{0x7c, 0x00},
{0x7d, 0x02},{0x7c, 0x03},{0x7d, 0x48},{0x7d, 0x48},{0x7c, 0x08},
{0x7d, 0x20},{0x7d, 0x10},{0x7d, 0x0e},{0x90, 0x00},{0x91, 0x0e},
{0x91, 0x1a},{0x91, 0x31},{0x91, 0x5a},{0x91, 0x69},{0x91, 0x75},
{0x91, 0x7e},{0x91, 0x88},{0x91, 0x8f},{0x91, 0x96},{0x91, 0xa3},
{0x91, 0xaf},{0x91, 0xc4},{0x91, 0xd7},{0x91, 0xe8},{0x91, 0x20},
{0x92, 0x00},{0x93, 0x06},{0x93, 0xe3},{0x93, 0x05},{0x93, 0x05},
{0x93, 0x00},{0x93, 0x02},{0x93, 0x00},{0x93, 0x00},{0x93, 0x00},
{0x93, 0x00},{0x93, 0x00},{0x93, 0x00},{0x93, 0x00},{0x96, 0x00},
{0x97, 0x08},{0x97, 0x19},{0x97, 0x02},{0x97, 0x0c},{0x97, 0x24},
{0x97, 0x30},{0x97, 0x28},{0x97, 0x26},{0x97, 0x02},{0x97, 0x98},
{0x97, 0x80},{0x97, 0x00},{0x97, 0x00},{0xc3, 0xed},{0xa4, 0x00},
{0xa8, 0x00},{0xc5, 0x11},{0xc6, 0x51},{0xbf, 0x80},{0xc7, 0x10},
{0xb6, 0x66},{0xb8, 0xa5},{0xb7, 0x64},{0xb9, 0x7c},{0xb3, 0xaf},
{0xb4, 0x97},{0xb5, 0xff},{0xb0, 0xc5},{0xb1, 0x94},{0xb2, 0x0f},
{0xc4, 0x5c},{0xc0, 0xc8},{0xc1, 0x96},{0x86, 0x1d},{0x50, 0x00},
{0x51, 0x90},{0x52, 0x18},{0x53, 0x00},{0x54, 0x00},{0x55, 0x88},
{0x57, 0x00},{0x5a, 0x90},{0x5b, 0x18},{0x5c, 0x05},{0xc3, 0xed},
{0x7f, 0x00},{0xda, 0x04},{0xe5, 0x1f},{0xe1, 0x67},{0xe0, 0x00},
{0xdd, 0xff},{0x05, 0x00},{0xff, 0x01},{0x11, 0x01},
{0xff, 0x01},{0x12, 0x40},{0x17, 0x11},{0x18, 0x43},{0x19, 0x00},
{0x1a, 0x4b},{0x32, 0x09},{0x4f, 0xca},{0x50, 0xa8},{0x5a, 0x23},
{0x6d, 0x00},{0x3d, 0x38},
{0x39, 0x12},{0x35, 0xda},{0x22, 0x1a},{0x37, 0xc3},{0x23, 0x00},
{0x34, 0xc0},{0x36, 0x1a},{0x06, 0x88},{0x07, 0xc0},{0x0d, 0x87},
{0x0e, 0x41},{0x4c, 0x00},{0x48, 0x00},{0x5B, 0x00},{0x42, 0x03},
{0xff, 0x00},{0xe0, 0x04},{0xc0, 0x64},{0xc1, 0x4B},{0x8c, 0x00},
{0x86, 0x1D},{0xd3, 0x82},{0xe0, 0x00},
/* QCIF */
{0xff, 0x00},{0xc0, 0x64},{0xc1, 0x4B},{0x8c, 0x00},{0x86, 0x3D},
{0x50, 0x92},{0x51, 0xC8},{0x52, 0x96},{0x53, 0x00},{0x54, 0x00},
{0x55, 0x00},{0x5a, 0x2C},{0x5b, 0x24},{0x5c,
nxt200x: Timeout waiting for nxt2004 to init.
Just a quick question. I have an Kworld atsc 110 and 115. after 2 1/2 days I have 1624 dmesg Timeout waiting for nxt2004 to init lines. My understanding is once something in inititialize you shouldn't need to do it again. is the a reason it needs to init repeatedly? The cards are functioning fine with mythtv. Thanks Jonathan Sample with timing ---8-- [211844.717390] nxt200x: Timeout waiting for nxt2004 to init. [211864.496286] nxt200x: Timeout waiting for nxt2004 to init. [211890.602194] nxt200x: Timeout waiting for nxt2004 to init. [211904.394297] nxt200x: Timeout waiting for nxt2004 to init. [211924.747026] nxt200x: Timeout waiting for nxt2004 to init. [212302.550277] nxt200x: Timeout waiting for nxt2004 to init. [212314.356295] nxt200x: Timeout waiting for nxt2004 to init. [212335.245278] nxt200x: Timeout waiting for nxt2004 to init. [212351.161394] nxt200x: Timeout waiting for nxt2004 to init. [212365.098031] nxt200x: Timeout waiting for nxt2004 to init. [212399.819294] nxt200x: Timeout waiting for nxt2004 to init. [212435.198162] nxt200x: Timeout waiting for nxt2004 to init. [212442.446145] nxt200x: Timeout waiting for nxt2004 to init. [212446.674303] nxt200x: Timeout waiting for nxt2004 to init. [212460.008295] nxt200x: Timeout waiting for nxt2004 to init. [212461.655279] nxt200x: Timeout waiting for nxt2004 to init. [212465.454277] nxt200x: Timeout waiting for nxt2004 to init. [212498.875026] nxt200x: Timeout waiting for nxt2004 to init. [212514.791276] nxt200x: Timeout waiting for nxt2004 to init. [212520.409467] nxt200x: Timeout waiting for nxt2004 to init. [212533.584468] nxt200x: Timeout waiting for nxt2004 to init. [212537.880279] nxt200x: Timeout waiting for nxt2004 to init. [213510.585294] nxt200x: Timeout waiting for nxt2004 to init. [213526.196301] nxt200x: Timeout waiting for nxt2004 to init. [213549.076155] nxt200x: Timeout waiting for nxt2004 to init. [213553.143013] nxt200x: Timeout waiting for nxt2004 to init. [213561.282205] nxt200x: Timeout waiting for nxt2004 to init. [213612.284277] nxt200x: Timeout waiting for nxt2004 to init. [213617.087032] nxt200x: Timeout waiting for nxt2004 to init. [213624.669319] nxt200x: Timeout waiting for nxt2004 to init. [213626.324344] nxt200x: Timeout waiting for nxt2004 to init. [213720.884172] nxt200x: Timeout waiting for nxt2004 to init. [213731.081026] nxt200x: Timeout waiting for nxt2004 to init. [213754.500280] nxt200x: Timeout waiting for nxt2004 to init. [213761.917152] nxt200x: Timeout waiting for nxt2004 to init. [214210.566403] nxt200x: Timeout waiting for nxt2004 to init. [214218.086204] nxt200x: Timeout waiting for nxt2004 to init. [214226.801295] nxt200x: Timeout waiting for nxt2004 to init. [214227.838212] nxt200x: Timeout waiting for nxt2004 to init. [214247.973356] nxt200x: Timeout waiting for nxt2004 to init. [214250.661033] nxt200x: Timeout waiting for nxt2004 to init. [214271.082031] nxt200x: Timeout waiting for nxt2004 to init. [214273.469366] nxt200x: Timeout waiting for nxt2004 to init. [214281.378038] nxt200x: Timeout waiting for nxt2004 to init. [214363.528204] nxt200x: Timeout waiting for nxt2004 to init. [214375.779286] nxt200x: Timeout waiting for nxt2004 to init. [214410.896042] nxt200x: Timeout waiting for nxt2004 to init. [214450.769296] nxt200x: Timeout waiting for nxt2004 to init. [214454.652042] nxt200x: Timeout waiting for nxt2004 to init. [214457.722314] nxt200x: Timeout waiting for nxt2004 to init. [214518.751148] nxt200x: Timeout waiting for nxt2004 to init. [215357.898211] nxt200x: Timeout waiting for nxt2004 to init. [215364.899033] nxt200x: Timeout waiting for nxt2004 to init. [215370.457203] nxt200x: Timeout waiting for nxt2004 to init. [215386.914171] nxt200x: Timeout waiting for nxt2004 to init. [215392.677279] nxt200x: Timeout waiting for nxt2004 to init. [215410.894040] nxt200x: Timeout waiting for nxt2004 to init. [215420.185278] nxt200x: Timeout waiting for nxt2004 to init. [215449.908211] nxt200x: Timeout waiting for nxt2004 to init. [215464.256277] nxt200x: Timeout waiting for nxt2004 to init. [215479.878277] nxt200x: Timeout waiting for nxt2004 to init. [215496.286193] nxt200x: Timeout waiting for nxt2004 to init. [215503.028286] nxt200x: Timeout waiting for nxt2004 to init. [215514.881166] nxt200x: Timeout waiting for nxt2004 to init. [215543.269221] nxt200x: Timeout waiting for nxt2004 to init. [215561.433213] nxt200x: Timeout waiting for nxt2004 to init. [215596.010294] nxt200x: Timeout waiting for nxt2004 to init. [215641.442934] nxt200x: Timeout waiting for nxt2004 to init. [215642.540277] nxt200x: Timeout waiting for nxt2004 to init. [215643.524211] nxt200x: Timeout waiting for nxt2004 to init. [215650.046294] nxt200x: Timeout waiting for nxt2004 to init. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: fr-Nantes file outdated
2010/5/28 Charles landema...@gmail.com: Hello, I found out that frequencies listed here are outdated: http://linuxtv.org/hg/dvb-apps/file/7de0663facd9/util/scan/dvb-t/fr-Nantes What about these ones: http://linuxtv.org/hg/dvb-apps/file/tip/util/scan/dvb-t/fr-Nantes These are the new frequencies: 538167000 682167000 546167000 738167000 490167000 658167000 Sincerely, Charles. Christoph -- 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: fr-Nantes file outdated
French TV Arte keeps broadcasting announcements claiming that on June 6th, its multiplexer will change and to keep watching Arte, we'll have to rescan channels. Stay tuned! Charles. 2010/5/31 Christoph Pfister christophpfis...@gmail.com: 2010/5/28 Charles landema...@gmail.com: Hello, I found out that frequencies listed here are outdated: http://linuxtv.org/hg/dvb-apps/file/7de0663facd9/util/scan/dvb-t/fr-Nantes What about these ones: http://linuxtv.org/hg/dvb-apps/file/tip/util/scan/dvb-t/fr-Nantes These are the new frequencies: 538167000 682167000 546167000 738167000 490167000 658167000 Sincerely, Charles. Christoph -- 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: question about v4l2_subdev
On Mon, 2010-05-31 at 17:38 +0200, Sedji Gaouaou wrote: Hi, I am currently working on the atmel video driver, and I am facing a issue. I have written a driver for the ov2640 omnivison sensor(enclosed). In the ov2640 driver I am using the v4l2_subdev API. The point is I don't how how can I access it in my video driver? How to register the subdev struct in the atmel driver, so I could access the s_ftm function for instance. That depends. Is the atmel video driver instantiating a v4l_device for itself, or is it using some frame work that instantiates one for it? The details of using the v4l2 framework are in linux/Documentation/video4linux/v4l2-framework.txt but, typically 1. Something first should call v4l2_device_register() on a v4l2_device object. (Typically there is only one v4l2_device object per bridge chip between the PCI, PCIe, or USB bus and the subdevices, even if that bridge chip has more than one I2C master implementation.) 2. Then, for subdevices connected to the bridge chip via I2C, something needs to call v4l2_i2c_new_subdev() with the v4l2_device pointer as one of the arguments, to get back a v4l2_subdevice instance pointer. 3. After that, v4l2_subdev_call() with the v4l2_subdev pointer as one of the arguments can be used to invoke the subdevice methods. TV Video capture drivers do this work themselves. Drivers using a camera framework may have the framework doing some of the work for them. 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: ir-core multi-protocol decode and mceusb
Hi Andy, Em 31-05-2010 09:15, Andy Walls escreveu: I've now got an ir-lirc-codec bridge passing data over to a completely unmodified lirc_dev, with the data then making its way out to the lircd userspace where its even getting properly decoded. I don't have the transmit side of things in ir-lirc-codec wired up just yet, but I'd like to submit what I've got (after some cleanup) tomorrow, and will then incrementally work on transmit. I'm pretty sure wiring up transmit is going to require some of the bits we'd be using for native transmit as well, so there may be some discussion required. Will give a look at setting enabled/disabled decoders tomorrow too, hopefully. Since you're looking at Tx, please take a look at the v4l2_subdev interface for ir devices. See linux/include/media/v4l2-subdev.h: struct v4l2_subdev_ir_ops I was wondering how this interface could be modified to interface nicely to lirc (or I guess ir-lirc-codec) for transmit functionality. Right now, only the cx23885 driver uses it: linux/drivers/media/video/cx23885/cx23888-ir.[ch] I have the skeleton of transmit for the device implemented (it does need some fixing up). (The CX23888 hardware is nice in that it only deals with raw pulses so one can decode any protocol and transmit any protocols. The hardware provides hardware counter/timers for measuring incoming pulses and sending outgoing pulses.) This interface is bound to V4L needs. As the Remote Controller subsystem is meant to support not only V4L or DVB IR's, but also other kinds of remote controllers that aren't associated to media devices, it makes no sense on binding TX to this interface. The biggest advantage of V4L subdev interface is that a command, like VIDIOC_S_STD could be sent to several devices that may need to know what's the current standard, in order to configure audio, video, etc. It also provides a nice way to access devices on a device-internal bus. In the case of RC, I don't see any similar need. So, IMO, the better is to use an in interface similar to RX for TX, e. g., something like: rc_register_tx() rc_unregister_tx() rc_send_code() Of course, inside the V4L drivers, it may actually make sense to keep using the v4l2-subdev if the IR is accessed, for example, via I2C bus. 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
Re: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
Hi Wolfram, On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote: I2C-drivers can use the clientdata-pointer to point to private data. As I2C devices are not really unregistered, but merely detached from their driver, it used to be the drivers obligation to clear this pointer during remove() or a failed probe(). As a couple of drivers forgot to do this, it was agreed that it was cleaner if the i2c-core does this clearance when appropriate, as there is no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. This feature was added to the core with commit e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. As there is no need anymore to clear the clientdata-pointer, remove all current occurrences in the drivers to simplify the code and prevent confusion. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Jean Delvare kh...@linux-fr.org --- Some more notes: I waited for rc1 as I knew there were some drivers/patches coming along which needed to be processed, too. I'd suggest that this goes via the i2c-tree, so we get rid of all occurences at once. Frankly I'd prefer taking input stuff through my tree with the goal of .36 merge window just to minimize potential merge issues. This is a simple cleanup patch that has no dependencies, so there is little gain from doing it all in one go. Thanks. -- Dmitry -- 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:Mon May 31 19:00:28 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14875:304cfde05b3f git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: ERRORS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: ERRORS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-armv5-ixp: ERRORS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: ERRORS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: ERRORS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: ERRORS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: ERRORS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: ERRORS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: ERRORS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dereferencing uninitialized variable in anysee_probe()
On Mon, May 31, 2010 at 06:22:49PM +0300, Antti Palosaari wrote: Terve Dan, On 05/31/2010 06:09 PM, Dan Carpenter wrote: Hi I'm going through some smatch stuff and I had a question. drivers/media/dvb/dvb-usb/anysee.c +482 anysee_probe(30) warn: variable dereferenced before check 'd' 466 ret = dvb_usb_device_init(intf,anysee_properties, THIS_MODULE,d, 467 adapter_nr); If we're in a cold state then dvb_usb_device_init() can return zero but d is uninitialized here. Anysee is always warm. Its USB-bridge, Cypress FX2, uploads firmware from eeprom and due to that it is never cold from the drivers point of view. *cold means device needs firmware upload from driver *warm means device is ready. Firmware is already uploaded or it is not needed at all. Wow. Thanks for the quick response. I was just auditing the code and noticed some extra null checking which made me confused. I'll send a patch for that. regards, dan carpenter -- 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 1/3] Gspca-gl860 driver update
On Mon, 31 May 2010, Jean-Francois Moine wrote: On Mon, 31 May 2010 00:24:21 +0200 Olivier Lorin olori...@gmail.com wrote: - Change of rounded image resolutions to the real ones - Fix for an irrelevant OV9655 image resolution identifier name - Extra spaces to align some variable names and a defined value Hi Olivier, If I can anticipate, the changes are too different. You should split this patch. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 Congratulations. Nice. Theodore Kilgore
[patch] V4L/DVB: remove unneeded null check in anysee_probe()
Smatch complained because d is dereferenced first and then checked for
null later . The only code path where d could be a invalid pointer is
if this is a cold device in dvb_usb_device_init(). I consulted Antti
Palosaari and he explained that anysee is always a warm device.
I have added a comment and removed the unneeded null check.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/dvb/dvb-usb/anysee.c
b/drivers/media/dvb/dvb-usb/anysee.c
index faca1ad..aa5c7d5 100644
--- a/drivers/media/dvb/dvb-usb/anysee.c
+++ b/drivers/media/dvb/dvb-usb/anysee.c
@@ -463,6 +463,11 @@ static int anysee_probe(struct usb_interface *intf,
if (intf-num_altsetting 1)
return -ENODEV;
+ /*
+* Anysee is always warm (its USB-bridge, Cypress FX2, uploads
+* firmware from eeprom). If dvb_usb_device_init() succeeds that
+* means d is a valid pointer.
+*/
ret = dvb_usb_device_init(intf, anysee_properties, THIS_MODULE, d,
adapter_nr);
if (ret)
@@ -479,10 +484,7 @@ static int anysee_probe(struct usb_interface *intf,
if (ret)
return ret;
- if (d)
- ret = anysee_init(d);
-
- return ret;
+ return anysee_init(d);
}
static struct usb_device_id anysee_table[] = {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.35-rc1 fails to boot: OOPS in ir_register_class
On Mon, 2010-05-31 at 07:25 +0200, Torsten Kaiser wrote: Trying to boot the new -rc1 it fails with the following OOPS: [3.454804] IR NEC protocol handler initialized [3.461310] IR RC5(x) protocol handler initialized [3.467865] IR RC6 protocol handler initialized [3.474070] IR JVC protocol handler initialized [3.480257] IR Sony protocol handler initialized [3.480259] Linux video capture interface: v2.00 [3.480722] bttv: driver version 0.9.18 loaded [3.480724] bttv: using 8 buffers with 2080k (520 pages) each for capture [3.507950] bttv: Bt8xx card found (0). [3.513845] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 19 [3.521339] bttv :05:06.0: PCI INT A - Link[LNKC] - GSI 19 (level, low) - IRQ 19 [3.531039] bttv0: Bt878 (rev 17) at :05:06.0, irq: 19, latency: 64, mmio: 0xeefff000 [3.541062] bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb [3.550946] bttv0: using: Hauppauge (bt878) [card=10,autodetected] [3.561433] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] [3.593765] usb 2-6: new low speed USB device using ohci_hcd and address 2 [3.599016] tveeprom 4-0050: Hauppauge model 61344, rev D421, serial# 3902813 [3.599018] tveeprom 4-0050: tuner model is Philips FM1216 (idx 21, type 5) [3.599021] tveeprom 4-0050: TV standards PAL(B/G) (eeprom 0x04) [3.599022] tveeprom 4-0050: audio processor is MSP3415 (idx 6) [3.599024] tveeprom 4-0050: has radio [3.599025] bttv0: Hauppauge eeprom indicates model#61344 [3.599027] bttv0: tuner type=5 [3.609618] msp3400 4-0040: MSP3415D-B3 found @ 0x80 (bt878 #0 [sw]) [3.609620] msp3400 4-0040: msp3400 supports nicam, mode is autodetect [3.621863] tuner 4-0061: chip found @ 0xc2 (bt878 #0 [sw]) [3.622168] tuner-simple 4-0061: creating new instance [3.622170] tuner-simple 4-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) [3.622882] bttv0: registered device video0 [3.622940] bttv0: registered device vbi0 [3.622997] bttv0: registered device radio0 [3.632337] bttv0: PLL: 28636363 = 35468950 .. ok [3.683096] Registered IR keymap rc-rc5-tv [3.683110] BUG: unable to handle kernel NULL pointer dereference at (null) [3.683113] IP: [813ebe79] ir_register_class+0x59/0x160 [3.683122] PGD 0 [3.683124] Oops: [#1] SMP [3.683125] last sysfs file: [3.683127] CPU 2 [3.683129] Modules linked in: [3.683130] [3.683133] Pid: 1, comm: swapper Not tainted 2.6.35-rc1 #1 KFN5-D SLI/KFN5-D SLI [3.683135] RIP: 0010:[813ebe79] [813ebe79] ir_register_class+0x59/0x160 [3.683139] RSP: 0018:88011ff09cd0 EFLAGS: 00010246 [3.683141] RAX: RBX: 88011f3c1a00 RCX: 81a5baa0 [3.683142] RDX: RSI: 817d24f0 RDI: 88011f3c1a00 [3.683144] RBP: R08: R09: [3.683146] R10: R11: 0021 R12: 817d6960 [3.683147] R13: 88011f223000 R14: 88011f3c1a00 R15: 88011f3c1b40 [3.683150] FS: 010f8870() GS:88008020() knlGS: [3.683151] CS: 0010 DS: ES: CR0: 8005003b [3.683153] CR2: CR3: 01a05000 CR4: 06e0 [3.683155] DR0: DR1: DR2: [3.683157] DR3: DR6: 0ff0 DR7: 0400 [3.683159] Process swapper (pid: 1, threadinfo 88011ff08000, task 88007ff48000) [3.683160] Stack: [3.683162] 88011f223000 81a5ab30 88011f223000 817d6960 [3.683164] 0 0021 813eb90a 88010028 817d240e [3.683166] 0 88011f3c1b68 0282 8800070b54e0 88011f35f100 [3.683169] Call Trace: [3.683174] [813eb90a] ? __ir_input_register+0x2ba/0x350 [3.683178] [8141730a] ? ir_probe+0x36a/0x4f0 [3.683181] [81416fa0] ? ir_probe+0x0/0x4f0 [3.683185] [813d9bca] ? i2c_device_probe+0xea/0x120 [3.683188] [813367aa] ? driver_sysfs_add+0x5a/0x80 [3.683190] [813368d3] ? driver_probe_device+0x83/0x190 [3.683193] [813d9c54] ? i2c_device_match+0x54/0x70 [3.683195] [81336d03] ? __driver_attach+0x93/0xa0 [3.683197] [81336c70] ? __driver_attach+0x0/0xa0 [3.683201] [81335bf8] ? bus_for_each_dev+0x58/0x80 [3.683203] [81335ea0] ? bus_add_driver+0xb0/0x250 [3.683206] [81336e4a] ? driver_register+0x6a/0x130 [3.683209] [812124a0] ? __pci_register_driver+0x80/0xc0 [3.683212] [813daa30] ? i2c_register_driver+0x30/0xb0 [3.683217] [81ae990d] ? bttv_init_module+0x0/0xde [
Re: ir-core multi-protocol decode and mceusb
On Mon, 2010-05-31 at 16:06 -0300, Mauro Carvalho Chehab wrote: Hi Andy, Em 31-05-2010 09:15, Andy Walls escreveu: I've now got an ir-lirc-codec bridge passing data over to a completely unmodified lirc_dev, with the data then making its way out to the lircd userspace where its even getting properly decoded. I don't have the transmit side of things in ir-lirc-codec wired up just yet, but I'd like to submit what I've got (after some cleanup) tomorrow, and will then incrementally work on transmit. I'm pretty sure wiring up transmit is going to require some of the bits we'd be using for native transmit as well, so there may be some discussion required. Will give a look at setting enabled/disabled decoders tomorrow too, hopefully. Since you're looking at Tx, please take a look at the v4l2_subdev interface for ir devices. See linux/include/media/v4l2-subdev.h: struct v4l2_subdev_ir_ops I was wondering how this interface could be modified to interface nicely to lirc (or I guess ir-lirc-codec) for transmit functionality. Right now, only the cx23885 driver uses it: linux/drivers/media/video/cx23885/cx23888-ir.[ch] I have the skeleton of transmit for the device implemented (it does need some fixing up). (The CX23888 hardware is nice in that it only deals with raw pulses so one can decode any protocol and transmit any protocols. The hardware provides hardware counter/timers for measuring incoming pulses and sending outgoing pulses.) This interface is bound to V4L needs. As the Remote Controller subsystem is meant to support not only V4L or DVB IR's, but also other kinds of remote controllers that aren't associated to media devices, it makes no sense on binding TX to this interface. The biggest advantage of V4L subdev interface is that a command, like VIDIOC_S_STD could be sent to several devices that may need to know what's the current standard, in order to configure audio, video, etc. It also provides a nice way to access devices on a device-internal bus. In the case of RC, I don't see any similar need. So, IMO, the better is to use an in interface similar to RX for TX, e. g., something like: rc_register_tx() rc_unregister_tx() rc_send_code() Right, I agree. The v4l2_subdev ir_ops is a detail hidden by the bridge driver and the bridge driver needs to deal with that. A registration process seems to be the proper way to do things. BTW, maybe rc_set_tx_parameters() is needed as well to set up the parameters for the transmitter. I haven't looked very hard at rc_register_rx() and related functions so I will soon. 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
Kaffeine 1.0 released
See the announcement at http://kaffeine.kde.org/?q=node/27 Christoph -- 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
Soc-camera and 2.6.33
I tried to upgrade from 2.6.30 to 2.6.33 and verify my board (ie. the mt9m111 sensor with pxa_camera host). I'm a bit surprised it didn't work. I dig just a bit, and found that : - in soc_camera_init_i2c(), the following call fails subdev = v4l2_i2c_new_subdev_board(ici-v4l2_dev, adap, icl-module_name, icl-board_info, NULL); I have subdev = NULL. - as a result, I'm getting that kind of log : camera 0-0: Probing 0-0 pxa27x-camera pxa27x-camera.0: Registered platform device at c3010900 data c03f0c24 pxa27x-camera pxa27x-camera.0: PXA Camera driver attached to camera 0 RJK: subdev=NULL, module=mt9m111 pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from camera 0 camera: probe of 0-0 failed with error -12 - if I try 2.6.34, I have no error report, and mt9m111 driver is not probed either. Is there an explanation as to why I have this regression ? Is something to be done with the v4l2 migration ? Cheers. -- Robert -- 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] drivers: remove all i2c_set_clientdata(client, NULL)
Hi Dmitry, On Mon, 31 May 2010 12:09:12 -0700, Dmitry Torokhov wrote: Frankly I'd prefer taking input stuff through my tree with the goal of .36 merge window just to minimize potential merge issues. This is a simple cleanup patch that has no dependencies, so there is little gain from doing it all in one go. If I take the patch in my i2c tree, the aim is to merge it upstream immediately, so merge issues won't exist. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-core multi-protocol decode and mceusb
Em 31-05-2010 16:38, Andy Walls escreveu:
On Mon, 2010-05-31 at 16:06 -0300, Mauro Carvalho Chehab wrote:
Hi Andy,
Em 31-05-2010 09:15, Andy Walls escreveu:
I've now got an ir-lirc-codec bridge passing data over to a completely
unmodified lirc_dev, with the data then making its way out to the
lircd userspace where its even getting properly decoded. I don't have
the transmit side of things in ir-lirc-codec wired up just yet, but
I'd like to submit what I've got (after some cleanup) tomorrow, and
will then incrementally work on transmit. I'm pretty sure wiring up
transmit is going to require some of the bits we'd be using for native
transmit as well, so there may be some discussion required. Will give
a look at setting enabled/disabled decoders tomorrow too, hopefully.
Since you're looking at Tx, please take a look at the v4l2_subdev
interface for ir devices. See
linux/include/media/v4l2-subdev.h: struct v4l2_subdev_ir_ops
I was wondering how this interface could be modified to interface nicely
to lirc (or I guess ir-lirc-codec) for transmit functionality.
Right now, only the cx23885 driver uses it:
linux/drivers/media/video/cx23885/cx23888-ir.[ch]
I have the skeleton of transmit for the device implemented (it does need
some fixing up).
(The CX23888 hardware is nice in that it only deals with raw pulses so
one can decode any protocol and transmit any protocols. The hardware
provides hardware counter/timers for measuring incoming pulses and
sending outgoing pulses.)
This interface is bound to V4L needs. As the Remote Controller subsystem
is meant to support not only V4L or DVB IR's, but also other kinds of remote
controllers that aren't associated to media devices, it makes no sense on
binding TX to this interface.
The biggest advantage of V4L subdev interface is that a command, like
VIDIOC_S_STD
could be sent to several devices that may need to know what's the current
standard,
in order to configure audio, video, etc. It also provides a nice way to
access
devices on a device-internal bus. In the case of RC, I don't see any similar
need. So, IMO, the better is to use an in interface similar to RX for TX, e.
g.,
something like:
rc_register_tx()
rc_unregister_tx()
rc_send_code()
Right, I agree. The v4l2_subdev ir_ops is a detail hidden by the bridge
driver and the bridge driver needs to deal with that. A registration
process seems to be the proper way to do things.
BTW, maybe
rc_set_tx_parameters()
is needed as well to set up the parameters for the transmitter.
I haven't looked very hard at rc_register_rx() and related functions so
I will soon.
They are declared at include/media/ir-core.h. The actual name is
ir_input_register().
The RX parameters are configured at the IR structs, before calling the function.
I may be wrong (since we didn't write any TX support), but I think that a
rc_set_tx_parameters() wouldn't be necessary, as I don't see why the driver will
change the parameters after registering, and without any userspace request.
If we consider that some userspace sysfs nodes will allow changing some
parameters,
then the better is to have a callback function call, passed via the registering
function,
that will allow calling a function inside the driver to change the TX
parameters.
For example, something like:
struct rc_tx_props {
...
int (*change_protocol)(...);
...
};
rc_register_tx(..., struct rc_tx_props *props)
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
Re: 2.6.35-rc1 fails to boot: OOPS in ir_register_class
Em 31-05-2010 16:31, Andy Walls escreveu: On Mon, 2010-05-31 at 07:25 +0200, Torsten Kaiser wrote: Trying to boot the new -rc1 it fails with the following OOPS: [3.454804] IR NEC protocol handler initialized [3.461310] IR RC5(x) protocol handler initialized [3.467865] IR RC6 protocol handler initialized [3.474070] IR JVC protocol handler initialized [3.480257] IR Sony protocol handler initialized [3.480259] Linux video capture interface: v2.00 [3.480722] bttv: driver version 0.9.18 loaded [3.480724] bttv: using 8 buffers with 2080k (520 pages) each for capture [3.507950] bttv: Bt8xx card found (0). [3.513845] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 19 [3.521339] bttv :05:06.0: PCI INT A - Link[LNKC] - GSI 19 (level, low) - IRQ 19 [3.531039] bttv0: Bt878 (rev 17) at :05:06.0, irq: 19, latency: 64, mmio: 0xeefff000 [3.541062] bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb [3.550946] bttv0: using: Hauppauge (bt878) [card=10,autodetected] [3.561433] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] [3.593765] usb 2-6: new low speed USB device using ohci_hcd and address 2 [3.599016] tveeprom 4-0050: Hauppauge model 61344, rev D421, serial# 3902813 [3.599018] tveeprom 4-0050: tuner model is Philips FM1216 (idx 21, type 5) [3.599021] tveeprom 4-0050: TV standards PAL(B/G) (eeprom 0x04) [3.599022] tveeprom 4-0050: audio processor is MSP3415 (idx 6) [3.599024] tveeprom 4-0050: has radio [3.599025] bttv0: Hauppauge eeprom indicates model#61344 [3.599027] bttv0: tuner type=5 [3.609618] msp3400 4-0040: MSP3415D-B3 found @ 0x80 (bt878 #0 [sw]) [3.609620] msp3400 4-0040: msp3400 supports nicam, mode is autodetect [3.621863] tuner 4-0061: chip found @ 0xc2 (bt878 #0 [sw]) [3.622168] tuner-simple 4-0061: creating new instance [3.622170] tuner-simple 4-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) [3.622882] bttv0: registered device video0 [3.622940] bttv0: registered device vbi0 [3.622997] bttv0: registered device radio0 [3.632337] bttv0: PLL: 28636363 = 35468950 .. ok [3.683096] Registered IR keymap rc-rc5-tv [3.683110] BUG: unable to handle kernel NULL pointer dereference at (null) [3.683113] IP: [813ebe79] ir_register_class+0x59/0x160 [3.683122] PGD 0 [3.683124] Oops: [#1] SMP [3.683125] last sysfs file: [3.683127] CPU 2 [3.683129] Modules linked in: [3.683130] [3.683133] Pid: 1, comm: swapper Not tainted 2.6.35-rc1 #1 KFN5-D SLI/KFN5-D SLI [3.683135] RIP: 0010:[813ebe79] [813ebe79] ir_register_class+0x59/0x160 [3.683139] RSP: 0018:88011ff09cd0 EFLAGS: 00010246 [3.683141] RAX: RBX: 88011f3c1a00 RCX: 81a5baa0 [3.683142] RDX: RSI: 817d24f0 RDI: 88011f3c1a00 [3.683144] RBP: R08: R09: [3.683146] R10: R11: 0021 R12: 817d6960 [3.683147] R13: 88011f223000 R14: 88011f3c1a00 R15: 88011f3c1b40 [3.683150] FS: 010f8870() GS:88008020() knlGS: [3.683151] CS: 0010 DS: ES: CR0: 8005003b [3.683153] CR2: CR3: 01a05000 CR4: 06e0 [3.683155] DR0: DR1: DR2: [3.683157] DR3: DR6: 0ff0 DR7: 0400 [3.683159] Process swapper (pid: 1, threadinfo 88011ff08000, task 88007ff48000) [3.683160] Stack: [3.683162] 88011f223000 81a5ab30 88011f223000 817d6960 [3.683164] 0 0021 813eb90a 88010028 817d240e [3.683166] 0 88011f3c1b68 0282 8800070b54e0 88011f35f100 [3.683169] Call Trace: [3.683174] [813eb90a] ? __ir_input_register+0x2ba/0x350 [3.683178] [8141730a] ? ir_probe+0x36a/0x4f0 [3.683181] [81416fa0] ? ir_probe+0x0/0x4f0 [3.683185] [813d9bca] ? i2c_device_probe+0xea/0x120 [3.683188] [813367aa] ? driver_sysfs_add+0x5a/0x80 [3.683190] [813368d3] ? driver_probe_device+0x83/0x190 [3.683193] [813d9c54] ? i2c_device_match+0x54/0x70 [3.683195] [81336d03] ? __driver_attach+0x93/0xa0 [3.683197] [81336c70] ? __driver_attach+0x0/0xa0 [3.683201] [81335bf8] ? bus_for_each_dev+0x58/0x80 [3.683203] [81335ea0] ? bus_add_driver+0xb0/0x250 [3.683206] [81336e4a] ? driver_register+0x6a/0x130 [3.683209] [812124a0] ? __pci_register_driver+0x80/0xc0 [3.683212] [813daa30] ? i2c_register_driver+0x30/0xb0 [3.683217]
Re: ir-core multi-protocol decode and mceusb
On Mon, 2010-05-31 at 17:58 -0300, Mauro Carvalho Chehab wrote:
Em 31-05-2010 16:38, Andy Walls escreveu:
On Mon, 2010-05-31 at 16:06 -0300, Mauro Carvalho Chehab wrote:
Hi Andy,
Em 31-05-2010 09:15, Andy Walls escreveu:
I've now got an ir-lirc-codec bridge passing data over to a completely
unmodified lirc_dev, with the data then making its way out to the
lircd userspace where its even getting properly decoded. I don't have
the transmit side of things in ir-lirc-codec wired up just yet, but
I'd like to submit what I've got (after some cleanup) tomorrow, and
will then incrementally work on transmit. I'm pretty sure wiring up
transmit is going to require some of the bits we'd be using for native
transmit as well, so there may be some discussion required. Will give
a look at setting enabled/disabled decoders tomorrow too, hopefully.
Since you're looking at Tx, please take a look at the v4l2_subdev
interface for ir devices. See
linux/include/media/v4l2-subdev.h: struct v4l2_subdev_ir_ops
I was wondering how this interface could be modified to interface nicely
to lirc (or I guess ir-lirc-codec) for transmit functionality.
Right now, only the cx23885 driver uses it:
linux/drivers/media/video/cx23885/cx23888-ir.[ch]
I have the skeleton of transmit for the device implemented (it does need
some fixing up).
(The CX23888 hardware is nice in that it only deals with raw pulses so
one can decode any protocol and transmit any protocols. The hardware
provides hardware counter/timers for measuring incoming pulses and
sending outgoing pulses.)
This interface is bound to V4L needs. As the Remote Controller subsystem
is meant to support not only V4L or DVB IR's, but also other kinds of
remote
controllers that aren't associated to media devices, it makes no sense on
binding TX to this interface.
The biggest advantage of V4L subdev interface is that a command, like
VIDIOC_S_STD
could be sent to several devices that may need to know what's the current
standard,
in order to configure audio, video, etc. It also provides a nice way to
access
devices on a device-internal bus. In the case of RC, I don't see any
similar
need. So, IMO, the better is to use an in interface similar to RX for TX,
e. g.,
something like:
rc_register_tx()
rc_unregister_tx()
rc_send_code()
Right, I agree. The v4l2_subdev ir_ops is a detail hidden by the bridge
driver and the bridge driver needs to deal with that. A registration
process seems to be the proper way to do things.
BTW, maybe
rc_set_tx_parameters()
is needed as well to set up the parameters for the transmitter.
I haven't looked very hard at rc_register_rx() and related functions so
I will soon.
They are declared at include/media/ir-core.h. The actual name is
ir_input_register().
The RX parameters are configured at the IR structs, before calling the
function.
I may be wrong (since we didn't write any TX support), but I think that a
rc_set_tx_parameters() wouldn't be necessary, as I don't see why the driver
will
change the parameters after registering, and without any userspace request.
Yes, my intent was to handle a user space request to change the
transmitter setup parameters to handle the protocol.
I also don't want to worry about having to code in kernel parameter
tables for any bizzare protocol userspace may know about.
If we consider that some userspace sysfs nodes will allow changing some
parameters,
then the better is to have a callback function call, passed via the
registering function,
that will allow calling a function inside the driver to change the TX
parameters.
For example, something like:
struct rc_tx_props {
...
int (*change_protocol)(...);
...
};
rc_register_tx(..., struct rc_tx_props *props)
A callback is likely needed. I'm not sure I would have chosen the name
change_protocol(), because transmitter parameters can be common between
protocols (at least RC-5 and RC-6 can be supported with one set of
parameters), or not match any existing in-kernel protocol. As long as
it is flexible enough to change individual transmitter parameters
(modulated/baseband, carrier freq, duty cycle, etc.) it will be fine.
Currently LIRC userspace changes Tx parameters using an ioctl(). It
asks the hardware to change transmitter parameters, because the current
model is that the transmitters don't need to know about protocols. (LIRC
userspace knows the parameters of the protocol it wants to use, so the
driver's don't have too).
I notice IR Rx also has a change_protocol() callback that is not
currently in use. If sending raw pulses to userspace, it would be also
nice to expose that callback so userspace could set the receiver
parameters.
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
Re: Soc-camera and 2.6.33
Hi Robert On Mon, 31 May 2010, Robert Jarzmik wrote: I tried to upgrade from 2.6.30 to 2.6.33 and verify my board (ie. the mt9m111 sensor with pxa_camera host). I'm a bit surprised it didn't work. I dig just a bit, and found that : - in soc_camera_init_i2c(), the following call fails subdev = v4l2_i2c_new_subdev_board(ici-v4l2_dev, adap, icl-module_name, icl-board_info, NULL); I have subdev = NULL. - as a result, I'm getting that kind of log : camera 0-0: Probing 0-0 pxa27x-camera pxa27x-camera.0: Registered platform device at c3010900 data c03f0c24 pxa27x-camera pxa27x-camera.0: PXA Camera driver attached to camera 0 RJK: subdev=NULL, module=mt9m111 pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from camera 0 camera: probe of 0-0 failed with error -12 a lot of things changed in and around soc-camera between 2.6.30 and .33... E.g., previously you could load driver modules in any order, it would work in any case. Now if you load your host driver (pxa) and your client driver is not there yet, it should be automatically loaded. However, if your user-space doesn't support this, it won't work. Can this be the reason gor your problem? Otherwise, I'd suspect a problem with your platform data (cf. other platforms), or, eventually with mt9m111. - if I try 2.6.34, I have no error report, and mt9m111 driver is not probed either. Is there an explanation as to why I have this regression ? Is something to be done with the v4l2 migration ? 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: [PATCH] tm6000: rewrite copy_streams
Em 31-05-2010 12:25, stefan.rin...@arcor.de escreveu:
From: Stefan Ringel stefan.rin...@arcor.de
fusion function copy streams and copy_packets to new function copy_streams.
There's something wrong with this patch:
$ patch -p1 -i /tmp/tm6000\:\ rewrite\ copy_streams.eml -l
(Stripping trailing CRs from patch.)
patching file drivers/staging/tm6000/tm6000-usb-isoc.h
(Stripping trailing CRs from patch.)
patching file drivers/staging/tm6000/tm6000-video.c
Hunk #1 FAILED at 186.
Hunk #2 FAILED at 439.
Hunk #3 FAILED at 451.
3 out of 6 hunks FAILED -- saving rejects to file
drivers/staging/tm6000/tm6000-video.c.rej
Please rebase it against git branch devel/for_v2.6.35 of my v4l-dvb.git tree.
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-usb-isoc.h |5 +-
drivers/staging/tm6000/tm6000-video.c| 335
+++---
2 files changed, 122 insertions(+), 218 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-usb-isoc.h
b/drivers/staging/tm6000/tm6000-usb-isoc.h
index 5a5049a..138716a 100644
--- a/drivers/staging/tm6000/tm6000-usb-isoc.h
+++ b/drivers/staging/tm6000/tm6000-usb-isoc.h
@@ -39,7 +39,7 @@ struct usb_isoc_ctl {
int pos, size, pktsize;
/* Last field: ODD or EVEN? */
- int field;
+ int vfield;
/* Stores incomplete commands */
u32 tmp_buf;
@@ -47,7 +47,4 @@ struct usb_isoc_ctl {
/* Stores already requested buffers */
struct tm6000_buffer*buf;
-
- /* Stores the number of received fields */
- int nfields;
};
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index 2a61cc3..9746fe7 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -186,234 +186,145 @@ const char *tm6000_msg_type[] = {
/*
* Identify the tm5600/6000 buffer header type and properly handles
*/
-static int copy_packet(struct urb *urb, u32 header, u8 **ptr, u8 *endp,
- u8 *out_p, struct tm6000_buffer **buf)
-{
- struct tm6000_dmaqueue *dma_q = urb-context;
- struct tm6000_core *dev = container_of(dma_q, struct tm6000_core, vidq);
- u8 c;
- unsigned int cmd, cpysize, pktsize, size, field, block, line, pos = 0;
- int rc = 0;
- /* FIXME: move to tm6000-isoc */
- static int last_line = -2, start_line = -2, last_field = -2;
-
- /* FIXME: this is the hardcoded window size
- */
- unsigned int linewidth = (*buf)-vb.width 1;
-
- if (!dev-isoc_ctl.cmd) {
- c = (header 24) 0xff;
-
- /* split the header fields */
- size = ((header 0x7e) 1);
-
- if (size 0)
- size -= 4;
-
- block = (header 7) 0xf;
- field = (header 11) 0x1;
- line = (header 12) 0x1ff;
- cmd = (header 21) 0x7;
-
- /* Validates header fields */
- if(size TM6000_URB_MSG_LEN)
- size = TM6000_URB_MSG_LEN;
-
- if (cmd == TM6000_URB_MSG_VIDEO) {
- if ((block+1)*TM6000_URB_MSG_LENlinewidth)
- cmd = TM6000_URB_MSG_ERR;
-
- /* FIXME: Mounts the image as field0+field1
- * It should, instead, check if the user selected
- * entrelaced or non-entrelaced mode
- */
- pos= ((line1)+field)*linewidth +
- block*TM6000_URB_MSG_LEN;
-
- /* Don't allow to write out of the buffer */
- if (pos+TM6000_URB_MSG_LEN (*buf)-vb.size) {
- dprintk(dev, V4L2_DEBUG_ISOC,
- ERR: size=%d, num=%d, line=%d,
- field=%d\n,
- size, block, line, field);
-
- cmd = TM6000_URB_MSG_ERR;
- }
- } else {
- pos=0;
- }
-
- /* Prints debug info */
- dprintk(dev, V4L2_DEBUG_ISOC, size=%d, num=%d,
- line=%d, field=%d\n,
- size, block, line, field);
-
- if ((last_line!=line)(last_line+1!=line)
- (cmd != TM6000_URB_MSG_ERR) ) {
- if (cmd != TM6000_URB_MSG_VIDEO) {
- dprintk(dev, V4L2_DEBUG_ISOC, cmd=%d,
- size=%d, num=%d, line=%d, field=%d\n,
- cmd, size, block, line, field);
- }
-
tm6000 audio urb
Hi, I'm having my first adventures on driver coding, trying to help audio development of tm6000 based on Mauro's hints. According to Mauro and coding comments, the audio URBs are already being received by tm6000-video. The copy_packet function correctly filters video packets (identified as cmd=1, extracted from header) and the tm6000_msg_type array suggests that the cmd=2 would be the audio packets. I logged all packets not being copied to video buffer and realized that the only packets remaining have been identified as cmd=4, which is supposedly type pts. For me it looks like either the cmd=4 type is audio, or the audio is not really being received. Does this make sense? Luis -- 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: Soc-camera and 2.6.33
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Hi Robert a lot of things changed in and around soc-camera between 2.6.30 and .33... E.g., previously you could load driver modules in any order, it would work in any case. Now if you load your host driver (pxa) and your client driver is not there yet, it should be automatically loaded. However, if your user-space doesn't support this, it won't work. Can this be the reason gor your problem? Otherwise, I'd suspect a problem with your platform data (cf. other platforms), or, eventually with mt9m111. I have a very tiny system : - udev - a shell (/bin/ash) - a libc - busybox (insmod/modprobe/rmmod/ls) - capture_example compiled as my testbed I do : - insmod mt9m111.ko - insmod pxa_camera.ko My userspace hasn't changed since 2.6.30 (constant executables, ARM-EABI). My platform was converted by you in commit a48c24a696f0d93c49f913b7818e9819612b1f4e if I remember correctly. Any hint for me to track down my problem ? Cheers. -- Robert -- 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: ir-core multi-protocol decode and mceusb
Em 31-05-2010 18:45, Andy Walls escreveu:
On Mon, 2010-05-31 at 17:58 -0300, Mauro Carvalho Chehab wrote:
I may be wrong (since we didn't write any TX support), but I think that a
rc_set_tx_parameters() wouldn't be necessary, as I don't see why the driver
will
change the parameters after registering, and without any userspace request.
Yes, my intent was to handle a user space request to change the
transmitter setup parameters to handle the protocol.
I also don't want to worry about having to code in kernel parameter
tables for any bizzare protocol userspace may know about.
Makes sense.
If we consider that some userspace sysfs nodes will allow changing some
parameters,
then the better is to have a callback function call, passed via the
registering function,
that will allow calling a function inside the driver to change the TX
parameters.
For example, something like:
struct rc_tx_props {
...
int (*change_protocol)(...);
...
};
rc_register_tx(..., struct rc_tx_props *props)
A callback is likely needed. I'm not sure I would have chosen the name
change_protocol(), because transmitter parameters can be common between
protocols (at least RC-5 and RC-6 can be supported with one set of
parameters), or not match any existing in-kernel protocol. As long as
it is flexible enough to change individual transmitter parameters
(modulated/baseband, carrier freq, duty cycle, etc.) it will be fine.
I just used this name as an example, as the same name exists on RX.
Depending on how we code the userspace API, we may use just one set_parameters
function, or a set of per-attribute changes.
In other words, if we implement severa sysfs nodes to change several parameters,
maybe it makes sense to have several callbacks. Another alternative would be
to have a commit sysfs node to apply a set of parameters at once.
Currently LIRC userspace changes Tx parameters using an ioctl(). It
asks the hardware to change transmitter parameters, because the current
model is that the transmitters don't need to know about protocols. (LIRC
userspace knows the parameters of the protocol it wants to use, so the
driver's don't have too).
I notice IR Rx also has a change_protocol() callback that is not
currently in use.
It is used only by em28xx, where the hardware decoder can work either with
RC-5 or NEC (newer chips also support RC-6, but this is currently not
implemented).
If sending raw pulses to userspace, it would be also
nice to expose that callback so userspace could set the receiver
parameters.
Raw pulse transmission is probably the easiest case. Probably, there's nothing
or a very few things that might need adjustments.
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
--
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: 2.6.34-rc7 kernel panics BUG: unable to handle kernel NULL pointer dereference at (null) while channel scan running
On Sun, 2010-05-30 at 12:33 +0200, Silamael wrote:
Hi there,
When i try to scan for available DBV-S channels kernel panics:
BUG: unable to handle kernel NULL pointer dereference at (null)
I'm trying to setup a TV box. Contains an Intel Atom N270 CPU, 2GB RAM,
1 TB SATA Hard-Drive. Mainboard is a MSI IM-945GSE Mini-ITX motherboard.
The DVB-S card is a WinTV Nexus-S Rev 2.3 card.
Kernel is a custom built kernel:
Linux version 2.6.34-rc7 (r...@filmdose) (gcc version 4.4.4 (Debian
4.4.4-1) ) #7 SMP Fri May 21 18:06:19 CEST 2010
Channel scan starts fine, finds some channels and after a random
duration it crashes. I already tried starting the kernel with nosmp,
noapic, and noacpi options but that does not change anything.
Kernel trace:
---
[ 773.280361] IP: [f825a7ba] saa7146_buffer_next+0x5e/0x1ed [saa7146_vv]
[ 773.280361] *pde =
[ 773.280361] Oops: [#1] SMP
[ 773.280361] last sysfs file: /sys/module/nfsd/initstate
[ 773.280361] Modules linked in: nfsd exportfs nfs lockd nfs_acl
auth_rpcgss sunrpc f71882fg coretemp loop lnbp21 stv0299 dvb_ttpci
snd_hda_codec_realtek dvb_core saa7146_vv videodev v4l1_compat
snd_hda_intel saa7146 snd_hda_codec videobuf_dma_sg snd_hwdep
videobuf_core snd_pcm i2c_i801 ttpci_eeprom psmouse snd_timer intel_agp
evdev pcspkr snd i2c_core serio_raw agpgart video processor rng_core
soundcore button output snd_page_alloc usb_storage uhci_hcd ehci_hcd
thermal sd_mod crc_t10dif thermal_sys usbcore nls_base e1000e [last
unloaded: scsi_wait_scan]
[ 773.280361]
[ 773.280361] Pid: 0, comm: swapper Not tainted 2.6.34-rc7 #7
A9830IMS/A9830IMS
[ 773.280361] EIP: 0060:[f825a7ba] EFLAGS: 00010246 CPU: 0
[ 773.280361] EIP is at saa7146_buffer_next+0x5e/0x1ed [saa7146_vv]
[ 773.280361] EAX: f68b3008 EBX: f733d900 ECX: 0001 EDX: 0002
[ 773.280361] ESI: ffd4 EDI: f68b3000 EBP: ESP: c135fefc
[ 773.280361] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 773.280361] Process swapper (pid: 0, ti=c135e000 task=c138cb60
task.ti=c135e000)
[ 773.280361] Stack:
[ 773.280361] f68b3000 f733d900 c13640bc 000a f825e5f6 f733d900
fff7fbf7 f825a759
[ 773.280361] 0 f733d900 f812bdfc fff7fbf7 f6a1e240
c106793a
[ 773.280361] 0 c1364080 000a c13640bc c135ff80 c1069072
000a 000a
[ 773.280361] Call Trace:
[ 773.280361] [f825e5f6] ? vbi_irq_done+0x99/0x9f [saa7146_vv]
[ 773.280361] [f825a759] ? vv_callback+0x10f/0x112 [saa7146_vv]
[ 773.280361] [f812bdfc] ? interrupt_hw+0x9f/0x1a8 [saa7146]
[ 773.280361] [c106793a] ? handle_IRQ_event+0x49/0xe7
[ 773.280361] [c1069072] ? handle_level_irq+0x55/0x9e
[ 773.280361] [c10044cb] ? handle_irq+0x17/0x1c
[ 773.280361] [c1003da9] ? do_IRQ+0x38/0x8e
[ 773.280361] [c1002d30] ? common_interrupt+0x30/0x38
[ 773.280361] [c10086e6] ? mwait_idle+0x59/0x5e
[ 773.280361] [c1001ae7] ? cpu_idle+0x91/0xaa
[ 773.280361] [c13b9881] ? start_kernel+0x31c/0x321
[ 773.280361] Code: 50 fc 25 f8 e8 9d 0e 01 c9 83 c4 1c 8b 43 44 89 c2
c1 fa 08 38 c2 75 04 0f 0b eb fe 8b 77 08 8d 47 08 39 c6 74 6b 83 ee 2c
31 ed 8b 4e 2c 8b 56 30 89 51 04 89 0a c7 46 2c 00 01 10 00 c7 46 30
Refer to linux/drivers/media/common/saa7146_fops.c:saa7146_buffer_next()
void saa7146_buffer_next(struct saa7146_dev *dev,
struct saa7146_dmaqueue *q, int vbi)
{
struct saa7146_buf *buf,*next = NULL;
BUG_ON(!q);
DEB_INT((dev:%p, dmaq:%p, vbi:%d\n, dev, q, vbi));
assert_spin_locked(dev-slock);
if (!list_empty(q-queue)) {
/* activate next one from queue */
buf = list_entry(q-queue.next,struct
saa7146_buf,vb.queue);
list_del(buf-vb.queue);
if (!list_empty(q-queue))
[...]
The code bytes from the above disassemble to:
37: e8 9d 0e 01 c9 call 0xc9010ed9
3c: 83 c4 1cadd$0x1c,%esp
3f: 8b 43 44mov0x44(%ebx),%eax
42: 89 c2 mov%eax,%edx
44: c1 fa 08sar$0x8,%edx
47: 38 c2 cmp%al,%dl
49: 75 04 jne0x4f
4b: 0f 0b ud2a ---+ End of BUG_ON() in
4d: eb fe jmp0x4d ---| assert_spin_locked()
4f: 8b 77 08mov0x8(%edi),%esi ; %esi = q-queue-head
52: 8d 47 08lea0x8(%edi),%eax ; %eax =
q-queue-head-next
55: 39 c6 cmp%eax,%esi ; if
(!list_empty(q-queue))
57: 74 6b je 0xc4; skip to else clause
59: 83 ee 2csub$0x2c,%esi ; buf =
list_entry(q-queue.next,struct
a short video that developers will likely enjoy
The following is a link to an approx. 11min video. The connection pt. to what you are doing here comes in it in around the 8 min mark, so bear with it (though I highly doubt it will be in any way insufferable). I hope you enjoy this little diversion (I think most will). http://www.youtube.com/watch?v=u6XAPnuFjJc -- 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 08/21] drivers/media: Remove unnecesary kmalloc casts
Signed-off-by: Joe Perches j...@perches.com
---
drivers/media/dvb/siano/smscoreapi.c |4 +---
drivers/media/video/w9968cf.c|3 +--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/siano/smscoreapi.c
b/drivers/media/dvb/siano/smscoreapi.c
index 0c87a3c..828bcc2 100644
--- a/drivers/media/dvb/siano/smscoreapi.c
+++ b/drivers/media/dvb/siano/smscoreapi.c
@@ -116,9 +116,7 @@ static struct smscore_registry_entry_t
*smscore_find_registry(char *devpath)
return entry;
}
}
- entry = (struct smscore_registry_entry_t *)
- kmalloc(sizeof(struct smscore_registry_entry_t),
- GFP_KERNEL);
+ entry = kmalloc(sizeof(struct smscore_registry_entry_t), GFP_KERNEL);
if (entry) {
entry-mode = default_mode;
strcpy(entry-devpath, devpath);
diff --git a/drivers/media/video/w9968cf.c b/drivers/media/video/w9968cf.c
index d807eea..591fc6d 100644
--- a/drivers/media/video/w9968cf.c
+++ b/drivers/media/video/w9968cf.c
@@ -3429,8 +3429,7 @@ w9968cf_usb_probe(struct usb_interface* intf, const
struct usb_device_id* id)
else
return -ENODEV;
- cam = (struct w9968cf_device*)
- kzalloc(sizeof(struct w9968cf_device), GFP_KERNEL);
+ cam = kzalloc(sizeof(struct w9968cf_device), GFP_KERNEL);
if (!cam)
return -ENOMEM;
--
1.7.0.3.311.g6a6955
--
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: tm6000 audio urb
Em 31-05-2010 19:22, Luis Henrique Fagundes escreveu:
Hi,
I'm having my first adventures on driver coding, trying to help audio
development of tm6000 based on Mauro's hints.
According to Mauro and coding comments, the audio URBs are already
being received by tm6000-video. The copy_packet function correctly
filters video packets (identified as cmd=1, extracted from header) and
the tm6000_msg_type array suggests that the cmd=2 would be the audio
packets. I logged all packets not being copied to video buffer and
realized that the only packets remaining have been identified as
cmd=4, which is supposedly type pts.
For me it looks like either the cmd=4 type is audio, or the audio is
not really being received. Does this make sense?
Luis Henrique,
The audio type is correct. You should notice that some logic is needed to enable
audio at tm6000. For example, you'll see this code at tm6000-alsa:
static int _tm6000_start_audio_dma(struct snd_tm6000_card *chip)
{
struct tm6000_core *core = chip-core;
int val;
/* Enables audio */
val = tm6000_get_reg(core, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, 0x0);
val |= 0x20;
tm6000_set_reg(core, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, val);
tm6000_set_reg(core, TM6010_REQ08_R01_A_INIT, 0x80);
return 0;
}
You'll also see this at tm6000-core:
tm6000_set_audio_bitrate (dev,48000);
...
int tm6000_set_audio_bitrate(struct tm6000_core *dev, int bitrate)
{
int val;
val=tm6000_get_reg (dev, REQ_07_SET_GET_AVREG, 0xeb, 0x0);
printk(Original value=%d\n,val);
if (val0)
return val;
val = 0x0f;/* Preserve the audio input control bits */
switch (bitrate) {
case 44100:
val|=0xd0;
dev-audio_bitrate=bitrate;
break;
case 48000:
val|=0x60;
dev-audio_bitrate=bitrate;
break;
}
val=tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0xeb, val);
return val;
}
You need to double check if the enabling stuff is properly called
at the right place.
I'm sure that, before adding tm6010 support, audio packages got received.
Eventually, some new patches to add support for tm6010 might have broken
the reception of audio packages.
So, I suggest that you should play with those routines and review the
git backlog to get what's going wrong.
Luis
--
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
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
Re: [PATCH] tm6000: rewrite copy_streams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 01.06.2010 00:09, schrieb Mauro Carvalho Chehab:
Em 31-05-2010 12:25, stefan.rin...@arcor.de escreveu:
From: Stefan Ringel stefan.rin...@arcor.de
fusion function copy streams and copy_packets to new function
copy_streams.
There's something wrong with this patch:
$ patch -p1 -i /tmp/tm6000\:\ rewrite\ copy_streams.eml -l
(Stripping trailing CRs from patch.)
patching file drivers/staging/tm6000/tm6000-usb-isoc.h
(Stripping trailing CRs from patch.)
patching file drivers/staging/tm6000/tm6000-video.c
Hunk #1 FAILED at 186.
Hunk #2 FAILED at 439.
Hunk #3 FAILED at 451.
3 out of 6 hunks FAILED -- saving rejects to file
drivers/staging/tm6000/tm6000-video.c.rej
Please rebase it against git branch devel/for_v2.6.35 of my
v4l-dvb.git tree.
Thanks, I rebase it and send it new today.
static int copy_streams(u8 *data, unsigned long len,
struct urb *urb)
{
struct tm6000_dmaqueue *dma_q = urb-context;
struct tm6000_core *dev= container_of(dma_q,struct tm6000_core,vidq);
-u8 *ptr=data, *endp=data+len;
+u8 *ptr=data, *endp=data+len, c;
unsigned long header=0;
int rc=0;
-struct tm6000_buffer *buf;
-char *outp = NULL;
-
-get_next_buf(dma_q, buf);
-if (buf)
-outp = videobuf_to_vmalloc(buf-vb);
+unsigned int cmd, cpysize, pktsize, size, field, block, line, pos
= 0;
+struct tm6000_buffer *vbuf;
+char *voutp = NULL;
+unsigned int linewidth;
-if (!outp)
+/* get video buffer */
+get_next_buf (dma_q, vbuf);
+if (!vbuf)
+return rc;
+voutp = videobuf_to_vmalloc(vbuf-vb);
+if (!voutp)
return 0;
-for (ptr=data; ptrendp;) {
+for (ptr = data; ptr endp;) {
if (!dev-isoc_ctl.cmd) {
-u8 *p=(u8 *)dev-isoc_ctl.tmp_buf;
-/* FIXME: This seems very complex
- * It just recovers up to 3 bytes of the header that
- * might be at the previous packet
- */
-if (dev-isoc_ctl.tmp_buf_len) {
-while (dev-isoc_ctl.tmp_buf_len) {
-if ( *(ptr+3-dev-isoc_ctl.tmp_buf_len) == 0x47) {
-break;
-}
-p++;
-dev-isoc_ctl.tmp_buf_len--;
-}
-if (dev-isoc_ctl.tmp_buf_len) {
-memcpy(header, p,
-dev-isoc_ctl.tmp_buf_len);
-memcpy((u8 *)header +
+/* Header */
+if (dev-isoc_ctl.tmp_buf_len 0) {
+/* from last urb or packet */
+header = dev-isoc_ctl.tmp_buf;
+if (4 - dev-isoc_ctl.tmp_buf_len 0) {
+memcpy ((u8 *)header +
dev-isoc_ctl.tmp_buf_len,
ptr,
4 - dev-isoc_ctl.tmp_buf_len);
ptr += 4 - dev-isoc_ctl.tmp_buf_len;
-goto HEADER;
}
+dev-isoc_ctl.tmp_buf_len = 0;
+} else {
+if (ptr + 3 = endp) {
+/* have incomplete header */
+dev-isoc_ctl.tmp_buf_len = endp - ptr;
+memcpy (dev-isoc_ctl.tmp_buf, ptr,
+dev-isoc_ctl.tmp_buf_len);
+return rc;
+}
+/* Seek for sync */
+for (; ptr endp - 3; ptr++) {
+if (*(ptr + 3) == 0x47)
+break;
+}
+/* Get message header */
+header = *(unsigned long *)ptr;
+ptr += 4;
}
-/* Seek for sync */
-for (;ptrendp-3;ptr++) {
-if (*(ptr+3)==0x47)
-break;
+/* split the header fields */
+c = (header 24) 0xff;
+size = ((header 0x7e) 1);
+if (size 0)
+size -= 4;
+block = (header 7) 0xf;
+field = (header 11) 0x1;
+line = (header 12) 0x1ff;
+cmd = (header 21) 0x7;
+/* Validates haeder fields */
+if (size TM6000_URB_MSG_LEN)
+size = TM6000_URB_MSG_LEN;
+pktsize = TM6000_URB_MSG_LEN;
+/* calculate position in buffer
+ * and change the buffer
+ */
+switch (cmd) {
+case TM6000_URB_MSG_VIDEO:
+if ((dev-isoc_ctl.vfield != field)
+(field == 1)) {
+/* Announces that a new buffer
+ * were filled
+ */
+buffer_filled (dev, dma_q, vbuf);
+dprintk (dev, V4L2_DEBUG_ISOC,
+new
Re: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)
On Mon, May 31, 2010 at 10:48:32PM +0100, Richard Purdie wrote: On Mon, 2010-05-31 at 12:09 -0700, Dmitry Torokhov wrote: On Mon, May 31, 2010 at 02:55:48PM +0200, Wolfram Sang wrote: I2C-drivers can use the clientdata-pointer to point to private data. As I2C devices are not really unregistered, but merely detached from their driver, it used to be the drivers obligation to clear this pointer during remove() or a failed probe(). As a couple of drivers forgot to do this, it was agreed that it was cleaner if the i2c-core does this clearance when appropriate, as there is no guarantee for the lifetime of the clientdata-pointer after remove() anyhow. This feature was added to the core with commit e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. As there is no need anymore to clear the clientdata-pointer, remove all current occurrences in the drivers to simplify the code and prevent confusion. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Jean Delvare kh...@linux-fr.org --- Some more notes: I waited for rc1 as I knew there were some drivers/patches coming along which needed to be processed, too. I'd suggest that this goes via the i2c-tree, so we get rid of all occurences at once. Frankly I'd prefer taking input stuff through my tree with the goal of .36 merge window just to minimize potential merge issues. This is a simple cleanup patch that has no dependencies, so there is little gain from doing it all in one go. How about asking Linus to take this one now, then its done and we can all move on rather than queuing up problems for the next merge window? That should work. Acked-by: Dmitry Torokhov d...@mail.ru Acked-by: Richard Purdie rpur...@linux.intel.com -- Dmitry -- 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: ir-core multi-protocol decode and mceusb
On Mon, May 31, 2010 at 6:31 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 31-05-2010 18:45, Andy Walls escreveu:
On Mon, 2010-05-31 at 17:58 -0300, Mauro Carvalho Chehab wrote:
I may be wrong (since we didn't write any TX support), but I think that a
rc_set_tx_parameters() wouldn't be necessary, as I don't see why the driver
will
change the parameters after registering, and without any userspace request.
Yes, my intent was to handle a user space request to change the
transmitter setup parameters to handle the protocol.
I also don't want to worry about having to code in kernel parameter
tables for any bizzare protocol userspace may know about.
Makes sense.
If we consider that some userspace sysfs nodes will allow changing some
parameters,
then the better is to have a callback function call, passed via the
registering function,
that will allow calling a function inside the driver to change the TX
parameters.
For example, something like:
struct rc_tx_props {
...
int (*change_protocol)(...);
...
};
rc_register_tx(..., struct rc_tx_props *props)
A callback is likely needed. I'm not sure I would have chosen the name
change_protocol(), because transmitter parameters can be common between
protocols (at least RC-5 and RC-6 can be supported with one set of
parameters), or not match any existing in-kernel protocol. As long as
it is flexible enough to change individual transmitter parameters
(modulated/baseband, carrier freq, duty cycle, etc.) it will be fine.
I just used this name as an example, as the same name exists on RX.
Depending on how we code the userspace API, we may use just one set_parameters
function, or a set of per-attribute changes.
In other words, if we implement severa sysfs nodes to change several
parameters,
maybe it makes sense to have several callbacks. Another alternative would be
to have a commit sysfs node to apply a set of parameters at once.
Currently LIRC userspace changes Tx parameters using an ioctl(). It
asks the hardware to change transmitter parameters, because the current
model is that the transmitters don't need to know about protocols. (LIRC
userspace knows the parameters of the protocol it wants to use, so the
driver's don't have too).
The list of transmit-related ioctls implemented in the lirc_mceusb driver:
- LIRC_SET_TRANSMITTER_MASK -- these devices have two IR tx outputs,
default is to send the signal out both, but you can also select just a
specific one (i.e., two set top boxes, only want to send command to
one or the other of them).
- LIRC_GET_SEND_MODE -- get current transmit mode
- LIRC_SET_SEND_MODE -- set current transmit mode
- LIRC_SET_SEND_CARRIER -- set the transmit carrier freq
- LIRC_GET_FEATURE -- get both the send and receive capabilities of the device
I notice IR Rx also has a change_protocol() callback that is not
currently in use.
It is used only by em28xx, where the hardware decoder can work either with
RC-5 or NEC (newer chips also support RC-6, but this is currently not
implemented).
The imon driver also implements change_protocol for the current-gen
devices, which are capable of decoding either mce remote signals or
the native imon remote signals. I was originally thinking I'd need to
implement change_protocol for the mceusb driver, but its ultimately a
no-op, since the hardware doesn't give a damn (and there's a note
somewhere that mentions its only relevant for hardware decode devices
that need to be put into a specific mode). Although, on something like
the mceusb driver, change_protocol *could* be wired up to mark only
the desired protocol enabled -- which might reduce complexity for
ir-keytable when loading a new keymap. (I went with a rather simple
approach for marking only the desired decoder enabled at initial
keymap load time which won't help here -- patch coming tomorrow for
that).
If sending raw pulses to userspace, it would be also
nice to expose that callback so userspace could set the receiver
parameters.
Raw pulse transmission is probably the easiest case. Probably, there's nothing
or a very few things that might need adjustments.
Transmitter mask, carrier frequency and a repeat count are the things
I can see needing to set regularly. From experience, at least with
motorola set top box hardware, you need to send a given signal 2-3
times, not just once, for the hardware to pick it up. There's a
min_repeat parameter in lirc config files only used on the transmit
side of the house to specify how many repeats of each blasted signal
to send.
--
Jarod Wilson
ja...@wilsonet.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
