Re: [RFC] Making Samsung S3C64XX camera interface driver in SoC camera subsystem
Hi Guennadi, On Fri, Apr 17, 2009 at 4:58 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 16 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hello, I'm planing to make a new camera interface driver for S3C64XX from Samsung. Even if it already has a driver, it seems to be re-designed for some reasons. If you are interested in, take a look at following repository (http://git.kernel.org/?p=linux/kernel/git/eyryu_ap/samsung-ap-2.6.24.git;a=summary) drivers/media/video/s3c_* files Before beginning to implement a new driver for that, I need to clarify some of features about how to implement in driver. Please take a look at the diagram on page 610 of following user manual of s3c6400. http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C6400X_UserManual_rev1-0_2008-02_661558um.pdf It seems to have a couple of path for camera data named codec and preview, and they could be used at the same time. It means that it has no problem making those two paths into independent device nodes like /dev/video0 and /dev/video1 But there is a limit of size using both of paths at the same time. I mean, If you are using preview path and camera sensor is running with 1280*720 resolution (which seems to be the max resolution could be handled by preview path), codec path can't use resolution bigger than 1280*720 at the same time because camera sensor can't produce different resolution at a time. And also we should face a big problem when we are making dual camera system with s3c64xx. Dual camera with single camera interface has some restriction using clock and data path, because they have to be shared between both of cameras. I suppose to handle them with VIDIOC_S_INPUT and G_INPUT. And with those, we can handle dual camera with single camera interface in a decent way. But the thing is that there should be a problem using dual camera with preview and codec path of s3c64xx. Even if we have each preview, and codec device node and can't open them concurrently when user is attempting to open each camera sensor like camera A with preview node and camera B with codec node. Because both of those camera sensors are sharing same data path and clock source, and s3c64xx camera interface only can handle one camera at a time. So, what I am concerned is how to make it a elegant driver which has two device nodes handling multiple sensors as input devices. Sounds complicated but I'm asking you to help me with any opinion about designing this driver. Any opinion about these issues will be greatly helpful to me. Ok, now I understand your comments to my soc-camera thread better. Now, what about making one (or more) video devices with V4L2_CAP_VIDEO_CAPTURE type and one with V4L2_CAP_VIDEO_OUTPUT? Then you can use your capture type devices to switch between cameras and to configure input, and your output device to configure preview? Then you can use soc-camera to control your capture devices (if you want to of course) and implement an output device directly. It should be a much simpler device, because it will not be communicating with the cameras and only modify various preview parameters. It's a cool idea! Adding my understanding to your comment, 1. make preview device a video output = it makes sense. but codec path also has dedicated DMA to frame buffer. What should we do with that? I have no idea by now. 2. preview device can have two inputs a) input from camera device : ok it's an ordinary way b) input from MSDMA : we can give RGB data upto 720P to preview device with rotating and resizing supported Does it sound ok? BTW, OMAP3 has similar feature with this. omap vout something? And by now I'm gonna make my driver with soc camera subsystem without VIDIOC_S_INPUT/G_INPUT, but I'm still desperate for that. Thank you for your opinion. I deeply appreciate that. Cheers, Nate Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Making Samsung S3C64XX camera interface driver in SoC camera subsystem
On Fri, 17 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hi Guennadi, On Fri, Apr 17, 2009 at 4:58 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Ok, now I understand your comments to my soc-camera thread better. Now, what about making one (or more) video devices with V4L2_CAP_VIDEO_CAPTURE type and one with V4L2_CAP_VIDEO_OUTPUT? Then you can use your capture type devices to switch between cameras and to configure input, and your output device to configure preview? Then you can use soc-camera to control your capture devices (if you want to of course) and implement an output device directly. It should be a much simpler device, because it will not be communicating with the cameras and only modify various preview parameters. It's a cool idea! Adding my understanding to your comment, 1. make preview device a video output = it makes sense. but codec path also has dedicated DMA to frame buffer. What should we do with that? I have no idea by now. Add a V4L2_CAP_VIDEO_OVERLAY capability and if the user requests V4L2_BUF_TYPE_VIDEO_OVERLAY - configure direct output to framebuffer? 2. preview device can have two inputs a) input from camera device : ok it's an ordinary way b) input from MSDMA : we can give RGB data upto 720P to preview device with rotating and resizing supported Does it sound ok? Yes, looks good to me:-) BTW, OMAP3 has similar feature with this. omap vout something? And by now I'm gonna make my driver with soc camera subsystem without VIDIOC_S_INPUT/G_INPUT, but I'm still desperate for that. Don't dispair - better send a patch when good times return (i.e., when we are fully with v4l2-subdev):-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Making Samsung S3C64XX camera interface driver in SoC camera subsystem
Hi Guennadi, On Fri, Apr 17, 2009 at 4:00 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 17 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hi Guennadi, On Fri, Apr 17, 2009 at 4:58 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Ok, now I understand your comments to my soc-camera thread better. Now, what about making one (or more) video devices with V4L2_CAP_VIDEO_CAPTURE type and one with V4L2_CAP_VIDEO_OUTPUT? Then you can use your capture type devices to switch between cameras and to configure input, and your output device to configure preview? Then you can use soc-camera to control your capture devices (if you want to of course) and implement an output device directly. It should be a much simpler device, because it will not be communicating with the cameras and only modify various preview parameters. It's a cool idea! Adding my understanding to your comment, 1. make preview device a video output = it makes sense. but codec path also has dedicated DMA to frame buffer. What should we do with that? I have no idea by now. Add a V4L2_CAP_VIDEO_OVERLAY capability and if the user requests V4L2_BUF_TYPE_VIDEO_OVERLAY - configure direct output to framebuffer? OK that's an idea. Then we can use preview as video output device and codec device as a capture device with overlay capability. 2. preview device can have two inputs a) input from camera device : ok it's an ordinary way b) input from MSDMA : we can give RGB data upto 720P to preview device with rotating and resizing supported Does it sound ok? Yes, looks good to me:-) BTW, OMAP3 has similar feature with this. omap vout something? And by now I'm gonna make my driver with soc camera subsystem without VIDIOC_S_INPUT/G_INPUT, but I'm still desperate for that. Don't dispair - better send a patch when good times return (i.e., when we are fully with v4l2-subdev):-) Priority job first and let's talk about it later. I also have to convert my sensor drivers into v4l2-subdev drivers before I post my patches to the list. Cheers, Nate Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Making Samsung S3C64XX camera interface driver in SoC camera subsystem
On Fri, 17 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hi Guennadi, On Fri, Apr 17, 2009 at 4:00 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 17 Apr 2009, Dongsoo, Nathaniel Kim wrote: 1. make preview device a video output = it makes sense. but codec path also has dedicated DMA to frame buffer. What should we do with that? I have no idea by now. Add a V4L2_CAP_VIDEO_OVERLAY capability and if the user requests V4L2_BUF_TYPE_VIDEO_OVERLAY - configure direct output to framebuffer? OK that's an idea. Then we can use preview as video output device and codec device as a capture device with overlay capability. Actually, if I interpret the Camera interface overview figure (20-1) correctly, both capture and output channels have the overlay capability, so, you can enable it for both of them and configure the respective one accordingly. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] soc-camera: convert to platform device
Hello, I've got one more thing to ask. Is SoC camera framework supporting for selecting video standards between camera interface and external camera module? I mean ITU-R BT 601 and 656 things. Or any different way that I'm not aware is supported? On Wed, Apr 15, 2009 at 9:17 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: This patch series is a preparation for the v4l2-subdev conversion. Please, review and test. My current patch-stack in the form of a (manually-created) quilt-series is at http://www.open-technology.de/download/20090415/ based on linux-next history branch, commit ID in -base file. Don't be surprised, that patch-set also contains a few not directly related patches. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Making Samsung S3C64XX camera interface driver in SoC camera subsystem
On Fri, Apr 17, 2009 at 4:15 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 17 Apr 2009, Dongsoo, Nathaniel Kim wrote: Hi Guennadi, On Fri, Apr 17, 2009 at 4:00 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 17 Apr 2009, Dongsoo, Nathaniel Kim wrote: 1. make preview device a video output = it makes sense. but codec path also has dedicated DMA to frame buffer. What should we do with that? I have no idea by now. Add a V4L2_CAP_VIDEO_OVERLAY capability and if the user requests V4L2_BUF_TYPE_VIDEO_OVERLAY - configure direct output to framebuffer? OK that's an idea. Then we can use preview as video output device and codec device as a capture device with overlay capability. Actually, if I interpret the Camera interface overview figure (20-1) correctly, both capture and output channels have the overlay capability, so, you can enable it for both of them and configure the respective one accordingly. You are right. both of them can have overlay capability. I just forgot that It could be configured like that. Thank you. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] soc-camera: convert to platform device
Hi Guennadi, On Wed, Apr 15, 2009 at 9:17 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: This patch series is a preparation for the v4l2-subdev conversion. Please, review and test. My current patch-stack in the form of a (manually-created) quilt-series is at http://www.open-technology.de/download/20090415/ based on linux-next history branch, commit ID in -base file. Don't be surprised, that patch-set also contains a few not directly related patches. Testing on Migo-R board with 2.6.30-rc2-git-something and the following cherry-picked patches: 0007-driver-core-fix-driver_match_device.patch 0033-soc-camera-host-driver-cleanup.patch 0034-soc-camera-remove-an-extra-device-generation-from-s.patch 0035-soc-camera-simplify-register-access-routines-in-mul.patch and part of 0036 (avoiding rejects, ap325 seems broken btw) It compiles just fine, boots up allright, but I can't open /dev/video0 anymore. It's still supposed to work with all drivers compiled-in, right? I'll investigate a bit more and update to latest linux-2.6 git. / magnus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] soc-camera: convert to platform device
On Fri, 17 Apr 2009, Dongsoo, Nathaniel Kim wrote: I've got one more thing to ask. Is SoC camera framework supporting for selecting video standards between camera interface and external camera module? I mean ITU-R BT 601 and 656 things. Or any different way that I'm not aware is supported? I thought someone did it already, maybe there were some patches that didn't make it in yet, cannot find ATM. In any case, we do have a pretty advanced (!:-)) bus parameter negotiation infrastructure, so, you would just have a couple more SOCAM_* flags, like SOCAM_BT601, SOCAM_BT656 or similar and use them to configure your host-camera link, depending upon their capabilities and platform flags. See for example how SOCAM_MASTER / SOCAM_SLAVE is selected. Also don't forget to extend the soc_camera_bus_param_compatible() function. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some questions about mr97310 controls (continuing previous thread on mr97310a.c)
Hi All,
On 04/17/2009 12:50 AM, Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Thomas Kaiser wrote:
snip
Just how does it work to set the Compression Balance size? Is this
some kind of special command sequence? Are we able to set this to
whatever we want?
It looks like. One can set a value from 0x0 to 0xff in the
Compression Balance size register (reg 0x4a).
In the pac207 Linux driver, this register is set to 0xff to turn off
the compression. While we use compression 0x88 is set (I think the
same value like in Windoz). Hans did play with this register and found
out that the compression changes with different values.
I wonder how this relates to the mr97310a. There is no such register
present, that I can see.
Hans, may you explain a bit more what you found out?
(Yes, please.)
Quoting from linux/drivers/media/video/gspca/pac207.c
(easiest for me as it has been a while I looked at this):
/* An exposure value of 4 also works (3 does not) but then we need to lower
the compression balance setting when in 352x288 mode, otherwise the usb
bandwidth is not enough and packets get dropped resulting in corrupt
frames. The problem with this is that when the compression balance gets
lowered below 0x80, the pac207 starts using a different compression
algorithm for some lines, these lines get prefixed with a 0x2dd2 prefix
and currently we do not know how to decompress these lines, so for now
we use a minimum exposure value of 5 */
#define PAC207_EXPOSURE_MIN 5
#define PAC207_EXPOSURE_MAX 26
And from libv4l/libv4lconvert/pac207.c:
void v4lconvert_decode_pac207(const unsigned char *inp, unsigned char *outp,
int width, int height)
{
/* we should received a whole frame with header and EOL marker
in myframe-data and return a GBRG pattern in frame-tmpbuffer
remove the header then copy line by line EOL is set with 0x0f 0xf0 marker
or 0x1e 0xe1 for compressed line*/
unsigned short word;
int row;
/* iterate over all rows */
for (row = 0; row height; row++) {
word = getShort(inp);
switch (word) {
case 0x0FF0:
memcpy(outp, inp + 2, width);
inp += (2 + width);
break;
case 0x1EE1:
inp += pac_decompress_row(inp, outp, width);
break;
case 0x2DD2: /* prefix for stronger compressed lines, currently the
kernel driver programs the cam so that we should not
get any of these */
default: /* corrupt frame */
/* FIXME add error reporting */
return;
}
outp += width;
}
So iow, the pac207 prefixes each row of a frame it sends out with 2 bytes,
indication the type of compression used, 0FF0 == no compression,
1ee1 == compression currently known in libv4l
But if you lower the compression balance register below 0x80, it will also
send out rows prefixed with 2DD2, and we (I) have no clue how to decompress
these. If we could find out how to handle these, that would be great, as we
then could lower the exposure time more when in full daylight, curing the
over exposure problems we have in full daylight.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVB-S / S2 reception issues when upgrading to 2.6.28-6
Hi,
Not sure if this is a bug or intended behaviour, but we're having some
reception issues on some recent DVB-S/S2 cards (Hauppauge Nova S-Plus
and HVR-4000 Lite) after upgrading from 2.6.19-7 to 2.6.28-6 (Vanilla
kernel.org versions)
Steps to reproduce:
szap -c /etc/dvb/transponders sat -x
dvbsnoop -adapter 0 -b PID | pv /dev/null
= nothing
python -c import time; f = file('/dev/dvb/adapter0/frontend0');
time.sleep(1)
= Transfer running again
With Debian packages:
dvb-apps 1.1.1+rev1207-4
dvbsnoop 1.4.50-2
Since we basically want constant reception on the DVB network
interface, we deactivated the power-saving features of the DVB cards:
# cat /etc/modprobe.d/dvb-driver
options dvb_core dvb_shutdown_timeout=0 dvb_powerdown_on_sleep=0
From what I can gather, only the most recent cards (the HVR4000 and
the Nova S-Plus) display this kind of behaviour. It would seem the
power-saving features available on these newer types of card with more
recent drivers could be the cause of the problem: despite the module
options, they'd still power off when the frontend is released (once
again, this is pure speculation on my part).
From time to time, we also lose satellite reception, and the following
error appears in kern.log:
cx8802_start_dma() Failed. Unsupported value in .mpeg (0x0001)
Running szap continuously solves the problem, but it seems like an
ugly hack to get this working, especially knowing it worked correctly
in 2.6.19-7.
Cheers,
--
Nicolas Noirbent - Core Software Developer
SmartJog SAS - www.smartjog.com - A TDF Group Company
Office: 27, blvd Hippolyte Marques 94200 Ivry-sur-Seine - France EU
Phone: +33 (0)1 5868 6234
--
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 0/5] soc-camera: convert to platform device
On Fri, Apr 17, 2009 at 4:51 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 17 Apr 2009, Magnus Damm wrote: On Wed, Apr 15, 2009 at 9:17 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: This patch series is a preparation for the v4l2-subdev conversion. Please, review and test. My current patch-stack in the form of a (manually-created) quilt-series is at http://www.open-technology.de/download/20090415/ based on linux-next history branch, commit ID in -base file. Don't be surprised, that patch-set also contains a few not directly related patches. Testing on Migo-R board with 2.6.30-rc2-git-something and the following cherry-picked patches: 0007-driver-core-fix-driver_match_device.patch 0033-soc-camera-host-driver-cleanup.patch 0034-soc-camera-remove-an-extra-device-generation-from-s.patch 0035-soc-camera-simplify-register-access-routines-in-mul.patch and part of 0036 (avoiding rejects, ap325 seems broken btw) Have I broken it or is it unrelated? 2.6.30-rc seems broken on Migo-R. A quick check suggests the following: V4L/DVB (10141): OK V4L/DVB (10672): BAD V4L/DVB (11024): BAD OK means mplayer capture works as excepted with CEU and ov772x. BAD means failure to open() /dev/video0 in the case of CEU. vivi works fine. Morimoto-san and/or Guennadi, do you see the same thing? Cheers, / magnus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] soc-camera: convert to platform device
On Fri, 17 Apr 2009, Magnus Damm wrote: On Fri, Apr 17, 2009 at 4:51 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 17 Apr 2009, Magnus Damm wrote: On Wed, Apr 15, 2009 at 9:17 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: This patch series is a preparation for the v4l2-subdev conversion. Please, review and test. My current patch-stack in the form of a (manually-created) quilt-series is at http://www.open-technology.de/download/20090415/ based on linux-next history branch, commit ID in -base file. Don't be surprised, that patch-set also contains a few not directly related patches. Testing on Migo-R board with 2.6.30-rc2-git-something and the following cherry-picked patches: 0007-driver-core-fix-driver_match_device.patch 0033-soc-camera-host-driver-cleanup.patch 0034-soc-camera-remove-an-extra-device-generation-from-s.patch 0035-soc-camera-simplify-register-access-routines-in-mul.patch and part of 0036 (avoiding rejects, ap325 seems broken btw) Have I broken it or is it unrelated? 2.6.30-rc seems broken on Migo-R. A quick check suggests the following: Ok, before we come to Migo-R, what is with ap325? Have I broken it with this my series or is it a different problem? V4L/DVB (10141): OK V4L/DVB (10672): BAD V4L/DVB (11024): BAD These seem to be pretty random snapshots... Are they all on Linus' master or on next or on v4l-dvb? You did pick up the 0007-driver-core-fix-driver_match_device.patch above, so, you know about that problem (I am very much surprised in fact that patch is still not in the mainline, just sent a reminder...), and you did use it in all your tests with kernels past 49b420a13ff95b449947181190b08367348e3e1b didn't you? OK means mplayer capture works as excepted with CEU and ov772x. BAD means failure to open() /dev/video0 in the case of CEU. vivi works fine. Morimoto-san and/or Guennadi, do you see the same thing? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tda7432: Delete old driver history
On Tue, 7 Apr 2009 17:55:17 +0200, Jean Delvare wrote: The history of changes does belong to git. Signed-off-by: Jean Delvare kh...@linux-fr.org --- In general I wouldn't care too much but it happens that this specific comment triggers a false positive in one of my scripts, so I'd rather get rid of it. linux/drivers/media/video/tda7432.c | 14 -- 1 file changed, 14 deletions(-) Mauro, can you please apply this patch? Thanks. --- v4l-dvb.orig/linux/drivers/media/video/tda7432.c 2009-04-06 10:10:25.0 +0200 +++ v4l-dvb/linux/drivers/media/video/tda7432.c 2009-04-07 17:44:59.0 +0200 @@ -20,20 +20,6 @@ * loudness - set between 0 and 15 for varying degrees of loudness effect * * maxvol - set maximium volume to +20db (1), default is 0db(0) - * - * - * Revision: 0.7 - maxvol module parm to set maximium volume 0db or +20db - * store if muted so we can return it - * change balance only if flaged to - * Revision: 0.6 - added tone controls - * Revision: 0.5 - Fixed odd balance problem - * Revision: 0.4 - added muting - * Revision: 0.3 - Fixed silly reversed volume controls. :) - * Revision: 0.2 - Cleaned up #defines - * fixed volume control - * Added I2C_DRIVERID_TDA7432 - * added loudness insmod control - * Revision: 0.1 - initial version */ #include linux/module.h -- 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
Hauppauge HVR-1500 (aka HP RM436AA#ABA)
The code compiles. Okay, great. Can anyone actually use this thing in Linux? I can't on my 1-year-old HP dv-6629. Thank you. -- 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: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter Card Support
Hi Vaibav, I am using Sergio's patch that was posted on dec12th. I have been trying to apply the mdc driver patches + camera drivers/isp drivers patches related to mdc on sergio's dec 12th patches. They fail to apply at all. I would appreciate if you could send me those patches. Regards, sriram On Wed, Jan 7, 2009 at 11:37 AM, hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com This is first version of OMAP3EVM Mulit-Media Daughter Card support. Tested: - TVP5146 (BT656) decoder interface on top of Sergio's ISP-Camera patches. - Loopback application, capturing image through TVP5146 and displaying it onto the TV/LCD on top of Hardik's V4L2 driver. - Basic functionality of HSUSB Transceiver USB-83320 - TODO: - Camera sensor support - Driver header file inclusion (dependency on ISP-Camera patches) - Some more clean-up may required. Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Manjunath Hadli m...@ti.com Signed-off-by: R Sivaraj siva...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/mach-omap2/Kconfig | 4 + arch/arm/mach-omap2/Makefile | 1 + arch/arm/mach-omap2/board-omap3evm-dc.c | 417 +++ arch/arm/mach-omap2/board-omap3evm-dc.h | 43 arch/arm/mach-omap2/mux.c | 7 + arch/arm/plat-omap/include/mach/mux.h | 4 + 6 files changed, 476 insertions(+), 0 deletions(-) mode change 100644 = 100755 arch/arm/mach-omap2/Kconfig mode change 100644 = 100755 arch/arm/mach-omap2/Makefile create mode 100755 arch/arm/mach-omap2/board-omap3evm-dc.c create mode 100755 arch/arm/mach-omap2/board-omap3evm-dc.h mode change 100644 = 100755 arch/arm/mach-omap2/mux.c mode change 100644 = 100755 arch/arm/plat-omap/include/mach/mux.h diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig old mode 100644 new mode 100755 index ca24a7a..094c97f --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -121,6 +121,10 @@ config MACH_OMAP3EVM bool OMAP 3530 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX +config MACH_OMAP3EVM_DC + bool OMAP 3530 EVM daughter card board + depends on ARCH_OMAP3 ARCH_OMAP34XX MACH_OMAP3EVM + config MACH_OMAP3_BEAGLE bool OMAP3 BEAGLE board depends on ARCH_OMAP3 ARCH_OMAP34XX diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile old mode 100644 new mode 100755 index 3897347..16fa35a --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -60,6 +60,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ usb-musb.o usb-ehci.o \ board-omap3evm-flash.o \ twl4030-generic-scripts.o +obj-$(CONFIG_MACH_OMAP3EVM_DC) += board-omap3evm-dc.o obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \ usb-musb.o usb-ehci.o \ mmc-twl4030.o \ diff --git a/arch/arm/mach-omap2/board-omap3evm-dc.c b/arch/arm/mach-omap2/board-omap3evm-dc.c new file mode 100755 index 000..233c219 --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-dc.c @@ -0,0 +1,417 @@ +/* + * arch/arm/mach-omap2/board-omap3evm-dc.c + * + * Driver for OMAP3 EVM Daughter Card + * + * Copyright (C) 2008 Texas Instruments Inc + * Author: Vaibhav Hiremath hvaib...@ti.com + * + * Contributors: + * Anuj Aggarwal anuj.aggar...@ti.com + * Sivaraj R siva...@ti.com + * + * This package 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + */ + +#include linux/module.h +#include linux/kernel_stat.h +#include linux/init.h +#include linux/i2c.h +#include linux/delay.h +#include linux/spinlock.h +#include linux/clk.h +#include linux/device.h +#include linux/io.h +#include linux/gpio.h + +#include mach/io.h +#include mach/mux.h + +#if defined(CONFIG_VIDEO_TVP514X) || defined(CONFIG_VIDEO_TVP514X_MODULE) +#include linux/videodev2.h +#include media/v4l2-int-device.h +#include media/tvp514x.h +/* include V4L2 camera driver related header file */ +#if defined(CONFIG_VIDEO_OMAP3) ||
RE: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter Card Support
Thanks, Vaibhav Hiremath -Original Message- From: Sriram V [mailto:vshrir...@gmail.com] Sent: Friday, April 17, 2009 5:57 PM To: Hiremath, Vaibhav Cc: video4linux-l...@redhat.com; linux-media@vger.kernel.org Subject: Re: [REVIEW PATCH 2/2] Added OMAP3EVM Multi-Media Daughter Card Support Hi Vaibav, I am using Sergio's patch that was posted on dec12th. I have been trying to apply the mdc driver patches + camera drivers/isp drivers patches related to mdc on sergio's dec 12th patches. They fail to apply at all. I would appreciate if you could send me those patches. [Hiremath, Vaibhav] One thing I am not able to understand is, why you are referring to old code-base. I have refreshed the patches with the latest post from Sakari. Is there any specific reason for this? Can you please provide error log, so that I can directly help you resolving this? Regards, sriram On Wed, Jan 7, 2009 at 11:37 AM, hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com This is first version of OMAP3EVM Mulit-Media Daughter Card support. Tested: - TVP5146 (BT656) decoder interface on top of Sergio's ISP-Camera patches. - Loopback application, capturing image through TVP5146 and displaying it onto the TV/LCD on top of Hardik's V4L2 driver. - Basic functionality of HSUSB Transceiver USB-83320 - TODO: - Camera sensor support - Driver header file inclusion (dependency on ISP-Camera patches) - Some more clean-up may required. Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Manjunath Hadli m...@ti.com Signed-off-by: R Sivaraj siva...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/mach-omap2/Kconfig |4 + arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-omap3evm-dc.c | 417 +++ arch/arm/mach-omap2/board-omap3evm-dc.h | 43 arch/arm/mach-omap2/mux.c |7 + arch/arm/plat-omap/include/mach/mux.h |4 + 6 files changed, 476 insertions(+), 0 deletions(-) mode change 100644 = 100755 arch/arm/mach-omap2/Kconfig mode change 100644 = 100755 arch/arm/mach-omap2/Makefile create mode 100755 arch/arm/mach-omap2/board-omap3evm-dc.c create mode 100755 arch/arm/mach-omap2/board-omap3evm-dc.h mode change 100644 = 100755 arch/arm/mach-omap2/mux.c mode change 100644 = 100755 arch/arm/plat- omap/include/mach/mux.h diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach- omap2/Kconfig old mode 100644 new mode 100755 index ca24a7a..094c97f --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -121,6 +121,10 @@ config MACH_OMAP3EVM bool OMAP 3530 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX +config MACH_OMAP3EVM_DC + bool OMAP 3530 EVM daughter card board + depends on ARCH_OMAP3 ARCH_OMAP34XX MACH_OMAP3EVM + config MACH_OMAP3_BEAGLE bool OMAP3 BEAGLE board depends on ARCH_OMAP3 ARCH_OMAP34XX diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach- omap2/Makefile old mode 100644 new mode 100755 index 3897347..16fa35a --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -60,6 +60,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board- omap3evm.o \ usb-musb.o usb-ehci.o \ board-omap3evm-flash.o \ twl4030-generic- scripts.o +obj-$(CONFIG_MACH_OMAP3EVM_DC) += board-omap3evm-dc.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board- omap3beagle.o \ usb-musb.o usb-ehci.o \ mmc-twl4030.o \ diff --git a/arch/arm/mach-omap2/board-omap3evm-dc.c b/arch/arm/mach-omap2/board-omap3evm-dc.c new file mode 100755 index 000..233c219 --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-dc.c @@ -0,0 +1,417 @@ +/* + * arch/arm/mach-omap2/board-omap3evm-dc.c + * + * Driver for OMAP3 EVM Daughter Card + * + * Copyright (C) 2008 Texas Instruments Inc + * Author: Vaibhav Hiremath hvaib...@ti.com + * + * Contributors: + * Anuj Aggarwal anuj.aggar...@ti.com + * Sivaraj R siva...@ti.com + * + * This package 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Oldrich, On Thu, 9 Apr 2009 21:15:30 +0200, Oldrich Jedlicka wrote: I've tried your patches with AverMedia Cardbus Hybrid (E506R) and they works fine. Thanks for testing and reporting, and sorry for the late answer. My current experience with AverMedia's IR chip (I don't know which one is on the card) is that I2C probing didn't find anything, but it got the chip into some strange state - next operation failed (so that the autodetection on address 0x40 and subaddress 0x0b/0x0d failed). OK, that makes sense. Many I2C devices only support a limited subset of the I2C protocol, and if you try to address them with a message format they don't support, their state machine goes into a bad state. That's probably what was happening there. This is the reason why we should always instantiate I2C devices explicitly when possible: whatever probing method you use, you have no guarantee that every device will like it. The chip at address 0x40 needs the write first (one byte: 0x0b or 0x0d) and immediate read, otherwise it would not respond. The saa7134's I2C 0xfd quirk (actually I would call it a hack :-)) caused failures in communication with the IR chip. I didn't know about this hack. The implementation choice seems wrong to me. The hack should be triggered only when needed, rather than by default with an exception for address 0x40. This goes beyond the scope of my patch though, and I don't want to touch that kind of code without hardware at hand to test my changes. The way I'm doing the IR reading is the same as the Windows driver does - I got the information through the Qemu with pci-proxy patch applied. Thanks, -- 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: [PATCH 6/6] saa7134: Simplify handling of IR on AVerMedia Cardbus
Hi Oldrich,
On Thu, 9 Apr 2009 23:12:51 +0200, Oldrich Jedlicka wrote:
On Saturday 04 of April 2009 at 14:31:37, Jean Delvare wrote:
Now that we instantiate I2C IR devices explicitly, we can skip probing
altogether on boards where the I2C IR device address is known. The
AVerMedia Cardbus are two of these boards.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/saa7134/saa7134-input.c | 35
+++-- 1 file changed, 5 insertions(+), 30 deletions(-)
---
v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-04-04
10:41:44.0 +0200 +++
v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-04-04
10:47:10.0 +0200 @@ -691,22 +691,6 @@ void
saa7134_probe_i2c_ir(struct saa7134
I2C_CLIENT_END
};
- unsigned char subaddr, data;
- struct i2c_msg msg_avermedia[] = { {
- .addr = 0x40,
- .flags = 0,
- .len = 1,
- .buf = subaddr,
- }, {
- .addr = 0x40,
- .flags = I2C_M_RD,
- .len = 1,
- .buf = data,
- } };
-
- struct i2c_client *client;
- int rc;
-
if (disable_ir) {
dprintk(IR has been disabled, not probing for i2c remote\n);
return;
@@ -753,6 +737,10 @@ void saa7134_probe_i2c_ir(struct saa7134
init_data.get_key = get_key_beholdm6xx;
init_data.ir_codes = ir_codes_behold;
break;
+ case SAA7134_BOARD_AVERMEDIA_CARDBUS:
+ case SAA7134_BOARD_AVERMEDIA_CARDBUS_506:
+ info.addr = 0x40;
+ break;
}
The Avermedia Cardbus (E500 - SAA7134_BOARD_AVERMEDIA_CARDBUS) doesn't have
remote control as far as I know. The first model was Cardbus Plus (E501R)
which is not supported (yet), but Grigory Milev reported that it works with
small patching. I plan to send patches after some more testing.
OK, I've removed case SAA7134_BOARD_AVERMEDIA_CARDBUS from my patch,
thanks for letting me know.
--
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
[PATCH] cx18: Fix the handling of i2c bus registration error
* Return actual error values as returned by the i2c subsystem, rather
than 0 or 1.
* If the registration of the second bus fails, unregister the first one
before exiting, otherwise we are leaking resources.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Hans Verkuil hverk...@xs4all.nl
Acked-by: Andy Walls awa...@radix.net
---
Mauro, can you please apply this fix now?
linux/drivers/media/video/cx18/cx18-i2c.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c 2009-03-01
16:09:09.0 +0100
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-03
18:45:18.0 +0200
@@ -214,7 +214,7 @@ static struct i2c_algo_bit_data cx18_i2c
/* init + register i2c algo-bit adapter */
int init_cx18_i2c(struct cx18 *cx)
{
- int i;
+ int i, err;
CX18_DEBUG_I2C(i2c init\n);
for (i = 0; i 2; i++) {
@@ -273,8 +273,18 @@ int init_cx18_i2c(struct cx18 *cx)
cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL,
core, reset, (u32) CX18_GPIO_RESET_I2C);
- return i2c_bit_add_bus(cx-i2c_adap[0]) ||
- i2c_bit_add_bus(cx-i2c_adap[1]);
+ err = i2c_bit_add_bus(cx-i2c_adap[0]);
+ if (err)
+ goto err;
+ err = i2c_bit_add_bus(cx-i2c_adap[1]);
+ if (err)
+ goto err_del_bus_0;
+ return 0;
+
+ err_del_bus_0:
+ i2c_del_adapter(cx-i2c_adap[0]);
+ err:
+ return err;
}
void exit_cx18_i2c(struct cx18 *cx)
--
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: Hauppauge HVR-1500 (aka HP RM436AA#ABA)
I have tried a few different settings, and tired updating the drivers with HG pull, but I just can't get it to work. Glad to hear I am not the only one having problems with this. If you get anywhere let me know what you did, I will try to do likewise. Tom Date: Fri, 17 Apr 2009 04:07:30 -0500 Subject: Hauppauge HVR-1500 (aka HP RM436AA#ABA) From: zenith1...@gmail.com To: linux-media@vger.kernel.org The code compiles. Okay, great. Can anyone actually use this thing in Linux? I can't on my 1-year-old HP dv-6629. Thank you. -- 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 _ Rediscover Hotmail®: Get e-mail storage that grows with you. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Storage2_042009-- 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 6/6] saa7134: Simplify handling of IR on AVerMedia Cardbus
Hi Jean, On Friday 17 of April 2009 at 15:45:20, Jean Delvare wrote: Hi Oldrich, On Thu, 9 Apr 2009 23:12:51 +0200, Oldrich Jedlicka wrote: On Saturday 04 of April 2009 at 14:31:37, Jean Delvare wrote: [sniff] @@ -753,6 +737,10 @@ void saa7134_probe_i2c_ir(struct saa7134 init_data.get_key = get_key_beholdm6xx; init_data.ir_codes = ir_codes_behold; break; + case SAA7134_BOARD_AVERMEDIA_CARDBUS: + case SAA7134_BOARD_AVERMEDIA_CARDBUS_506: + info.addr = 0x40; + break; } The Avermedia Cardbus (E500 - SAA7134_BOARD_AVERMEDIA_CARDBUS) doesn't have remote control as far as I know. The first model was Cardbus Plus (E501R) which is not supported (yet), but Grigory Milev reported that it works with small patching. I plan to send patches after some more testing. OK, I've removed case SAA7134_BOARD_AVERMEDIA_CARDBUS from my patch, thanks for letting me know. You can add SAA7134_BOARD_AVERMEDIA_501 there - if my patch for it get accepted :-) Cheers, Oldrich. -- 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 6/6] saa7134: Simplify handling of IR on AVerMedia Cardbus
On Fri, 17 Apr 2009 18:16:06 +0200, Oldrich Jedlicka wrote: Hi Jean, On Friday 17 of April 2009 at 15:45:20, Jean Delvare wrote: Hi Oldrich, On Thu, 9 Apr 2009 23:12:51 +0200, Oldrich Jedlicka wrote: On Saturday 04 of April 2009 at 14:31:37, Jean Delvare wrote: [sniff] @@ -753,6 +737,10 @@ void saa7134_probe_i2c_ir(struct saa7134 init_data.get_key = get_key_beholdm6xx; init_data.ir_codes = ir_codes_behold; break; + case SAA7134_BOARD_AVERMEDIA_CARDBUS: + case SAA7134_BOARD_AVERMEDIA_CARDBUS_506: + info.addr = 0x40; + break; } The Avermedia Cardbus (E500 - SAA7134_BOARD_AVERMEDIA_CARDBUS) doesn't have remote control as far as I know. The first model was Cardbus Plus (E501R) which is not supported (yet), but Grigory Milev reported that it works with small patching. I plan to send patches after some more testing. OK, I've removed case SAA7134_BOARD_AVERMEDIA_CARDBUS from my patch, thanks for letting me know. You can add SAA7134_BOARD_AVERMEDIA_501 there - if my patch for it get accepted :-) Obviously I can't add it before your own patch is in ;) -- 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: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thu, 16 Apr 2009, Kyle Guinn wrote: On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote: On Thu, 16 Apr 2009, Kyle Guinn wrote: On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote: Hello Theodore kilg...@banach.math.auburn.edu wrote: Also, after the byte indicator for the compression algorithm there are some more bytes, and these almost definitely contain information which could be valuable while doing image processing on the output. If they are already kept and passed out of the module over to libv4lconvert, then it would be very easy to do something with those bytes if it is ever figured out precisely what they mean. But if it is not done now it would have to be done then and would cause even more trouble. I sent it already in private mail to you. Here is the observation I made for the PAC207 SOF some years ago: From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (center) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (edge) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Thomas I've been looking through the frame headers sent by the MR97310A (the Aiptek PenCam VGA+, 08ca:0111). Here are my observations. FF FF 00 FF 96 6x x0 xx xx xx xx xx In binary that looks something like this: 10010110 011001aa a101 All of the values look to be MSbit first. A looks like a 3-bit frame sequence number that seems to start with 1 and increments for each frame. Hmmm. This I never noticed. What you are saying is that the two bytes 6x and x0 are variable? You are sure about that? What I have previously experienced is that the first is always 64 with these cameras, and the second one indicates the absence of compression (in which case it is 0, which of course only arises for still cameras), or if there is data compression then it is not zero. I have never seen this byte to change during a session with a camera. Here is a little table of what I have previously witnessed, and perhaps you can suggest what to do in order to see this is not happening: Camera that byte compression solved, or not streaming Aiptek 00 no N/A no Aiptek 50 yes yes both the Sakar cam 00 no N/A no ditto 50 yes yes both Argus QuikClix 20 yes no doesn't work Argus DC162050 yes yes doesn't work CIF cameras 00 no N/A no ditto 50 yes yes no ditto d0 yes no yes Other strange facts are -- that the Sakar camera, the Argus QuikClix, and the DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of them will stream with the existing driver. The other two go through the motions, but the isoc packets do not actually get sent, so there is no image coming out. I do not understand the reason for this; I have been trying to figure it out and it is rather weird. I should add that, yes, those two cameras were said to be capable of streaming when I bought them. Could it be a problem of age? I don't expect that, but maybe. -- the CIF cameras all share the USB id of 0x93a:0x010e (I bought several of them) and they all are using a different compression algorithm while streaming from what they use if running as still cameras in compressed mode. This leads to the question whether it is possible to set the compression algorithm during the initialization sequence, so that the camera also uses the 0x50 mode while streaming, because we already know how to use that mode. But I have never seen the 0x64 0xX0 bytes used to count the frames. Could you tell me how to repeat that? It certainly would knock down the validity of the above table wouldn't it? I've modified libv4l to print out the 12-byte header before it skips over it. Good idea, and an obvious one. Why did I not think of that? Then when I fire up mplayer it prints out each header as each frame is received. The framerate is only about 5 fps so there isn't a ton of data to parse through. When I point the camera into a light I get this (at 640x480): ... ff ff 00 ff
[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:Fri Apr 17 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11516:6ce311bdeee0 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc1-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-rc1-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-rc1-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc1-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29.1-mips: OK linux-2.6.30-rc1-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: OK linux-2.6.30-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-rc1-x86_64: WARNINGS fw/apps: OK sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS 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/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ioctl VIDIOCGTUNER: Invalid argument ioctl VIDIOCGFBUF: Invalid argument try direct access to /dev/video0 device /dev/video0 open for read ### video4linux device info [/dev/video0] ### general info VIDIOCGCAP name: Camera type: 0x1 [CAPTURE] channels: 1 audios : 0 maxwidth: 356 maxheight : 292 minwidth: 48 minheight : 32 channels VIDIOCGCHAN(0) channel : 0 name: STV06xx tuners : 0 flags : 0x0 [] type: CAMERA norm: 0 tuner audio VIDIOCGAUDIO audio : 0 volume : 0 bass: 0 treble : 0 picture VIDIOCGPICT brightness : 0 hue : 0 colour : 0 contrast: 0 whiteness : 0 depth : 8 palette : unknown buffer window VIDIOCGWIN x : 0 y : 0 width : 356 height : 292 chromakey : 0 flags : 0 ### v4l2 device info [/dev/video0] ### general info VIDIOC_QUERYCAP driver : STV06xx card: Camera bus_info: usb-:00:1d.0-1 version : 2.5.0 capabilities: 0x501 [VIDEO_CAPTURE,READWRITE,STREAMING] standards inputs VIDIOC_ENUMINPUT(0) index : 0 name: STV06xx type: CAMERA audioset: 0 tuner : 0 std : 0x0 [] status : 0x0 [] video capture VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) index : 0 type: VIDEO_CAPTURE flags : 0 description : GRBG pixelformat : 0x47425247 [GRBG] VIDIOC_ENUM_FMT(1,VIDEO_CAPTURE) index : 1 type: VIDEO_CAPTURE flags : 0 description : RGB3 pixelformat : 0x33424752 [RGB3] VIDIOC_ENUM_FMT(2,VIDEO_CAPTURE) index : 2 type: VIDEO_CAPTURE flags : 0 description : BGR3
Re: libv4l release: 0.5.97: the whitebalance release!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: [snip] libv4l-0.5.97 - * Some applications / libs (*cough* gstreamer *cough*) will not work correctly with planar YUV formats when the width is not a multiple of 8, so crop widths which are not a multiple of 8 to the nearest multiple of 8 when converting to planar YUV Could you please elaborate how this is supposed to work, because it doesn't with the gspca_stv06xx driver and a sensor supporting raw bayer and 356x292. Best regards, Erik Get it here: http://people.atrpms.net/~hdegoede/libv4l-0.5.97.tar.gz Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkno2PsACgkQN7qBt+4UG0GdWQCgiHC3jAVJk8znEgAk0cgrt4Cp Tg0AmQEk4TMJG2l3It7vCa9NKHiZg9eM =NEdy -END PGP SIGNATURE- -- 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 0/6] ir-kbd-i2c conversion to the new i2c binding model (v2)
Hi all, Here comes an update of my conversion of ir-kbd-i2c to the new i2c binding model. I've split it into 6 pieces for easier review. Firstly there is 1 preliminary patch: 01-ir-kbd-i2c-dont-abuse-client-name.patch Then 3 patches doing the actual conversion: 02-ir-kbd-i2c-convert-to-new-style.patch 03-configure-ir-receiver.patch 04-ir-kbd-i2c-dont-bind-to-unsupported-devices.patch And lastly 2 patches cleaning up saa7134-input thanks to the new possibilities offered by the conversion: 04-saa7134-input-cleanup-msi-ir.patch 05-saa7134-input-cleanup-avermedia-cardbus.patch This patch set is against the v4l-dvb repository, but I didn't pay attention to the compatibility issues. I simply build-tested it on 2.6.27 and 2.6.29. This patch set touches many different drivers and I can't test any of them. My only TV card with an IR receiver doesn't make use of ir-kbd-i2c. So I would warmly welcome testers. The more testing my changes can get, the better. And of course I welcome reviews and comments as well. I had to touch many drivers I don't know anything about so it is possible that I missed something. The main difference with my initial patch set is that the ir-kbd-i2c devices are named ir_video instead of ir-kbd. The new name was chosen neutral to make it clear that alternative drivers can bind to these devices if so is the user's desire (lirc comes to mind). Such drivers will need to be updated, but with the legacy binding model going away, that had to happen anyway. I'll post all 6 patches as replies to this post. They can also be temporarily downloaded from: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ Additionally I've put a combined patch there, to make testing easier: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN-ONE.patch But for review the individual patches are much better. Thanks, -- 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
[PATCH 1/6] ir-kbd-i2c: Don't use i2c_client.name for our own needs
In the standard device driver binding model, the name field of
struct i2c_client is used to match devices to their drivers, so we
must stop using it for internal purposes. Define a separate field
in struct IR_i2c as a replacement, and use it.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/cx231xx/cx231xx-input.c |2 +-
linux/drivers/media/video/em28xx/em28xx-cards.c |6 +++---
linux/drivers/media/video/em28xx/em28xx-input.c |2 +-
linux/drivers/media/video/ir-kbd-i2c.c|5 +++--
linux/drivers/media/video/saa7134/saa7134-input.c | 12 ++--
linux/include/media/ir-kbd-i2c.h |1 +
6 files changed, 15 insertions(+), 13 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-input.c
2009-04-08 11:27:31.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-input.c 2009-04-17
12:54:18.0 +0200
@@ -37,7 +37,7 @@ MODULE_PARM_DESC(ir_debug, enable debug
#define i2cdprintk(fmt, arg...) \
if (ir_debug) { \
- printk(KERN_DEBUG %s/ir: fmt, ir-c.name , ## arg); \
+ printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
}
#define dprintk(fmt, arg...) \
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-cards.c
2009-04-17 11:22:56.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-cards.c 2009-04-17
12:54:18.0 +0200
@@ -1948,19 +1948,19 @@ void em28xx_set_ir(struct em28xx *dev, s
case (EM2820_BOARD_TERRATEC_CINERGY_250):
ir-ir_codes = ir_codes_em_terratec;
ir-get_key = em28xx_get_key_terratec;
- snprintf(ir-c.name, sizeof(ir-c.name),
+ snprintf(ir-name, sizeof(ir-name),
i2c IR (EM28XX Terratec));
break;
case (EM2820_BOARD_PINNACLE_USB_2):
ir-ir_codes = ir_codes_pinnacle_grey;
ir-get_key = em28xx_get_key_pinnacle_usb_grey;
- snprintf(ir-c.name, sizeof(ir-c.name),
+ snprintf(ir-name, sizeof(ir-name),
i2c IR (EM28XX Pinnacle PCTV));
break;
case (EM2820_BOARD_HAUPPAUGE_WINTV_USB_2):
ir-ir_codes = ir_codes_hauppauge_new;
ir-get_key = em28xx_get_key_em_haup;
- snprintf(ir-c.name, sizeof(ir-c.name),
+ snprintf(ir-name, sizeof(ir-name),
i2c IR (EM2840 Hauppauge));
break;
case (EM2820_BOARD_MSI_VOX_USB_2):
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-input.c
2009-04-08 11:27:31.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-input.c 2009-04-17
12:54:18.0 +0200
@@ -41,7 +41,7 @@ MODULE_PARM_DESC(ir_debug, enable debug
#define i2cdprintk(fmt, arg...) \
if (ir_debug) { \
- printk(KERN_DEBUG %s/ir: fmt, ir-c.name , ## arg); \
+ printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
}
#define dprintk(fmt, arg...) \
--- v4l-dvb.orig/linux/drivers/media/video/ir-kbd-i2c.c 2009-04-08
11:27:31.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ir-kbd-i2c.c 2009-04-17
12:54:18.0 +0200
@@ -346,6 +346,7 @@ static int ir_attach(struct i2c_adapter
ir-c.adapter = adap;
ir-c.addr= addr;
+ snprintf(ir-c.name, sizeof(ir-c.name), ir-kbd);
i2c_set_clientdata(ir-c, ir);
@@ -419,7 +420,7 @@ static int ir_attach(struct i2c_adapter
}
/* Sets name */
- snprintf(ir-c.name, sizeof(ir-c.name), i2c IR (%s), name);
+ snprintf(ir-name, sizeof(ir-name), i2c IR (%s), name);
ir-ir_codes = ir_codes;
/* register i2c device
@@ -444,7 +445,7 @@ static int ir_attach(struct i2c_adapter
/* init + register input device */
ir_input_init(input_dev, ir-ir, ir_type, ir-ir_codes);
input_dev-id.bustype = BUS_I2C;
- input_dev-name = ir-c.name;
+ input_dev-name = ir-name;
input_dev-phys = ir-phys;
err = input_register_device(ir-input);
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-04-17 11:22:56.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-04-17
12:54:18.0 +0200
@@ -60,7 +60,7 @@ MODULE_PARM_DESC(disable_other_ir, disa
#define dprintk(fmt, arg...) if (ir_debug) \
printk(KERN_DEBUG %s/ir: fmt, dev-name , ## arg)
#define i2cdprintk(fmt, arg...)if (ir_debug) \
- printk(KERN_DEBUG %s/ir: fmt, ir-c.name , ## arg)
+ printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg)
/* Helper functions for RC5 and NEC decoding at GPIO16 or GPIO18 */
static int saa7134_rc5_irq(struct saa7134_dev *dev);
@@ -694,7 +694,7 @@ void saa7134_set_i2c_ir(struct saa7134_d
switch (dev-board) {
case SAA7134_BOARD_PINNACLE_PCTV_110i:
case
[PATCH 2/6] ir-kbd-i2c: Switch to the new-style device binding model
Let card drivers probe for IR receiver devices and instantiate them if
found. Ultimately it would be better if we could stop probing
completely, but I suspect this won't be possible for all card types.
There's certainly room for cleanups. For example, some drivers are
sharing I2C adapter IDs, so they also had to share the list of I2C
addresses being probed for an IR receiver. Now that each driver
explicitly says which addresses should be probed, maybe some addresses
can be dropped from some drivers.
Also, the special cases in saa7134-i2c should probably be handled on a
per-board basis. This would be more efficient and less risky than always
probing extra addresses on all boards. I'll give it a try later.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
Cc: Mike Isely is...@pobox.com
---
linux/drivers/media/video/bt8xx/bttv-i2c.c | 21 +
linux/drivers/media/video/cx231xx/cx231xx-cards.c| 11
linux/drivers/media/video/cx231xx/cx231xx-i2c.c |3
linux/drivers/media/video/cx231xx/cx231xx.h |1
linux/drivers/media/video/cx23885/cx23885-i2c.c | 12 +
linux/drivers/media/video/cx88/cx88-i2c.c| 13 +
linux/drivers/media/video/em28xx/em28xx-cards.c | 20 +
linux/drivers/media/video/em28xx/em28xx-i2c.c|3
linux/drivers/media/video/em28xx/em28xx-input.c |6
linux/drivers/media/video/em28xx/em28xx.h|1
linux/drivers/media/video/ir-kbd-i2c.c | 200 +++---
linux/drivers/media/video/ivtv/ivtv-i2c.c| 31 ++
linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c | 24 ++
linux/drivers/media/video/saa7134/saa7134-i2c.c |3
linux/drivers/media/video/saa7134/saa7134-input.c| 86 ++-
linux/drivers/media/video/saa7134/saa7134.h |1
linux/include/media/ir-kbd-i2c.h |2
17 files changed, 244 insertions(+), 194 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-04-17
14:36:51.0 +0200
+++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-04-17
14:37:54.0 +0200
@@ -405,6 +405,27 @@ int __devinit init_bttv_i2c(struct bttv
}
if (0 == btv-i2c_rc i2c_scan)
do_i2c_scan(btv-c.v4l2_dev.name, btv-i2c_client);
+
+ /* Instantiate the IR receiver device, if present */
+ if (0 == btv-i2c_rc) {
+ struct i2c_board_info info;
+ /* The external IR receiver is at i2c address 0x34 (0x35 for
+ reads). Future Hauppauge cards will have an internal
+ receiver at 0x30 (0x31 for reads). In theory, both can be
+ fitted, and Hauppauge suggest an external overrides an
+ internal.
+
+ That's why we probe 0x1a (~0x34) first. CB
+ */
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x4b, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, ir_video, I2C_NAME_SIZE);
+ i2c_new_probed_device(btv-c.i2c_adap, info, addr_list);
+ }
return btv-i2c_rc;
}
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-cards.c
2009-04-17 14:36:51.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-cards.c 2009-04-17
14:37:54.0 +0200
@@ -282,13 +282,16 @@ static void cx231xx_config_tuner(struct
}
/* --- */
-void cx231xx_set_ir(struct cx231xx *dev, struct IR_i2c *ir)
+void cx231xx_register_i2c_ir(struct cx231xx *dev)
{
- if (disable_ir) {
- ir-get_key = NULL;
+ if (disable_ir)
return;
- }
+ /* REVISIT: instantiate IR device */
+}
+
+void cx231xx_set_ir(struct cx231xx *dev, struct IR_i2c *ir)
+{
/* detect configure */
switch (dev-model) {
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-i2c.c
2009-04-17 14:36:51.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-i2c.c 2009-04-17
14:37:54.0 +0200
@@ -540,6 +540,9 @@ int cx231xx_i2c_register(struct cx231xx_
if (0 == bus-i2c_rc) {
if (i2c_scan)
cx231xx_do_i2c_scan(dev, bus-i2c_client);
+
+ /* Instantiate the IR receiver device, if present */
+ cx231xx_register_i2c_ir(dev);
} else
cx231xx_warn(%s: i2c bus %d register FAILED\n,
dev-name, bus-nr);
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx.h2009-04-17
14:36:51.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx.h 2009-04-17
14:37:54.0 +0200
@@
[PATCH 4/6] ir-kbd-i2c: Don't assume all IR receivers are supported
The code in ir_probe makes the dangerous assumption that all IR
receivers are supported by the driver. The new i2c model makes it
possible for bridge drivers to instantiate IR devices before they are
supported, therefore the ir-kbd-i2c drivers must be made more robust
to not spam the logs or even crash on unsupported IR devices. Simply,
the driver will not bind to the unsupported devices.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Andy Walls awa...@radix.net
---
linux/drivers/media/video/ir-kbd-i2c.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/ir-kbd-i2c.c 2009-04-07
21:35:53.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ir-kbd-i2c.c 2009-04-07
22:49:10.0 +0200
@@ -307,7 +307,7 @@ static void ir_work(struct work_struct *
static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
IR_KEYTAB_TYPE *ir_codes = NULL;
- const char *name;
+ const char *name = NULL;
int ir_type;
struct IR_i2c *ir;
struct input_dev *input_dev;
@@ -389,8 +389,7 @@ static int ir_probe(struct i2c_client *c
ir_codes= ir_codes_avermedia_cardbus;
break;
default:
- /* shouldn't happen */
- printk(DEVNAME : Huh? unknown i2c address (0x%02x)?\n, addr);
+ dprintk(1, DEVNAME : Unsupported i2c address 0x%02x\n, addr);
err = -ENODEV;
goto err_out_free;
}
@@ -405,6 +404,14 @@ static int ir_probe(struct i2c_client *c
ir-get_key = init_data-get_key;
}
+ /* Make sure we are all setup before going on */
+ if (!name || !ir-get_key || !ir_codes) {
+ dprintk(1, DEVNAME : Unsupported device at address 0x%02x\n,
+ addr);
+ err = -ENODEV;
+ goto err_out_free;
+ }
+
/* Sets name */
snprintf(ir-name, sizeof(ir-name), i2c IR (%s), name);
ir-ir_codes = ir_codes;
--
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
[PATCH 5/6] saa7134: Simplify handling of IR on MSI t...@nywhere Plus
Now that we instantiate I2C IR devices explicitly, we can skip probing
altogether on boards where the I2C IR device address is known. The MSI
t...@nywhere Plus is one of these boards.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/saa7134/saa7134-input.c | 28 +++--
1 file changed, 15 insertions(+), 13 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-04-17 14:53:35.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-04-17
15:10:55.0 +0200
@@ -692,9 +692,6 @@ void saa7134_probe_i2c_ir(struct saa7134
I2C_CLIENT_END
};
- const unsigned short addr_list_msi[] = {
- 0x30, I2C_CLIENT_END
- };
struct i2c_msg msg_msi = {
.addr = 0x50,
.flags = I2C_M_RD,
@@ -748,6 +745,15 @@ void saa7134_probe_i2c_ir(struct saa7134
init_data.name = MSI t...@nywhere Plus;
init_data.get_key = get_key_msi_tvanywhere_plus;
init_data.ir_codes = ir_codes_msi_tvanywhere_plus;
+ info.addr = 0x30;
+ /* MSI t...@nywhere Plus controller doesn't seem to
+ respond to probes unless we read something from
+ an existing device. Weird...
+ REVISIT: might no longer be needed */
+ rc = i2c_transfer(dev-i2c_adap, msg_msi, 1);
+ dprintk(KERN_DEBUG probe 0x%02x @ %s: %s\n,
+ msg_msi.addr, dev-i2c_adap.name,
+ (1 == rc) ? yes : no);
break;
case SAA7134_BOARD_HAUPPAUGE_HVR1110:
init_data.name = HVR 1110;
@@ -767,18 +773,14 @@ void saa7134_probe_i2c_ir(struct saa7134
if (init_data.name)
info.platform_data = init_data;
- client = i2c_new_probed_device(dev-i2c_adap, info, addr_list);
- if (client)
+ /* No need to probe if address is known */
+ if (info.addr) {
+ i2c_new_device(dev-i2c_adap, info);
return;
+ }
- /* MSI t...@nywhere Plus controller doesn't seem to
- respond to probes unless we read something from
- an existing device. Weird... */
- rc = i2c_transfer(dev-i2c_adap, msg_msi, 1);
- dprintk(KERN_DEBUG probe 0x%02x @ %s: %s\n,
- msg_msi.addr, dev-i2c_adap.name,
- (1 == rc) ? yes : no);
- client = i2c_new_probed_device(dev-i2c_adap, info, addr_list_msi);
+ /* Address not known, fallback to probing */
+ client = i2c_new_probed_device(dev-i2c_adap, info, addr_list);
if (client)
return;
--
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
DViCO FusionHDTV7 Dual Express and other remotes?
I'm setting up a new MythTV system with a DViCO FusionHDTV7 Dual Express and I was able to figure out how to get the remote working thanks to this wiki page ( http://linuxtv.org/wiki/index.php/Remote_controllers-V4L ). I have found a few quotes by people who believe that only the remote that came with the card will work, but I haven't found anything definitive. So is it possible to use a different remote with the IR Receiver on the card and LIRC? Thanks, Dave -- 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: libv4l release: 0.5.97: the whitebalance release!
On Friday 17 Apr 2009, Hans de Goede wrote: I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a No, no / in the device name. I've tried enabling the logging option in libv4l while running v4l2-ctl -l to list the controls present on each camera but I can't see any significant looking differences in the log other than the the fact the sq905 seems to get many more unsuccessful VIDIOC_QUERYCTRL requests. Unless you have a better idea my next step would be to extend the logging to include the parameters on the VIDIOC_QUERYCTRL ioctls, however my gut feel is that it is related the camera having controls that have CIDs both lower and higher than the ones libv4l adds and libv4l doesn't do anything with the driver returned values if V4L2_CTRL_FLAG_NEXT_CTRL is set. Adam normalize_low_bound (int) : min=0 max=127 step=1 default=0 value=0 whitebalance (bool) : default=1 value=1 normalize (bool) : default=0 value=0 normalize_high_bound (int) : min=128 max=255 step=1 default=255 value=255 brightness (int) : min=0 max=255 step=1 default=4 value=4 exposure (int) : min=5 max=26 step=1 default=5 value=5 auto_gain (bool) : default=1 value=1 gain (int) : min=0 max=31 step=1 default=9 value=9 libv4l2: open: 3 libv4l2: open 3: setting pixelformat to RGB24 VIDIOC_S_FMT app requesting: RGB3 VIDIOC_S_FMT converting from: BA81 request == VIDIOC_S_FMT pixelformat: RGB3 320x240 field: 1 bytesperline: 960 imagesize230400 colorspace: 8, priv: 0 result == 0 libv4l2: open 3: done setting pixelformat request == VIDIOC_QUERYCAP result == 0 request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_G_CTRL result == 0 request == VIDIOC_QUERYCTRL result == 0
rtl2830 based freecom dvb-t card
Hi!
I have a Freecom DVB-T USB Stick around, ht has a RTL2830, a MT2060F and a
CY7C68013A-56LFXC, the card is exaxply like the Freecom DVB-T 14aa:0225 on
http://www.bttv-gallery.de/ but changes vendor, mine shows 14ff:0225 also
the same as Yakumo QuickStick Basic DVB-T on
http://www.svethardware.cz/art_doc-68A7D8BB854EBE54C125723F007253B1.html
The only difference I appreciated between my card and the ones on those two
webs is that by the PCB version number they show 0618 on bigger but thinner
numbers while mine shows 0634.
I tried to add my usb ids to the driver at
http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2 but it looks like my first
approach is wrong, as I get the driver to load when I insert the card but
it does nothing.
This is the diff I made when I tried to add this card id to the driver:
diff -r -u rtl2831-r2-c7564e1397d3/linux/drivers/media/dvb/rtl2831/rtd2830u.c
rtl2831-r2-c7564e1397d3.mio/linux/drivers/media/dvb/rtl2831/rtd2830u.c
--- rtl2831-r2-c7564e1397d3/linux/drivers/media/dvb/rtl2831/rtd2830u.c
2009-03-05 21:01:32.0 +0100
+++ rtl2831-r2-c7564e1397d3.mio/linux/drivers/media/dvb/rtl2831/rtd2830u.c
2009-04-17 21:31:49.0 +0200
@@ -382,6 +382,7 @@
{USB_DEVICE(USB_VID_COMPRO, USB_PID_COMPRO_WARM)},
{USB_DEVICE(USB_VID_VESTEL, USB_PID_VESTEL_WARM)},
{USB_DEVICE(USB_VID_FREECOM, USB_PID_FREECOM_WARM)},
+ {USB_DEVICE(USB_VID_FREECOM_2, USB_PID_FREECOM_WARM_2)},
{0},
};
@@ -449,6 +450,10 @@
.cold_ids = {NULL, NULL},
.warm_ids = {rtd2831u_usb_table[10], NULL},
},
+ {.name = Freecom USB 2.0 DVB-T Device,
+.cold_ids = {NULL, NULL},
+.warm_ids = {rtd2831u_usb_table[11], NULL},
+},
{NULL},
}
};
diff -r -u rtl2831-r2-c7564e1397d3/linux/drivers/media/dvb/rtl2831/rtd2831u.h
rtl2831-r2-c7564e1397d3.mio/linux/drivers/media/dvb/rtl2831/rtd2831u.h
--- rtl2831-r2-c7564e1397d3/linux/drivers/media/dvb/rtl2831/rtd2831u.h
2009-03-05 21:01:32.0 +0100
+++ rtl2831-r2-c7564e1397d3.mio/linux/drivers/media/dvb/rtl2831/rtd2831u.h
2009-04-17 18:11:02.0 +0200
@@ -65,6 +65,9 @@
#defineUSB_VID_FREECOM 0x14AA
#defineUSB_PID_FREECOM_WARM0x0160
+#defineUSB_VID_FREECOM_2 0x14FF
+#defineUSB_PID_FREECOM_WARM_2 0x0225
+
#define RTD2831_URB_SIZE 4096
#define RTD2831_URB_NUMBER 7
Can somebody please tell me what should I add to test if this card is
supported with this driver?
In case it means something here is the lsusb -v for the card:
Bus 001 Device 002: ID 14ff:0225
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize064
idVendor 0x14ff
idProduct 0x0225
bcdDevice0.00
iManufacturer 0
iProduct0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 171
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 1
bNumEndpoints 6
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type
Re: [PATCH 2/6] ir-kbd-i2c: Switch to the new-style device binding model
I thought we were going to leave the pvrusb2 driver out of this since I've already got a change ready that also includes additional logic to take into account the properties of the hardware device (i.e. only activate ir-kbd-i2c when we know it has a chance of working). -Mike On Fri, 17 Apr 2009, Jean Delvare wrote: Let card drivers probe for IR receiver devices and instantiate them if found. Ultimately it would be better if we could stop probing completely, but I suspect this won't be possible for all card types. There's certainly room for cleanups. For example, some drivers are sharing I2C adapter IDs, so they also had to share the list of I2C addresses being probed for an IR receiver. Now that each driver explicitly says which addresses should be probed, maybe some addresses can be dropped from some drivers. Also, the special cases in saa7134-i2c should probably be handled on a per-board basis. This would be more efficient and less risky than always probing extra addresses on all boards. I'll give it a try later. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Hans Verkuil hverk...@xs4all.nl Cc: Andy Walls awa...@radix.net Cc: Mike Isely is...@pobox.com --- linux/drivers/media/video/bt8xx/bttv-i2c.c | 21 + linux/drivers/media/video/cx231xx/cx231xx-cards.c| 11 linux/drivers/media/video/cx231xx/cx231xx-i2c.c |3 linux/drivers/media/video/cx231xx/cx231xx.h |1 linux/drivers/media/video/cx23885/cx23885-i2c.c | 12 + linux/drivers/media/video/cx88/cx88-i2c.c| 13 + linux/drivers/media/video/em28xx/em28xx-cards.c | 20 + linux/drivers/media/video/em28xx/em28xx-i2c.c|3 linux/drivers/media/video/em28xx/em28xx-input.c |6 linux/drivers/media/video/em28xx/em28xx.h|1 linux/drivers/media/video/ir-kbd-i2c.c | 200 +++--- linux/drivers/media/video/ivtv/ivtv-i2c.c| 31 ++ linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c | 24 ++ linux/drivers/media/video/saa7134/saa7134-i2c.c |3 linux/drivers/media/video/saa7134/saa7134-input.c| 86 ++- linux/drivers/media/video/saa7134/saa7134.h |1 linux/include/media/ir-kbd-i2c.h |2 17 files changed, 244 insertions(+), 194 deletions(-) [...] -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: RFC on proposed patches to mr97310a.c for gspca and v4l
On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
I've been looking through the frame headers sent by the MR97310A (the
Aiptek PenCam VGA+, 08ca:0111). Here are my observations.
FF FF 00 FF 96 6x x0 xx xx xx xx xx
In binary that looks something like this:
10010110 011001aa a101
All of the values look to be MSbit first. A looks like a 3-bit frame
sequence number that seems to start with 1 and increments for each
frame.
Hmmm. This I never noticed. What you are saying is that the two bytes 6x
and x0 are variable? You are sure about that? What I have previously
experienced is that the first is always 64 with these cameras, and the
second one indicates the absence of compression (in which case it is 0,
which of course only arises for still cameras), or if there is data
compression then it is not zero. I have never seen this byte to change
during a session with a camera. Here is a little table of what I have
previously witnessed, and perhaps you can suggest what to do in order to
see this is not happening:
Camera that byte compression solved, or not
streaming
Aiptek 00 no N/A no
Aiptek 50 yes yes both
the Sakar cam 00 no N/A no
ditto 50 yes yes both
Argus QuikClix 20 yes no doesn't work
Argus DC1620 50 yes yes doesn't work
CIF cameras00 no N/A no
ditto 50 yes yes no
ditto d0 yes no yes
Other strange facts are
-- that the Sakar camera, the Argus QuikClix, and the
DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of
them will stream with the existing driver. The other two go through the
motions, but the isoc packets do not actually get sent, so there is no
image coming out. I do not understand the reason for this; I have been
trying to figure it out and it is rather weird. I should add that, yes,
those two cameras were said to be capable of streaming when I bought
them. Could it be a problem of age? I don't expect that, but maybe.
-- the CIF cameras all share the USB id of 0x93a:0x010e (I bought
several of them) and they all are using a different compression
algorithm while streaming from what they use if running as still cameras
in compressed mode. This leads to the question whether it is possible to
set the compression algorithm during the initialization sequence, so
that the camera also uses the 0x50 mode while streaming, because we
already know how to use that mode.
But I have never seen the 0x64 0xX0 bytes used to count the frames.
Could you tell me how to repeat that? It certainly would knock down the
validity of the above table wouldn't it?
I've modified libv4l to print out the 12-byte header before it skips over
it.
Good idea, and an obvious one. Why did I not think of that?
Then when I fire up mplayer it prints out each header as each frame is
received. The framerate is only about 5 fps so there isn't a ton of data
to parse through. When I point the camera into a light I get this (at
640x480):
...
ff ff 00 ff 96 64 d0 c1 5c c6 00 00
ff ff 00 ff 96 65 50 c1 5c c6 00 00
ff ff 00 ff 96 65 d0 c1 5c c6 00 00
ff ff 00 ff 96 66 50 c1 5c c6 00 00
ff ff 00 ff 96 66 d0 c1 5c c6 00 00
ff ff 00 ff 96 67 50 c1 5c c6 00 00
ff ff 00 ff 96 67 d0 c1 5c c6 00 00
ff ff 00 ff 96 64 50 c1 5c c6 00 00
ff ff 00 ff 96 64 d0 c1 5c c6 00 00
ff ff 00 ff 96 65 50 c1 5c c6 00 00
...
Which camera is this? Is it the Aiptek Pencam VGA+? If so, then I can try
it, too, because I also have one of them.
Yes, that's the one. Try your others if you can and let me know what happens.
Only those 3 bits change, and it looks like a counter to me. Take a look
at the gspca-mars (MR97113A?) subdriver. I think it tries to accommodate
the frame sequence number when looking for the SOF.
No, I don't see that, sorry. What I see is that it looks for the SOF,
which is declared in pac_common.h to be the well-known FF FF 00 FF 96 and
no more bytes after that.
I'm talking about this code from gspca/mars.c. Look in sd_pkt_scan().
if (data[0 + p] == 0xff
data[1 + p] == 0xff
data[2 + p] == 0x00
data[3 + p] == 0xff
data[4 + p] == 0x96) {
if (data[5 + p] == 0x64
|| data[5 + p] == 0x65
|| data[5 + p] == 0x66
|| data[5 + p] == 0x67) {
-Kyle
--
To unsubscribe from this
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Fri, 17 Apr 2009, Kyle Guinn wrote:
On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
snip
ff ff 00 ff 96 64 d0 c1 5c c6 00 00
ff ff 00 ff 96 65 50 c1 5c c6 00 00
ff ff 00 ff 96 65 d0 c1 5c c6 00 00
ff ff 00 ff 96 66 50 c1 5c c6 00 00
ff ff 00 ff 96 66 d0 c1 5c c6 00 00
ff ff 00 ff 96 67 50 c1 5c c6 00 00
ff ff 00 ff 96 67 d0 c1 5c c6 00 00
ff ff 00 ff 96 64 50 c1 5c c6 00 00
ff ff 00 ff 96 64 d0 c1 5c c6 00 00
ff ff 00 ff 96 65 50 c1 5c c6 00 00
...
Which camera is this? Is it the Aiptek Pencam VGA+? If so, then I can try
it, too, because I also have one of them.
Yes, that's the one. Try your others if you can and let me know what happens.
OK. I will.
Only those 3 bits change, and it looks like a counter to me. Take a look
at the gspca-mars (MR97113A?) subdriver. I think it tries to accommodate
the frame sequence number when looking for the SOF.
No, I don't see that, sorry. What I see is that it looks for the SOF,
which is declared in pac_common.h to be the well-known FF FF 00 FF 96 and
no more bytes after that.
I'm talking about this code from gspca/mars.c. Look in sd_pkt_scan().
if (data[0 + p] == 0xff
data[1 + p] == 0xff
data[2 + p] == 0x00
data[3 + p] == 0xff
data[4 + p] == 0x96) {
if (data[5 + p] == 0x64
|| data[5 + p] == 0x65
|| data[5 + p] == 0x66
|| data[5 + p] == 0x67) {
Ah, so: mars.c not mr97310a.c
You lost me, there, for a minute. Yes, this sequence is there.
Thanks,
Theodore Kilgore
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
