Re: [PATCH] media: add support to gspca/pac7302.c for 093a:2627 (Genius FaceCam 300)
Acked-by: Márton Németh nm...@freemail.hu Jozsef Marton wrote: From: Jozsef Marton jmar...@users.sourceforge.net gspca_pac7302 module supports the webcam with usb id: 093a:2627. It is a Genius FaceCam 300. The module does not need any changes but listing the usb id along with a vertical flip flag. The included patch adds this to the module source. Signed-off-by: Jozsef Marton jmar...@users.sourceforge.net --- diff -uprN -X dontdiff linux-3.4-rc7-vanilla/Documentation/video4linux/gspca.txt linux-3.4-rc7/Documentation/video4linux/gspca.txt --- linux-3.4-rc7-vanilla/Documentation/video4linux/gspca.txt 2012-05-13 03:37:47.0 +0200 +++ linux-3.4-rc7/Documentation/video4linux/gspca.txt 2012-05-15 16:56:55.603514846 +0200 @@ -276,6 +276,7 @@ pac7302 093a:2622 Genius Eye 312 pac7302 093a:2624 PAC7302 pac7302 093a:2625 Genius iSlim 310 pac7302 093a:2626 Labtec 2200 +pac7302 093a:2627 Genius FaceCam 300 pac7302 093a:2628 Genius iLook 300 pac7302 093a:2629 Genious iSlim 300 pac7302 093a:262a Webcam 300k diff -uprN -X dontdiff linux-3.4-rc7-vanilla/drivers/media/video/gspca/pac7302.c linux-3.4-rc7/drivers/media/video/gspca/pac7302.c --- linux-3.4-rc7-vanilla/drivers/media/video/gspca/pac7302.c 2012-05-13 03:37:47.0 +0200 +++ linux-3.4-rc7/drivers/media/video/gspca/pac7302.c 2012-05-15 15:15:03.355624405 +0200 @@ -940,6 +940,7 @@ static const struct usb_device_id device {USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP}, {USB_DEVICE(0x093a, 0x2625)}, {USB_DEVICE(0x093a, 0x2626)}, + {USB_DEVICE(0x093a, 0x2627), .driver_info = FL_VFLIP}, {USB_DEVICE(0x093a, 0x2628)}, {USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP}, {USB_DEVICE(0x093a, 0x262a)}, -- 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] v4l2: handle multiplication overflow
Mauro Carvalho Chehab írta: Em 22-12-2011 07:42, Németh Márton escreveu: From: Márton Németh nm...@freemail.hu When a V4L2 ioctl is executed the memory provided by the caller in user space is copied to the kernel space in video_usercopy() function. To find out how many bytes has to be copied the check_array_args() helper function is used. This patch adds a check for multiplication overflow. Without this check the multiplication may overflow resulting array_size to be zero. This means that later on uninitialized value can trigger NULL pointer exception. The overflow happens because ctrls-count is an __u32 multiplied by a constant coming from sizeof() operator. Multiplication result of two 32bit value may be a 64bit value, thus overflow can happen. Similarly buf-length is an __u32 multiplied by a constant coming from sizeof() operator. The chosen error value is -ENOMEM because we are just about to allocate kernel memory to copy data from userspace. We cannot even store the required number of bytes in the variable of size_t type. To trigger the error from user space use the v4l-test 0.19 [1] or essentially the following code fragment: struct v4l2_ext_controls controls; memset(controls, 0, sizeof(controls)); controls.ctrl_class = V4L2_CTRL_CLASS_USER; controls.count = 0x4000; controls.controls = NULL; ret = ioctl(f, VIDIOC_G_EXT_CTRLS, controls); References: [1] v4l-test: Test environment for Video For Linux Two (V4L2) API http://v4l-test.sourceforge.net/ Signed-off-by: Márton Németh nm...@freemail.hu --- I'm a little bit in doubt whether this is the correct way to check for the multiplication overflow. In case of x86 architecture the MUL insruction [2] can be used to multiply EAX with an other 32bit register, and the 64bit result is placed to EDX:EAX. In case of EDX != 0 the carry and overflow flags are set. This means that executing the MUL instruction on x86 already provides information whether the result fits to 32bit or not. I might use __u64 as a result of the multiplication and check whether the upper 32bit is still zero but the optimal would be to check for the carry or the overflow flag. Still, there could be a special case when the constant from sizeof() operator is a power of 2, in this case the compiler might optimize the multiplication using a shift left. In this case something else is needed. I couldn't really find information about the number of bits for size_t on different architectures. If size_t happens to be at least 64bit on some architecture then this overflow will not happen at all and the array_size will contain the correct value. What do you think? Hi Németh, IMO, the check should, instead, use a max hard limit for the array size. There's no sense on allowing very large arrays there. I think that this patch become obsoleted by this one, already merged: Yes, that merged patch is simple and based on real-world practical limits and also solves the overflow problem. commit 6c06108be53ca5e94d8b0e93883d534dd9079646 Author: Dan Carpenter dan.carpen...@oracle.com Date: Thu Jan 5 02:27:57 2012 -0300 [media] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy() If ctrls-count is too high the multiplication could overflow and array_size would be lower than expected. Mauro and Hans Verkuil suggested that we cap it at 1024. That comes from the maximum number of controls with lots of room for expantion. $ grep V4L2_CID include/linux/videodev2.h | wc -l 211 Cc: stable sta...@vger.kernel.org Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index e1da8fc..639abee 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -2226,6 +2226,10 @@ static int check_array_args(unsigned int cmd, void *parg, size_t *array_size, struct v4l2_ext_controls *ctrls = parg; if (ctrls-count != 0) { + if (ctrls-count V4L2_CID_MAX_CTRLS) { + ret = -EINVAL; + break; + } *user_ptr = (void __user *)ctrls-controls; *kernel_ptr = (void *)ctrls-controls; *array_size = sizeof(struct v4l2_ext_control) diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index 6bfaa76..b2e1331 100644 --- a/include/linux/videodev2.h +++ b/include/linux/videodev2.h @@ -1132,6 +1132,7 @@ struct v4l2_querymenu { #define V4L2_CTRL_FLAG_NEXT_CTRL 0x8000 /* User-class control IDs defined by V4L2 */ +#define V4L2_CID_MAX_CTRLS 1024 #define V4L2_CID_BASE(V4L2_CTRL_CLASS_USER | 0x900) #define
[PATCH] v4l2: handle multiplication overflow
From: Márton Németh nm...@freemail.hu When a V4L2 ioctl is executed the memory provided by the caller in user space is copied to the kernel space in video_usercopy() function. To find out how many bytes has to be copied the check_array_args() helper function is used. This patch adds a check for multiplication overflow. Without this check the multiplication may overflow resulting array_size to be zero. This means that later on uninitialized value can trigger NULL pointer exception. The overflow happens because ctrls-count is an __u32 multiplied by a constant coming from sizeof() operator. Multiplication result of two 32bit value may be a 64bit value, thus overflow can happen. Similarly buf-length is an __u32 multiplied by a constant coming from sizeof() operator. The chosen error value is -ENOMEM because we are just about to allocate kernel memory to copy data from userspace. We cannot even store the required number of bytes in the variable of size_t type. To trigger the error from user space use the v4l-test 0.19 [1] or essentially the following code fragment: struct v4l2_ext_controls controls; memset(controls, 0, sizeof(controls)); controls.ctrl_class = V4L2_CTRL_CLASS_USER; controls.count = 0x4000; controls.controls = NULL; ret = ioctl(f, VIDIOC_G_EXT_CTRLS, controls); References: [1] v4l-test: Test environment for Video For Linux Two (V4L2) API http://v4l-test.sourceforge.net/ Signed-off-by: Márton Németh nm...@freemail.hu --- I'm a little bit in doubt whether this is the correct way to check for the multiplication overflow. In case of x86 architecture the MUL insruction [2] can be used to multiply EAX with an other 32bit register, and the 64bit result is placed to EDX:EAX. In case of EDX != 0 the carry and overflow flags are set. This means that executing the MUL instruction on x86 already provides information whether the result fits to 32bit or not. I might use __u64 as a result of the multiplication and check whether the upper 32bit is still zero but the optimal would be to check for the carry or the overflow flag. Still, there could be a special case when the constant from sizeof() operator is a power of 2, in this case the compiler might optimize the multiplication using a shift left. In this case something else is needed. I couldn't really find information about the number of bits for size_t on different architectures. If size_t happens to be at least 64bit on some architecture then this overflow will not happen at all and the array_size will contain the correct value. What do you think? References: [2] Intel 80386 Reference Programmer's Manual MUL -- Unsigned Multiplication of AL or AX http://www.scs.stanford.edu/nyu/04fa/lab/i386/MUL.htm --- diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index e1da8fc..e239be8 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -2200,6 +2200,7 @@ static int check_array_args(unsigned int cmd, void *parg, size_t *array_size, void * __user *user_ptr, void ***kernel_ptr) { int ret = 0; + size_t size; switch (cmd) { case VIDIOC_QUERYBUF: @@ -2214,8 +2215,15 @@ static int check_array_args(unsigned int cmd, void *parg, size_t *array_size, } *user_ptr = (void __user *)buf-m.planes; *kernel_ptr = (void *)buf-m.planes; - *array_size = sizeof(struct v4l2_plane) * buf-length; - ret = 1; + size = sizeof(struct v4l2_plane) * buf-length; + if (unlikely(size buf-length)) { + /* *array_size overflowed at multiplication */ + *array_size = 0; + ret = -ENOMEM; + } else { + *array_size = size; + ret = 1; + } } break; } @@ -2228,9 +2236,15 @@ static int check_array_args(unsigned int cmd, void *parg, size_t *array_size, if (ctrls-count != 0) { *user_ptr = (void __user *)ctrls-controls; *kernel_ptr = (void *)ctrls-controls; - *array_size = sizeof(struct v4l2_ext_control) - * ctrls-count; - ret = 1; + size = sizeof(struct v4l2_ext_control) * ctrls-count; + if (unlikely(size ctrls-count)) { + /* *array_size overflowed at multiplication */ + *array_size = 0; + ret = -ENOMEM; + } else { + *array_size = size; + ret = 1; +
Re: pac7311
Lars Noschinski wrote: * Németh Márton nm...@freemail.hu [11-10-18 22:14]: Hi Lars, Lars Noschinski wrote: I'm using a webcam (Philipps SPC500NC) which identifies itself as 093a:2603 Pixart Imaging, Inc. PAC7312 Camera and is sort-of supported by the gspca_pac7311 module. sort-of because the image alternates quickly between having a red tint or a green tint (using the gspac driver from kernel 3.0.0, but this problem is present since at least 2.6.31). The most important source code for your webcam is drivers/media/video/gspca/pac7311.c . You can see it online at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/media/video/gspca/pac7311.c . If I remove and re-plugin the camera a few times (on average around 3 times), the colors are stable. When you plug and remove the webcam and the colors are wrong, do you get any message in the dmesg? I get the same messages; sometimes the order of the messages output by uhci_hcd ehci_hcd differs, but this seems to be unrelated to working/not working. Once the colors are stable and you unplug and replug the webcam, what happens then? Is there again around 3 times when the webcam is not working properly? I now did a longer series of unplugreplug: Over the time, status stable colors seemed to get more probable. After a while, it only falls back to alternating colors, when I unplug it for a longer time (say 10 seconds). Might be a hardware problem? You might want to try the same webcam on different USB port to exclude the connector problem on the computer. I don't know if you have the possibility to try the webcam on a completly different computer also. Then a second issue becomes apparent: There is almost no saturation in the image. Toying around with Contrast, Gamma, Exposure or Gain does not help. What _does_ help is the Vflip switch: If I enable it, the image is flipped vertically (as expected), but also the color become a lot better. Is there any difference when you use the Mirror control? What about the combination of the Vflip and Mirror controls? Vflip and (Vflip and Mirror) change color; Mirror alone does not. What about the Auto Gain setting? Is it enabled or disabled in your case? Auto Gain is enabled; but colors also change if it is disabled Is there something I can do to debug/fix this problem? You can try testing the webcam with different resolutions. The webcam supports 160x120, 320x240 and 640x480 resolutions based on the source code. You can try the different resolutions for example with cheese ( http://projects.gnome.org/cheese/ ) or any of your favorite V4L2 program. This does not seem to make a difference; except that 160x120 is listed, but does not seem to be available. guvcview tells me: Checking video mode 640x480@32bpp : OK setting new resolution (320 x 240) checking format: 859981650 Checking video mode 320x240@32bpp : OK setting new resolution (160 x 120) checking format: 859981650 Checking video mode 160x120@32bpp : OK ioctl (-1067952623) retried 4 times - giving up: Die Ressource ist zur Zeit nicht verfügbar) VIDIOC_DQBUF - Unable to dequeue buffer : Die Ressource ist zur Zeit nicht verfügbar Error grabbing image (the last message is then repeated, till i change the resolution) [Also, since I switched to 160x120, cheese crashes with a segfault, without giving me the possibility to switch back and I cannot find the config file.] You can try running cheese using the command line strace -f cheese to see what was the last system call before the crash. If you have the debug symbols installed for cheese then you can also try running gdb cheese. Once you get the (gdb) prompt enter the command run. Switch to 160x120 resolution. When cheese crashes you should get (gdb) prompt again. Execute bt (backtrace) and send the result. You can load the usbmon kernel module and use Wireshark to log the USB communication between your computer and the webcam starting with plug-in. You can compare the communication when the webcam starts to work correctly with the one when the webcam doesn't work as expected. I'll try to do this later this week. Greetings, Lars Noschinski -- 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: pac7311
Hi Lars, Lars Noschinski wrote: I'm using a webcam (Philipps SPC500NC) which identifies itself as 093a:2603 Pixart Imaging, Inc. PAC7312 Camera and is sort-of supported by the gspca_pac7311 module. sort-of because the image alternates quickly between having a red tint or a green tint (using the gspac driver from kernel 3.0.0, but this problem is present since at least 2.6.31). The most important source code for your webcam is drivers/media/video/gspca/pac7311.c . You can see it online at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/media/video/gspca/pac7311.c . If I remove and re-plugin the camera a few times (on average around 3 times), the colors are stable. When you plug and remove the webcam and the colors are wrong, do you get any message in the dmesg? Once the colors are stable and you unplug and replug the webcam, what happens then? Is there again around 3 times when the webcam is not working properly? Then a second issue becomes apparent: There is almost no saturation in the image. Toying around with Contrast, Gamma, Exposure or Gain does not help. What _does_ help is the Vflip switch: If I enable it, the image is flipped vertically (as expected), but also the color become a lot better. Is there any difference when you use the Mirror control? What about the combination of the Vflip and Mirror controls? What about the Auto Gain setting? Is it enabled or disabled in your case? Is there something I can do to debug/fix this problem? You can try testing the webcam with different resolutions. The webcam supports 160x120, 320x240 and 640x480 resolutions based on the source code. You can try the different resolutions for example with cheese ( http://projects.gnome.org/cheese/ ) or any of your favorite V4L2 program. You can load the usbmon kernel module and use Wireshark to log the USB communication between your computer and the webcam starting with plug-in. You can compare the communication when the webcam starts to work correctly with the one when the webcam doesn't work as expected. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gspca: video0 becomes video1 after ISOC data error
Hi, I'm running Debian with Linux 2.6.38-2-486 on a computer. I have a hama AC-150 webcam attached to this computer. The webcam works continouosly and I use mencoder to do some cropping and transformation and to encode the video stream to a file. When I plug the device the following appears in the dmesg: [439884.692090] usb 3-1: new full speed USB device using uhci_hcd and address 6 [439884.841721] usb 3-1: New USB device found, idVendor=0c45, idProduct=6142 [439884.841958] usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [439884.842153] usb 3-1: Product: USB camera [439884.851327] gspca: probing 0c45:6142 [439884.856694] sonixj: Sonix chip id: 12 [439884.942767] sonixj: Sensor po2030n [439884.947226] input: sonixj as /devices/pci:00/:00:0b.0/usb3/3-1/input/input4 [439884.968553] gspca: video0 created The camera works and sometimes the following messages appear in dmesg: [2992914.118137] gspca: ISOC data error: [3] len=0, status=-84 [3020511.187726] gspca: ISOC data error: [16] len=0, status=-84 [3071235.051448] gspca: ISOC data error: [22] len=0, status=-84 [3178268.392602] gspca: ISOC data error: [11] len=0, status=-84 [3195506.149353] gspca: ISOC data error: [14] len=0, status=-84 [3200576.757068] gspca: ISOC data error: [13] len=0, status=-84 [3242983.446235] gspca: ISOC data error: [20] len=0, status=-84 [3242983.446406] gspca: ISOC data error: [21] len=0, status=-84 [3242983.446526] gspca: ISOC data error: [22] len=0, status=-84 [3242983.446638] gspca: ISOC data error: [23] len=0, status=-84 [3242983.468410] gspca: ISOC data error: [0] len=0, status=-84 [3242983.468578] gspca: ISOC data error: [1] len=0, status=-84 [3242983.468709] gspca: ISOC data error: [2] len=0, status=-84 [3242983.468827] gspca: ISOC data error: [3] len=0, status=-84 ... [3242983.579375] gspca: ISOC data error: [22] len=0, status=-84 [3242983.579375] gspca: ISOC data error: [23] len=0, status=-84 [3242983.588379] gspca: URB error -84, resubmitting [3242983.591697] usb 3-1: USB disconnect, address 6 [3242983.592489] gspca: ISOC data error: [0] len=0, status=-84 [3242983.592630] gspca: ISOC data error: [1] len=0, status=-84 [3242983.592744] gspca: ISOC data error: [2] len=0, status=-84 [3242983.592856] gspca: ISOC data error: [3] len=0, status=-84 ... [3242983.594935] gspca: ISOC data error: [22] len=0, status=-84 [3242983.595044] gspca: ISOC data error: [23] len=0, status=-84 [3242983.595149] gspca: usb_submit_urb() ret -19 [3242983.602605] gspca: video0 disconnect [3242983.899568] usb 3-1: new full speed USB device using uhci_hcd and address 7 [3242984.077146] usb 3-1: New USB device found, idVendor=0c45, idProduct=6142 [3242984.077375] usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [3242984.077563] usb 3-1: Product: USB camera [3242984.096020] gspca: probing 0c45:6142 [3242984.117655] sonixj: Sonix chip id: 12 [3242984.221778] sonixj: Sensor po2030n [3242984.249883] input: sonixj as /devices/pci:00/:00:0b.0/usb3/3-1/input/input5 [3242984.258533] gspca: video1 created At this point the user space application (mencoder) still have the /dev/video0 device open but the video0 device is no longer there. Instead the video1 is created. I already saw similar behaviour in case of suspend-resume cycle, see Bug 13419 - gspca: /dev/video0 changes to /dev/video1 after suspend https://bugzilla.kernel.org/show_bug.cgi?id=13419 The error code -84 refers to EILSEQ (Illegal byte sequence) according to include/asm-generic/errno.h . What could be the reason for ISO data error? I guess the video0 is disconnected as part of error recovery. In this case, however the video1 device is created so the user space application looses the original video streaming device. Is this how it shall work? Regards, Márton Németh -- 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 RFC] gspca_sonixj: handle return values from USB subsystem
Hi, Jean-Francois Moine írta: On Sun, 17 Oct 2010 16:45:03 +0200 Németh Márton nm...@freemail.hu wrote: The usb_control_msg() may return error at any time so it is necessary to handle it. The error handling mechanism is taken from the pac7302. The resulting driver was tested with hama AC-150 webcam (USB ID 0c45:6142). Hi Németh, This mechanism has already been done by commit 60f44336 in media_tree.git branch staging/v2.6.37. I must looking at totally wrong place for my base of changes. Now I see the branch staging/v2.6.37, thanks for the hint. Márton Németh -- 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/2] gspca_sonixj: add hardware vertical flip support for hama AC-150
Hi Jean-Francois, Jean-Francois Moine wrote: On Sun, 17 Oct 2010 13:08:01 +0200 Németh Márton nm...@freemail.hu wrote: The PO2030N sensor chip found in hama AC-150 webcam supports vertical flipping the image by hardware. Add support for this in the gspca_sonixj driver also. [snip] The driver sonixj has changed in staging/2.6.37. I join a new version of your patches. May you check it? (when acked, I'll keep you as the author of the change) Looks good. It was a bit tricky for me sometimes to understand the changes together with the V4L/DVB: gspca - main: New video control mechanism (commit ccbfd092a4199a6fba17273c11c1e0b340d91eb5), but still looks good. One small thing: the title of the patch shall be changed because this version contains horizontal and vertical flip also. Note that I could not run the new driver, yet, together with hama AC-150, but I hope you could already try whether the new feature is working correctly. Márton Németh -- 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 2/2] gspca_sonixj: add hardware horizontal flip support for hama AC-150
From: Márton Németh nm...@freemail.hu The PO2030N sensor chip found in hama AC-150 webcam supports horizontal flipping the image by hardware. Add support for this in the gspca_sonixj driver also. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -upr c/drivers/media/video/gspca/sonixj.c d/drivers/media/video/gspca/sonixj.c --- c/drivers/media/video/gspca/sonixj.c2010-10-17 12:08:12.0 +0200 +++ d/drivers/media/video/gspca/sonixj.c2010-10-17 12:28:41.0 +0200 @@ -46,6 +46,7 @@ struct sd { u8 red; u8 gamma; u8 vflip; /* ov7630/ov7648/po2030n only */ + u8 hflip; /* po2030n only */ u8 sharpness; u8 infrared;/* mt9v111 only */ u8 freq;/* ov76xx only */ @@ -104,6 +105,8 @@ static int sd_setautogain(struct gspca_d static int sd_getautogain(struct gspca_dev *gspca_dev, __s32 *val); static int sd_setvflip(struct gspca_dev *gspca_dev, __s32 val); static int sd_getvflip(struct gspca_dev *gspca_dev, __s32 *val); +static int sd_sethflip(struct gspca_dev *gspca_dev, __s32 val); +static int sd_gethflip(struct gspca_dev *gspca_dev, __s32 *val); static int sd_setsharpness(struct gspca_dev *gspca_dev, __s32 val); static int sd_getsharpness(struct gspca_dev *gspca_dev, __s32 *val); static int sd_setinfrared(struct gspca_dev *gspca_dev, __s32 val); @@ -235,7 +238,22 @@ static const struct ctrl sd_ctrls[] = { .set = sd_setvflip, .get = sd_getvflip, }, -#define SHARPNESS_IDX 8 +#define HFLIP_IDX 8 + { + { + .id = V4L2_CID_HFLIP, + .type= V4L2_CTRL_TYPE_BOOLEAN, + .name= Hflip, + .minimum = 0, + .maximum = 1, + .step= 1, +#define HFLIP_DEF 0 + .default_value = HFLIP_DEF, + }, + .set = sd_sethflip, + .get = sd_gethflip, + }, +#define SHARPNESS_IDX 9 { { .id = V4L2_CID_SHARPNESS, @@ -251,7 +269,7 @@ static const struct ctrl sd_ctrls[] = { .get = sd_getsharpness, }, /* mt9v111 only */ -#define INFRARED_IDX 9 +#define INFRARED_IDX 10 { { .id = V4L2_CID_INFRARED, @@ -267,7 +285,7 @@ static const struct ctrl sd_ctrls[] = { .get = sd_getinfrared, }, /* ov7630/ov7648/ov7660 only */ -#define FREQ_IDX 10 +#define FREQ_IDX 11 { { .id = V4L2_CID_POWER_LINE_FREQUENCY, @@ -289,41 +307,52 @@ static const __u32 ctrl_dis[] = { [SENSOR_ADCM1700] =(1 AUTOGAIN_IDX) | (1 INFRARED_IDX) | (1 VFLIP_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), [SENSOR_GC0307] = (1 INFRARED_IDX) | (1 VFLIP_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), [SENSOR_HV7131R] = (1 INFRARED_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), [SENSOR_MI0360] = (1 INFRARED_IDX) | (1 VFLIP_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), [SENSOR_MO4000] = (1 INFRARED_IDX) | (1 VFLIP_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), [SENSOR_MT9V111] = (1 VFLIP_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), [SENSOR_OM6802] = (1 INFRARED_IDX) | (1 VFLIP_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), -[SENSOR_OV7630] = (1 INFRARED_IDX), +[SENSOR_OV7630] = (1 INFRARED_IDX) | + (1 HFLIP_IDX), -[SENSOR_OV7648] = (1 INFRARED_IDX), +[SENSOR_OV7648] = (1 INFRARED_IDX) | + (1 HFLIP_IDX), [SENSOR_OV7660] = (1 AUTOGAIN_IDX) | (1 INFRARED_IDX) | - (1 VFLIP_IDX), + (1 VFLIP_IDX) | + (1 HFLIP_IDX), [SENSOR_PO1030] = (1 AUTOGAIN_IDX) | (1 INFRARED_IDX) | (1 VFLIP_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), [SENSOR_PO2030N] = (1 AUTOGAIN_IDX) | @@ -332,11 +361,13 @@ static const __u32 ctrl_dis[] = { [SENSOR_SOI768] = (1 AUTOGAIN_IDX) | (1 INFRARED_IDX) | (1 VFLIP_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), [SENSOR_SP80708] = (1 AUTOGAIN_IDX) | (1 INFRARED_IDX) | (1 VFLIP_IDX) | + (1 HFLIP_IDX) | (1 FREQ_IDX), };
[PATCH 1/2] gspca_sonixj: add hardware vertical flip support for hama AC-150
From: Márton Németh nm...@freemail.hu The PO2030N sensor chip found in hama AC-150 webcam supports vertical flipping the image by hardware. Add support for this in the gspca_sonixj driver also. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -upr b/drivers/media/video/gspca/sonixj.c c/drivers/media/video/gspca/sonixj.c --- b/drivers/media/video/gspca/sonixj.c2010-10-17 11:22:33.0 +0200 +++ c/drivers/media/video/gspca/sonixj.c2010-10-17 12:08:12.0 +0200 @@ -45,7 +45,7 @@ struct sd { u8 blue; u8 red; u8 gamma; - u8 vflip; /* ov7630/ov7648 only */ + u8 vflip; /* ov7630/ov7648/po2030n only */ u8 sharpness; u8 infrared;/* mt9v111 only */ u8 freq;/* ov76xx only */ @@ -219,7 +219,7 @@ static const struct ctrl sd_ctrls[] = { .set = sd_setautogain, .get = sd_getautogain, }, -/* ov7630/ov7648 only */ +/* ov7630/ov7648/po2030n only */ #define VFLIP_IDX 7 { { @@ -328,7 +328,6 @@ static const __u32 ctrl_dis[] = { [SENSOR_PO2030N] = (1 AUTOGAIN_IDX) | (1 INFRARED_IDX) | - (1 VFLIP_IDX) | (1 FREQ_IDX), [SENSOR_SOI768] = (1 AUTOGAIN_IDX) | (1 INFRARED_IDX) | @@ -2136,7 +2135,7 @@ static void setautogain(struct gspca_dev sd-ag_cnt = -1; } -/* hv7131r/ov7630/ov7648 only */ +/* hv7131r/ov7630/ov7648/po2030n only */ static void setvflip(struct sd *sd) { u8 comn; @@ -2156,6 +2155,20 @@ static void setvflip(struct sd *sd) comn |= 0x80; i2c_w1(sd-gspca_dev, 0x75, comn); break; + case SENSOR_PO2030N: + /* Reg. 0x1E: Timing Generator Control Register 2 (Tgcontrol2) +* (reset value: 0x0A) +* bit7: HM: Horizontal Mirror: 0: disable, 1: enable +* bit6: VM: Vertical Mirror: 0: disable, 1: enable +* bit5: ST: Shutter Selection: 0: electrical, 1: mechanical +* bit4: FT: Single Frame Transfer: 0: disable, 1: enable +* bit3-0: X +*/ + comn = 0x0A; + if (sd-vflip) + comn |= 0x40; + i2c_w1(sd-gspca_dev, 0x1E, comn); + break; default: /* case SENSOR_OV7648: */ comn = 0x06; -- 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] gspca_sonixj: remove magic numbers for delay
From: Márton Németh nm...@freemail.hu The number 0xdd is used for marking delay init sequence steps. Replace 0xdd values only if the meaning is delay. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -upr a/drivers/media/video/gspca/sonixj.c b/drivers/media/video/gspca/sonixj.c --- a/drivers/media/video/gspca/sonixj.c2010-10-17 10:51:26.0 +0200 +++ b/drivers/media/video/gspca/sonixj.c2010-10-17 11:22:33.0 +0200 @@ -572,20 +572,23 @@ static const u8 reg84[] = { 0x3e, 0x00, 0xcd, 0x0f, 0xf7, 0x0f, /* VR VG VB */ 0x00, 0x00, 0x00/* YUV offsets */ }; + +#define DELAY 0xdd + static const u8 adcm1700_sensor_init[][8] = { {0xa0, 0x51, 0xfe, 0x00, 0x00, 0x00, 0x00, 0x10}, {0xb0, 0x51, 0x04, 0x08, 0x00, 0x00, 0x00, 0x10}, /* reset */ - {0xdd, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, + {DELAY, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, {0xb0, 0x51, 0x04, 0x00, 0x00, 0x00, 0x00, 0x10}, - {0xdd, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, + {DELAY, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, {0xb0, 0x51, 0x0c, 0xe0, 0x2e, 0x00, 0x00, 0x10}, {0xb0, 0x51, 0x10, 0x02, 0x02, 0x00, 0x00, 0x10}, {0xb0, 0x51, 0x14, 0x0e, 0x0e, 0x00, 0x00, 0x10}, {0xb0, 0x51, 0x1c, 0x00, 0x80, 0x00, 0x00, 0x10}, {0xb0, 0x51, 0x20, 0x01, 0x00, 0x00, 0x00, 0x10}, - {0xdd, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, + {DELAY, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, {0xb0, 0x51, 0x04, 0x04, 0x00, 0x00, 0x00, 0x10}, - {0xdd, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, + {DELAY, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, {0xb0, 0x51, 0x04, 0x01, 0x00, 0x00, 0x00, 0x10}, {0xa0, 0x51, 0xfe, 0x10, 0x00, 0x00, 0x00, 0x10}, {0xb0, 0x51, 0x14, 0x01, 0x00, 0x00, 0x00, 0x10}, @@ -629,7 +632,7 @@ static const u8 gc0307_sensor_init[][8] {0xa0, 0x21, 0x0e, 0x02, 0x00, 0x00, 0x00, 0x10}, {0xa0, 0x21, 0x0f, 0xb2, 0x00, 0x00, 0x00, 0x10}, {0xa0, 0x21, 0x12, 0x70, 0x00, 0x00, 0x00, 0x10}, - {0xdd, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /*delay 10ms*/ + {DELAY, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /*delay 10ms*/ {0xa0, 0x21, 0x13, 0x00, 0x00, 0x00, 0x00, 0x10}, {0xa0, 0x21, 0x15, 0xb8, 0x00, 0x00, 0x00, 0x10}, {0xa0, 0x21, 0x16, 0x13, 0x00, 0x00, 0x00, 0x10}, @@ -772,7 +775,7 @@ static const u8 mo4000_sensor_init[][8] }; static const u8 mt9v111_sensor_init[][8] = { {0xb1, 0x5c, 0x0d, 0x00, 0x01, 0x00, 0x00, 0x10}, /* reset? */ - {0xdd, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ + {DELAY, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ {0xb1, 0x5c, 0x0d, 0x00, 0x00, 0x00, 0x00, 0x10}, {0xb1, 0x5c, 0x01, 0x00, 0x01, 0x00, 0x00, 0x10}, /* IFP select */ {0xb1, 0x5c, 0x08, 0x04, 0x80, 0x00, 0x00, 0x10}, /* output fmt ctrl */ @@ -860,10 +863,10 @@ static const u8 om6802_sensor_param1[][8 static const u8 ov7630_sensor_init[][8] = { {0xa1, 0x21, 0x76, 0x01, 0x00, 0x00, 0x00, 0x10}, {0xa1, 0x21, 0x12, 0xc8, 0x00, 0x00, 0x00, 0x10}, - {0xdd, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ + {DELAY, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ {0xa1, 0x21, 0x12, 0x48, 0x00, 0x00, 0x00, 0x10}, {0xa1, 0x21, 0x12, 0xc8, 0x00, 0x00, 0x00, 0x10}, - {0xdd, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ + {DELAY, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ {0xa1, 0x21, 0x12, 0x48, 0x00, 0x00, 0x00, 0x10}, /* win: i2c_r from 00 to 80 */ {0xd1, 0x21, 0x03, 0x80, 0x10, 0x20, 0x80, 0x10}, @@ -917,7 +920,7 @@ static const u8 ov7630_sensor_param1[][8 static const u8 ov7648_sensor_init[][8] = { {0xa1, 0x21, 0x76, 0x00, 0x00, 0x00, 0x00, 0x10}, {0xa1, 0x21, 0x12, 0x80, 0x00, 0x00, 0x00, 0x10}, /* reset */ - {0xdd, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ + {DELAY, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ {0xa1, 0x21, 0x12, 0x00, 0x00, 0x00, 0x00, 0x10}, {0xd1, 0x21, 0x03, 0xa4, 0x30, 0x88, 0x00, 0x10}, {0xb1, 0x21, 0x11, 0x80, 0x08, 0x00, 0x00, 0x10}, @@ -966,7 +969,7 @@ static const u8 ov7648_sensor_param1[][8 static const u8 ov7660_sensor_init[][8] = { {0xa1, 0x21, 0x12, 0x80, 0x00, 0x00, 0x00, 0x10}, /* reset SCCB */ - {0xdd, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ + {DELAY, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}, /* delay 20ms */ {0xa1, 0x21, 0x12, 0x05, 0x00, 0x00, 0x00, 0x10}, /* Outformat = rawRGB */ {0xa1, 0x21, 0x13, 0xb8, 0x00, 0x00, 0x00, 0x10}, /* init COM8 */ @@ -1062,7 +1065,7 @@ static const u8 ov7660_sensor_param1[][8 static const u8
Re: em28xx in v4l-dvb destroyed my USB TV card
Hi, Marius Bjørnstad wrote: A problem with the em28xx driver was brought up in June by Thorsten Hirsch: http://www.spinics.net/lists/linux-media/msg20588.html . I also have a TerraTec Cinergy Hybrid T USB XS. When I used my device with Linux, it would take a long time to be recognised by the OS, and this would get worse. At this point, the device is not recognised, and almost completely dead. When I plug it in, I get errors like - Oct 17 14:34:55 muon kernel: [ 7111.324875] hub 1-1:1.0: unable to enumerate USB device on port 2 Oct 17 14:34:55 muon kernel: [ 7111.580618] hub 1-1:1.0: unable to enumerate USB device on port 2 Oct 17 14:34:55 muon kernel: [ 7111.840481] hub 1-1:1.0: unable to enumerate USB device on port 2 Oct 17 14:34:55 muon kernel: [ 7112.092358] hub 1-1:1.0: unable to enumerate USB device on port 2 -- and these keep coming until the device is removed. The device is also not available in windows. The unable to enumerate USB device on port ... error message usually means that the USB hardware what you connect itself is damaged. At that time the v4l-dvb driver is not yet started, only the low level USB enumeration is running. It is also possible that the USB cable causes the problem, if any. I had an USB device which had wrong soldering and that one gave the same error message. That device was degraded as time passed. You might want to try the device on different USB port, different USB cable, or even on different computer to see exactly which hardware component is not working properly. Márton Németh -- 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 RFC] gspca_sonixj: handle return values from USB subsystem
From: Márton Németh nm...@freemail.hu The usb_control_msg() may return error at any time so it is necessary to handle it. The error handling mechanism is taken from the pac7302. The resulting driver was tested with hama AC-150 webcam (USB ID 0c45:6142). Signed-off-by: Márton Németh nm...@freemail.hu --- diff -upr d/drivers/media/video/gspca/sonixj.c e/drivers/media/video/gspca/sonixj.c --- d/drivers/media/video/gspca/sonixj.c2010-10-17 12:28:41.0 +0200 +++ e/drivers/media/video/gspca/sonixj.c2010-10-17 16:28:38.0 +0200 @@ -1359,29 +1359,45 @@ static const u8 (*sensor_init[])[8] = { static void reg_r(struct gspca_dev *gspca_dev, u16 value, int len) { + int ret; + #ifdef GSPCA_DEBUG if (len USB_BUF_SZ) { err(reg_r: buffer overflow); return; } #endif - usb_control_msg(gspca_dev-dev, + if (gspca_dev-usb_err 0) + return; + ret = usb_control_msg(gspca_dev-dev, usb_rcvctrlpipe(gspca_dev-dev, 0), 0, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_INTERFACE, value, 0, gspca_dev-usb_buf, len, 500); - PDEBUG(D_USBI, reg_r [%02x] - %02x, value, gspca_dev-usb_buf[0]); + if (ret 0) { + PDEBUG(D_ERR, reg_r(): + Failed to read %i registers from to 0x%x, error %i, + len, value, ret); + gspca_dev-usb_err = ret; + } else { + PDEBUG(D_USBI, reg_r [%02x] - %02x, + value, gspca_dev-usb_buf[0]); + } } static void reg_w1(struct gspca_dev *gspca_dev, u16 value, u8 data) { + int ret; + + if (gspca_dev-usb_err 0) + return; PDEBUG(D_USBO, reg_w1 [%04x] = %02x, value, data); gspca_dev-usb_buf[0] = data; - usb_control_msg(gspca_dev-dev, + ret = usb_control_msg(gspca_dev-dev, usb_sndctrlpipe(gspca_dev-dev, 0), 0x08, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_INTERFACE, @@ -1389,12 +1405,22 @@ static void reg_w1(struct gspca_dev *gsp 0, gspca_dev-usb_buf, 1, 500); + if (ret 0) { + PDEBUG(D_ERR, reg_w1(): + Failed to write register to 0x%x, error %i, + value, ret); + gspca_dev-usb_err = ret; + } } static void reg_w(struct gspca_dev *gspca_dev, u16 value, const u8 *buffer, int len) { + int ret; + + if (gspca_dev-usb_err 0) + return; PDEBUG(D_USBO, reg_w [%04x] = %02x %02x .., value, buffer[0], buffer[1]); #ifdef GSPCA_DEBUG @@ -1404,20 +1430,29 @@ static void reg_w(struct gspca_dev *gspc } #endif memcpy(gspca_dev-usb_buf, buffer, len); - usb_control_msg(gspca_dev-dev, + ret = usb_control_msg(gspca_dev-dev, usb_sndctrlpipe(gspca_dev-dev, 0), 0x08, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_INTERFACE, value, 0, gspca_dev-usb_buf, len, 500); + if (ret 0) { + PDEBUG(D_ERR, reg_w(): + Failed to write %i registers to 0x%x, error %i, + len, value, ret); + gspca_dev-usb_err = ret; + } } /* I2C write 1 byte */ static void i2c_w1(struct gspca_dev *gspca_dev, u8 reg, u8 val) { struct sd *sd = (struct sd *) gspca_dev; + int ret; + if (gspca_dev-usb_err 0) + return; PDEBUG(D_USBO, i2c_w1 [%02x] = %02x, reg, val); switch (sd-sensor) { case SENSOR_ADCM1700: @@ -1436,7 +1471,7 @@ static void i2c_w1(struct gspca_dev *gsp gspca_dev-usb_buf[5] = 0; gspca_dev-usb_buf[6] = 0; gspca_dev-usb_buf[7] = 0x10; - usb_control_msg(gspca_dev-dev, + ret = usb_control_msg(gspca_dev-dev, usb_sndctrlpipe(gspca_dev-dev, 0), 0x08, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_INTERFACE, @@ -1444,22 +1479,37 @@ static void i2c_w1(struct gspca_dev *gsp 0, gspca_dev-usb_buf, 8, 500); + if (ret 0) { + PDEBUG(D_ERR, i2c_w1(): Failed to write + I2C register 0x%x, value 0x%X, error %i, + reg, val, ret); + gspca_dev-usb_err = ret; + } } /* I2C write 8 bytes */ static void i2c_w8(struct gspca_dev *gspca_dev, const u8 *buffer)
Re: Old patches sent via the Mailing list
Mauro Carvalho Chehab wrote: == Gspca patches - Waiting Hans de Goede hdego...@redhat.com review == Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown packet received http://patchwork.kernel.org/patch/75837 Németh Márton nm...@freemail.hu This was NACKed by Hans de Goede, as the pachwork link shows. Please drop it. Márton Németh -- 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
mem2mem_testdev: BUG: unable to handle kernel NULL pointer dereference
Hi, I tried the mem2mem_testdev driver from Linux kernel 2.6.35-rc3 together with the test environment from http://v4l-test.sourceforge.net . I found that the VIDIOC_G_FMT ioctl may result in a NULL pointer dereference in kernel. I derived a simple test case which I also attached. Steps to reproduce: $ su # modprobe mem2mem-testdev # exit $ gcc -Wall -Wextra -O2 test_mem2mem.c -o test_mem2mem $ ./test_mem2mem I investigated the problem a little bit and found that the expression q_data-fmt-fourcc in function vidioc_g_fmt() may cause this behaviour. Regards, Márton Németh /* * Simple test case for VIDIOC_G_FMT. Derived from * v4l-test, http://v4l-test.sourceforge.net * * Writen by Márton Németh nm...@freemail.hu * 20 Jun 2010 * Released under GPL. */ #include stdio.h #include sys/types.h #include sys/stat.h #include fcntl.h #include unistd.h #include sys/ioctl.h #include errno.h #include string.h #include unistd.h #include linux/videodev2.h #include linux/errno.h int main() { int f; int ret; int ret_get, errno_get; struct v4l2_format format; f = open(/dev/video0, O_RDWR); if (f 0) { perror(Cannot open /dev/video0); return 1; } memset(format, 0xff, sizeof(format)); format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; printf(Calling VIDIOC_G_FMT ioctl...\n); fflush(stdout); ret_get = ioctl(f, VIDIOC_G_FMT, format); errno_get = errno; printf(VIDIOC_G_FMT: ret=%i, errno=%i\n, ret_get, errno_get); ret = close(f); f = 0; if (ret 0) { perror(Cannot close); return 1; } return 0; } [0.00] Linux version 2.6.35-rc3 (nma...@europa) (gcc version 4.4.4 (Debian 4.4.4-5) ) #2 PREEMPT Sat Jun 19 14:34:39 CEST 2010 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000d8000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3bf7 (usable) [0.00] BIOS-e820: 3bf7 - 3bf7a000 (ACPI data) [0.00] BIOS-e820: 3bf7a000 - 3bf8 (ACPI NVS) [0.00] BIOS-e820: 3bf8 - 4000 (reserved) [0.00] BIOS-e820: fffe - 0001 (reserved) [0.00] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel! [0.00] DMI present. [0.00] e820 update range: - 1000 (usable) == (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] last_pfn = 0x3bf70 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-D3FFF write-protect [0.00] D4000-D7FFF uncachable [0.00] D8000-DBFFF write-protect [0.00] DC000-D write-back [0.00] E-E3FFF uncachable [0.00] E4000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FFC000 write-back [0.00] 1 base 003C00 mask FFFC00 uncachable [0.00] 2 base 00E000 mask FFF000 write-combining [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] initial memory mapped : 0 - 0100 [0.00] found SMP MP-table at [c00f6870] f6870 [0.00] init_memory_mapping: -377fe000 [0.00] 00 - 40 page 4k [0.00] 40 - 003740 page 2M [0.00] 003740 - 00377fe000 page 4k [0.00] kernel direct mapping tables up to 377fe000 @ 7000-c000 [0.00] ACPI: RSDP 000f68d0 00014 (v00 PTLTD ) [0.00] ACPI: RSDT 3bf7600b 00030 (v01 PTLTDRSDT 0604 LTP ) [0.00] ACPI: FACP 3bf79e87 00074 (v01 AMDK8 PTLTW0604 PTL_ 000F4240) [0.00] ACPI: DSDT 3bf7603b 03E4C (v01 VIA PTL_ACPI 0604 MSFT 010E) [0.00] ACPI: FACS 3bf7afc0 00040 [0.00] ACPI: SSDT 3bf79efb 000B5 (v01 PTLTD POWERNOW 0604 LTP 0001) [0.00] ACPI: APIC 3bf79fb0 00050 (v01 PTLTD ? APIC 0604 LTP ) [0.00] ACPI: Local APIC address 0xfee0 [0.00] 71MB HIGHMEM available. [0.00] 887MB LOWMEM available. [0.00] mapped low ram: 0 - 377fe000 [0.00] low ram: 0 - 377fe000 [0.00] Zone PFN ranges: [0.00] DMA 0x0001 - 0x1000 [0.00] Normal 0x1000 - 0x000377fe [0.00] HighMem 0x000377fe - 0x0003bf70 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0: 0x0001 - 0x009f [0.00] 0: 0x0100 - 0x0003bf70 [0.00] On node 0
Re: genius islim 310 webcam test
Hi Sergei, thanks for the report. Hi Jean-Francois, I got this report about a working Genius iSlim 310 webcam. Maybe it would be a good idea to add the device 0x093a:0x2625 in pac7302.c. Should I send a patch for you? Regards, Márton Németh Krivchikov Sergei wrote: Hi! All works. From: http://forum.ubuntu.ru/index.php?topic=9767.msg717310#msg717310 and http://stemp.wordpress.com/2009/11/03/karmic-get-the-latest-drivers-for-gspca-uvc-usbvideo-and-other/ |1. sudo aptitude install mercurial build-essential linux-headers libncurses5-dev ||2. hg clone http://linuxtv.org/hg/v4l-dvb/ ||3. cd v4l-dvb 4. Add to | v4l-dvb/linux/drivers/media/video/gspca/pac7302.c in section /* -- module initialisation -- */ static const struct usb_device_id device_table[] __devinitconst = { {USB_DEVICE(0x06f8, 0x3009)}, {USB_DEVICE(0x093a, 0x2620)}, {USB_DEVICE(0x093a, 0x2621)}, {USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP}, {USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP}, * {USB_DEVICE(0x093a, 0x2625)}*, {USB_DEVICE(0x093a, 0x2626)}, {USB_DEVICE(0x093a, 0x2628)}, {USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP}, {USB_DEVICE(0x093a, 0x262a)}, {USB_DEVICE(0x093a, 0x262c)}, {} }; |5. sudo cp /boot/config-`uname -r` v4l/.config| |6. sudo make menuconfig| Set M in Multimedia Support - Video Capture adapters - V4L USB devices - GSPCA - pac7302.c and Uncheck all other devices if you want. |7. make 8. sudo make install| Thanks! -- 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] gspca_pac7302: add Genius iSlim 310
From: Márton Németh nm...@freemail.hu Add Genius iSlim 310 webcam to the supported list of the PAC7302 driver. For more information see http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302 . Signed-off-by: Márton Németh nm...@freemail.hu --- diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index f13eb03..f9b9d32 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -253,6 +253,7 @@ pac7302 093a:2620 Apollo AC-905 pac7302093a:2621 PAC731x pac7302093a:2622 Genius Eye 312 pac7302093a:2624 PAC7302 +pac7302093a:2625 Genius iSlim 310 pac7302093a:2626 Labtec 2200 pac7302093a:2628 Genius iLook 300 pac7302093a:2629 Genious iSlim 300 diff --git a/drivers/media/video/gspca/pac7302.c b/drivers/media/video/gspca/pac7302.c index 2a68220..7c0f265 100644 --- a/drivers/media/video/gspca/pac7302.c +++ b/drivers/media/video/gspca/pac7302.c @@ -1200,6 +1200,7 @@ static const struct usb_device_id device_table[] __devinitconst = { {USB_DEVICE(0x093a, 0x2621)}, {USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP}, {USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP}, + {USB_DEVICE(0x093a, 0x2625)}, {USB_DEVICE(0x093a, 0x2626)}, {USB_DEVICE(0x093a, 0x2628)}, {USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP}, -- 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: genius islim 310 webcam test
Jean-Francois Moine írta: On Wed, 31 Mar 2010 07:56:59 +0200 Németh Márton nm...@freemail.hu wrote: The next thing is that you need to learn how to compile the Linux kernel from source code. There is a description for Ubuntu at https://help.ubuntu.com/community/Kernel/Compile . After you are able to compile and install your new kernel, you can try to apply the patch in this email, recompile the kernel, install the kernel and the modules, unload the gspca_pac7302 kernel module (rmmod gspca_pac7302), and then plug the webcam in order it can load the new kernel module. When you were successful with these steps you'll see new messages in the output of dmesg command. Please send this output also. Hello Németh and Sergei, I think the patch is not needed because it just gives the vend:prod which is already known by lsusb. To avoid misunderstandings, the patch I sent is not just printing the USB vendor ID and product ID but also really enables the pac7302 gspca subdriver to actually work with the newly added USB IDs. On the other hand, compiling a full kernel is not needed with a small tarball distribution as the one I have in my page (actual gspca-2.9.10). This is also a possible way to go, the important thing is that a kernel module has to be built and the previous version of gspca_pac7302 kernel module has to be replaced with the newly built one. Regards, Márton Németh -- 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: genius islim 310 webcam test
Hello Sergei, Krivchikov Sergei wrote: Hi! I have a Genius iSlim 310 webcam and linux ubuntu 9.10 kernel 2.6.31. My developer level under linux - beginner (very beginner) :) but i'm ready to test this webcam undr linux. But I need the instructions:) How was your success in the launch of this webcam under Linux? Sincerely, Sergei Krivchikov. Currently the Genius iSlim 310 webcam is not supported by the mainline Linux kernel, but I think that the support can be added very easily. See the description at http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302 why. First thing what I'll need that you connect your Genius iSlim 310 to the Linux box, open an xterm and send the output of lsusb command. Then we can find out the USB ID of the device. Also, please send the output of dmesg. The easiest way to do this is to redirect the standard output to a file like this: dmesg dmesg.txt and then send the created file as an attachment. The next thing is that you need to learn how to compile the Linux kernel from source code. There is a description for Ubuntu at https://help.ubuntu.com/community/Kernel/Compile . After you are able to compile and install your new kernel, you can try to apply the patch in this email, recompile the kernel, install the kernel and the modules, unload the gspca_pac7302 kernel module (rmmod gspca_pac7302), and then plug the webcam in order it can load the new kernel module. When you were successful with these steps you'll see new messages in the output of dmesg command. Please send this output also. Finally, what you will also need is that the libv4l-0 package of Ubuntu ( http://packages.ubuntu.com/intrepid/libv4l-0 ) is installed on your computer. This package you may have already installed. These are the main points. Let's see how far you can proceed. Let me know if you need further assistance. Regards, Márton Németh --- From: Márton Németh nm...@freemail.hu On the schematics in PixArt PAC7301/PAC7302 datasheet (http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf) pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes the possible product ID range 0x2620..0x262f. In this range there are some known webcams, however, there are some PIDs with unknown or future devices. Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is probable that this driver will work correctly independent of the used PID. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r dfa82cf98a85 linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Sat Jan 30 20:03:02 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 31 11:08:21 2010 +0100 @@ -96,6 +96,7 @@ u8 flags; #define FL_HFLIP 0x01 /* mirrored by default */ #define FL_VFLIP 0x02 /* vertical flipped by default */ +#define FL_EXPERIMENTAL 0x80 /* USB IDs based on heuristic without any known product */ u8 sof_read; u8 autogain_ignore_frames; @@ -1220,17 +1221,33 @@ }; /* -- module initialisation -- */ +/* Note on FL_EXPERIMENTAL: + * On the schematics in PixArt PAC7301/PAC7302 datasheet + * (http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf) + * pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes + * the possible product ID range 0x2620..0x262f. In this range there are some + * known webcams, however, there are some PIDs with unknown or future devices. + * Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is + * probable that this driver will work correctly independent of the used PID. + */ static const struct usb_device_id device_table[] __devinitconst = { {USB_DEVICE(0x06f8, 0x3009)}, {USB_DEVICE(0x093a, 0x2620)}, {USB_DEVICE(0x093a, 0x2621)}, {USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP}, + {USB_DEVICE(0x093a, 0x2623), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP}, + {USB_DEVICE(0x093a, 0x2625), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x2626)}, + {USB_DEVICE(0x093a, 0x2627), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x2628)}, {USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP}, {USB_DEVICE(0x093a, 0x262a)}, + {USB_DEVICE(0x093a, 0x262b), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x262c)}, + {USB_DEVICE(0x093a, 0x262d), .driver_info = FL_EXPERIMENTAL }, + {USB_DEVICE(0x093a, 0x262e), .driver_info = FL_EXPERIMENTAL }, + {USB_DEVICE(0x093a, 0x262f), .driver_info = FL_EXPERIMENTAL }, {} }; MODULE_DEVICE_TABLE(usb, device_table); @@ -1239,6 +1256,17 @@ static int __devinit sd_probe(struct usb_interface *intf, const struct usb_device_id *id) { + if ((u8)id-driver_info FL_EXPERIMENTAL) { + PDEBUG(D_ERR | D_PROBE, WARNING: USB device ID
Re: problem compiling modoule mt9t031 in current v4l-dvb-hg
Hi, Halim Sahin wrote: Hi Folks, I was not able to build v4l-dvb from hg (checked out today). /root/work/v4l-dvb/v4l/mt9t031.c:729: error: unknown field 'runtime_suspend' specified in initializer /root/work/v4l-dvb/v4l/mt9t031.c:730: error: unknown field 'runtime_resume' specified in initializer /root/work/v4l-dvb/v4l/mt9t031.c:730: warning: initialization from incompatible pointer type make[3]: *** [/root/work/v4l-dvb/v4l/mt9t031.o] Error 1 make[2]: *** [_module_/root/work/v4l-dvb/v4l] Error 2 make[1]: *** [default] Fehler 2 make: *** [all] Fehler 2 Kernel 2.6.31 (x86_64) What is the CONFIG_PM setting in your environment? Regards, Márton Németh -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
Hans Verkuil írta: On Sunday 07 March 2010 13:20:16 Németh Márton wrote: Hello Hans, Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Would you mind adding a new test case for your test environment? This would be a test case with the newest stable kernel without Power Management support (CONFIG_PM not defined in .config). It seems some problem could be caught with this test case. Hmm, it is not that easy to do that. I just use default configs or allyes/allmodconfig. Is this for particular architectures? No, no special architecture is necessary. The idea is that a lot of drivers are using the CONFIG_PM in an '#ifdef' and different code will be compiled when the CONFIG_PM is defined and when it is not defined. Note that I'm working on getting the daily build working for the git tree as well. I'm currently testing my build changes to see if I didn't forget anything. If all goes well then the today's build will support git. Good to hear about this new feature. Regards, Márton Németh -- 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/2] bttv: Move I2C IR initialization
Hi, Jean Delvare wrote: Move I2C IR initialization from just after I2C bus setup to right before non-I2C IR initialization. This avoids the case where an I2C IR device is blocking audio support (at least the PV951 suffers from this). It is also more logical to group IR support together, regardless of the connectivity. Something could have gone wrong because this patch and the patch at http://linuxtv.org/hg/v4l-dvb/rev/659e08177aa3 has the #if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30) and #endif pair at different places. The current result is the following compiler warning: bttv-i2c.c: In function 'init_bttv_i2c': bttv-i2c.c:440: warning: control reaches end of non-void function Regard, Márton Németh This fixes bug #15184: http://bugzilla.kernel.org/show_bug.cgi?id=15184 Signed-off-by: Jean Delvare kh...@linux-fr.org --- As this fixes a regression, I suggest pushing to Linus quickly. This is a candidate for 2.6.32-stable too. linux/drivers/media/video/bt8xx/bttv-driver.c |1 + linux/drivers/media/video/bt8xx/bttv-i2c.c| 10 +++--- linux/drivers/media/video/bt8xx/bttvp.h |1 + 3 files changed, 9 insertions(+), 3 deletions(-) --- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-12-11 09:47:47.0 +0100 +++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-i2c.c2010-02-16 18:14:34.0 +0100 @@ -409,9 +409,14 @@ 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); -#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30) - /* Instantiate the IR receiver device, if present */ + return btv-i2c_rc; +} + +/* Instantiate the I2C IR receiver device, if present */ +void __devinit init_bttv_i2c_ir(struct bttv *btv) +{ +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30) if (0 == btv-i2c_rc) { struct i2c_board_info info; /* The external IR receiver is at i2c address 0x34 (0x35 for @@ -432,7 +437,6 @@ int __devinit init_bttv_i2c(struct bttv i2c_new_probed_device(btv-c.i2c_adap, info, addr_list); } #endif - return btv-i2c_rc; } int __devexit fini_bttv_i2c(struct bttv *btv) --- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttvp.h 2009-04-06 10:10:24.0 +0200 +++ v4l-dvb/linux/drivers/media/video/bt8xx/bttvp.h 2010-02-16 18:13:31.0 +0100 @@ -281,6 +281,7 @@ extern unsigned int bttv_debug; extern unsigned int bttv_gpio; extern void bttv_gpio_tracking(struct bttv *btv, char *comment); extern int init_bttv_i2c(struct bttv *btv); +extern void init_bttv_i2c_ir(struct bttv *btv); extern int fini_bttv_i2c(struct bttv *btv); #define bttv_printk if (bttv_verbose) printk --- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-driver.c 2009-12-11 09:47:47.0 +0100 +++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-driver.c 2010-02-16 18:13:31.0 +0100 @@ -4498,6 +4498,7 @@ static int __devinit bttv_probe(struct p request_modules(btv); } + init_bttv_i2c_ir(btv); bttv_input_init(btv); /* everything is fine */ -- 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] bttv: fix compiler warning before kernel 2.6.30
From: Márton Németh nm...@freemail.hu Fix the following compiler warnings when compiling before Linux kernel version 2.6.30: bttv-i2c.c: In function 'init_bttv_i2c': bttv-i2c.c:440: warning: control reaches end of non-void function Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 41c5482f2dac linux/drivers/media/video/bt8xx/bttv-i2c.c --- a/linux/drivers/media/video/bt8xx/bttv-i2c.cThu Mar 04 02:49:46 2010 -0300 +++ b/linux/drivers/media/video/bt8xx/bttv-i2c.cSat Mar 06 10:22:55 2010 +0100 @@ -409,7 +409,6 @@ } if (0 == btv-i2c_rc i2c_scan) do_i2c_scan(btv-c.v4l2_dev.name, btv-i2c_client); -#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30) return btv-i2c_rc; } @@ -417,6 +416,7 @@ /* Instantiate the I2C IR receiver device, if present */ void __devinit init_bttv_i2c_ir(struct bttv *btv) { +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30) if (0 == btv-i2c_rc) { struct i2c_board_info info; /* The external IR receiver is at i2c address 0x34 (0x35 for -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
Hello Hans, Hans Verkuil wrote: 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:Sat Mar 6 19:00:21 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14392:72846c99c0f7 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-dm365: ERRORS linux-2.6.33-armv5-dm365: ERRORS I was interested in what these errors could be so I checked the http://www.xs4all.nl/~hverkuil/logs/Saturday.log file. Unfortunately this log file does not contain more. So I also checked the detailed log files at http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 * linux-2.6.33-armv5-dm365.log and * linux-2.6.32.6-armv5-dm365.log Sat Mar 6 19:03:59 CET 2010 make -C /home/hans/work/build/v4l-dvb-master/v4l make[1]: Entering directory `/home/hans/work/build/v4l-dvb-master/v4l' scripts/make_makefile.pl ./scripts/make_kconfig.pl /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6 /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6 Updating/Creating .config File not found: /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6/.config at ./scripts/make_kconfig.pl line 32, IN line 4. Preparing to compile for kernel version 2.6.32 File not found: /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6/.config at ./scripts/make_kconfig.pl line 32, IN line 4. Preparing to compile for kernel version 2.6.32 make[1]: Leaving directory `/home/hans/work/build/v4l-dvb-master/v4l' make[1]: Entering directory `/home/hans/work/build/v4l-dvb-master/v4l' ./scripts/make_kconfig.pl /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6 /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6 Updating/Creating .config File not found: /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6/.config at ./scripts/make_kconfig.pl line 32, IN line 4. Preparing to compile for kernel version 2.6.32 File not found: /home/hans/work/build/trees/armv5-dm365/linux-2.6.32.6/.config at ./scripts/make_kconfig.pl line 32, IN line 4. Preparing to compile for kernel version 2.6.32 make[1]: *** No rule to make target `.myconfig', needed by `config-compat.h'. Stop. make[1]: Leaving directory `/home/hans/work/build/v4l-dvb-master/v4l' make: *** [all] Error 2 Sat Mar 6 19:03:59 CET 2010 I recommend to add the lines which contain the message File not found to the generated http://www.xs4all.nl/~hverkuil/logs/Saturday.log log file. By the way, what could be the problem here? Regards, Márton Németh -- 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] gspca cpia1: make local functions static
From: Márton Németh nm...@freemail.hu Make the local functions static. Note that the function command_setlights() is currently not called from anywhere. This will remove the following sparse warnings (see make C=1): * symbol 'command_setformat' was not declared. Should it be static? * symbol 'command_setcolourparams' was not declared. Should it be static? * symbol 'command_setapcor' was not declared. Should it be static? * symbol 'command_setvloffset' was not declared. Should it be static? * symbol 'command_setexposure' was not declared. Should it be static? * symbol 'command_setcolourbalance' was not declared. Should it be static? * symbol 'command_setcompressiontarget' was not declared. Should it be static? * symbol 'command_setyuvtresh' was not declared. Should it be static? * symbol 'command_setcompressionparams' was not declared. Should it be static? * symbol 'command_setcompression' was not declared. Should it be static? * symbol 'command_setsensorfps' was not declared. Should it be static? * symbol 'command_setflickerctrl' was not declared. Should it be static? * symbol 'command_setecptiming' was not declared. Should it be static? * symbol 'command_pause' was not declared. Should it be static? * symbol 'command_resume' was not declared. Should it be static? * symbol 'command_setlights' was not declared. Should it be static? Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r e50bb36f881c linux/drivers/media/video/gspca/cpia1.c --- a/linux/drivers/media/video/gspca/cpia1.c Sat Mar 06 22:29:29 2010 -0300 +++ b/linux/drivers/media/video/gspca/cpia1.c Sun Mar 07 07:32:57 2010 +0100 @@ -861,7 +861,7 @@ return do_command(gspca_dev, CPIA_COMMAND_GetExposure, 0, 0, 0, 0); } -int command_setformat(struct gspca_dev *gspca_dev) +static int command_setformat(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; int ret; @@ -878,7 +878,7 @@ sd-params.roi.rowStart, sd-params.roi.rowEnd); } -int command_setcolourparams(struct gspca_dev *gspca_dev) +static int command_setcolourparams(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; return do_command(gspca_dev, CPIA_COMMAND_SetColourParams, @@ -887,7 +887,7 @@ sd-params.colourParams.saturation, 0); } -int command_setapcor(struct gspca_dev *gspca_dev) +static int command_setapcor(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; return do_command(gspca_dev, CPIA_COMMAND_SetApcor, @@ -897,7 +897,7 @@ sd-params.apcor.gain8); } -int command_setvloffset(struct gspca_dev *gspca_dev) +static int command_setvloffset(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; return do_command(gspca_dev, CPIA_COMMAND_SetVLOffset, @@ -907,7 +907,7 @@ sd-params.vlOffset.gain8); } -int command_setexposure(struct gspca_dev *gspca_dev) +static int command_setexposure(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; int ret; @@ -943,7 +943,7 @@ return ret; } -int command_setcolourbalance(struct gspca_dev *gspca_dev) +static int command_setcolourbalance(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; @@ -973,7 +973,7 @@ return -EINVAL; } -int command_setcompressiontarget(struct gspca_dev *gspca_dev) +static int command_setcompressiontarget(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; @@ -983,7 +983,7 @@ sd-params.compressionTarget.targetQ, 0); } -int command_setyuvtresh(struct gspca_dev *gspca_dev) +static int command_setyuvtresh(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; @@ -992,7 +992,7 @@ sd-params.yuvThreshold.uvThreshold, 0, 0); } -int command_setcompressionparams(struct gspca_dev *gspca_dev) +static int command_setcompressionparams(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; @@ -1009,7 +1009,7 @@ sd-params.compressionParams.decimationThreshMod); } -int command_setcompression(struct gspca_dev *gspca_dev) +static int command_setcompression(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; @@ -1018,7 +1018,7 @@ sd-params.compression.decimation, 0, 0); } -int command_setsensorfps(struct gspca_dev *gspca_dev) +static int command_setsensorfps(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; @@ -1027,7 +1027,7 @@ sd-params.sensorFps.baserate, 0, 0); } -int command_setflickerctrl(struct gspca_dev *gspca_dev) +static int command_setflickerctrl(struct gspca_dev *gspca_dev) { struct sd *sd = (struct sd *) gspca_dev; @@ -1038,7 +1038,7 @@ 0); } -int
[RFC, PATCH 1/3] gspca: add LEDs subsystem connection
From: Márton Németh nm...@freemail.hu On some webcams one or more LEDs can be found. One type of these LEDs are feedback LEDs: they usually shows the state of streaming mode. The LED can be programmed to constantly switched off state (e.g. for power saving reasons, preview mode) or on state (e.g. the application shows motion detection or on-air). The second type of LEDs are used to create enough light for the sensor for example visible or in infra-red light. Both type of these LEDs can be handled using the LEDs subsystem. This patch add support to connect a gspca based driver to the LEDs subsystem. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r d8fafa7d88dc linux/drivers/media/video/gspca/gspca.h --- a/linux/drivers/media/video/gspca/gspca.h Thu Feb 18 19:02:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/gspca.h Wed Mar 03 00:10:19 2010 +0100 @@ -7,6 +7,8 @@ #include linux/videodev2.h #include media/v4l2-common.h #include linux/mutex.h +#include linux/leds.h +#include linux/workqueue.h #include compat.h /* compilation option */ @@ -53,14 +55,41 @@ int nrates; }; +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) +/** + * struct gspca_led - data structure for one LED on a camera + * @led_cdev: the class device for the LED + * @name: place for the LED name which will appear under /sys/class/leds/ + * @led_trigger: the trigger structure for the same LED + * @trigger_name: place for the trigger name which will appear in the file + */sys/class/leds/{led name}/trigger + * @parent: pointer to the parent gspca_dev + */ +struct gspca_led { + struct led_classdev led_cdev; + char name[32]; +#ifdef CONFIG_LEDS_TRIGGERS + struct led_trigger led_trigger; + char trigger_name[32]; +#endif + struct gspca_dev *parent; +}; +#endif + /* device information - set at probe time */ struct cam { const struct v4l2_pix_format *cam_mode; /* size nmodes */ const struct framerates *mode_framerates; /* must have size nmode, * just like cam_mode */ +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) + struct gspca_led *leds; +#endif u32 bulk_size; /* buffer size when image transfer by bulk */ u32 input_flags;/* value for ENUM_INPUT status flags */ u8 nmodes; /* size of cam_mode */ +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) + u8 nleds; /* number of LEDs */ +#endif u8 no_urb_create; /* don't create transfer URBs */ u8 bulk_nurbs; /* number of URBs in bulk mode * - cannot be MAX_NURBS diff -r d8fafa7d88dc linux/drivers/media/video/gspca/gspca.c --- a/linux/drivers/media/video/gspca/gspca.c Thu Feb 18 19:02:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/gspca.c Wed Mar 03 00:10:19 2010 +0100 @@ -4,6 +4,7 @@ * Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr) * * Camera button input handling by Márton Németh + * LED subsystem connection by Márton Németh * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu * * This program is free software; you can redistribute it and/or modify it @@ -2256,6 +2257,76 @@ .release = gspca_release, }; +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) +/** + * gspca_create_name() - Create a name using format string and a number + * @name: format string on input, e.g. video%d::feedback. The format string + *may contain one and only one %d format specifier. The created name + *will be put on the same location and the original format string will + *be overwritten. + * @length: the length of the buffer in bytes pointed by the name parameter + * @num: the number to use when creating the name + * + * Returns zero on success. + */ +static int gspca_create_name(char *name, unsigned int length, int num) +{ + char buffer[32]; + unsigned int l; + + /* TODO: check format string: it shall contain one and only one %d */ + + l = min(length, sizeof(buffer)); + snprintf(buffer, l, name, num); + strlcpy(name, buffer, l); + + return 0; +} + +static void gspca_leds_register(struct gspca_dev *gspca_dev) { + int i; + int ret; + + for (i = 0; i gspca_dev-cam.nleds; i++) { +#ifdef CONFIG_LEDS_TRIGGERS + gspca_create_name(gspca_dev-cam.leds[i].trigger_name, + sizeof(gspca_dev-cam.leds[i].trigger_name), + gspca_dev-vdev.num); + gspca_dev-cam.leds[i].led_trigger.name = gspca_dev-cam.leds[i].trigger_name; + gspca_dev-cam.leds[i].led_cdev.default_trigger = gspca_dev-cam.leds[i].trigger_name; +#endif + gspca_create_name(gspca_dev-cam.leds[i].name, +
[RFC, PATCH 2/3] gspca pac7302: separate LED handling
From: Márton Németh nm...@freemail.hu On Labtec Webcam 2200 there is a feedback LED which can be controlled independent from the streaming. The feedback LED can be used from user space application to show for example detected motion or to distinguish between the preview and on-air state of the video stream. The default value of the LED control is Auto which keeps the previous behaviour: LED is off when the stream is off, LED is on if the stream is on. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r d8fafa7d88dc linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Thu Feb 18 19:02:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Wed Mar 03 00:10:19 2010 +0100 @@ -6,6 +6,7 @@ * * Separated from Pixart PAC7311 library by Márton Németh * Camera button input handling by Márton Németh nm...@freemail.hu + * LED control by Márton Németh nm...@freemail.hu * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu * * This program is free software; you can redistribute it and/or modify @@ -62,6 +63,7 @@ 0 | 0xc6 | setwhitebalance() 0 | 0xc7 | setbluebalance() 0 | 0xdc | setbrightcont(), setcolors() +1 | 0x78 | set_streaming_led() 3 | 0x02 | setexposure() 3 | 0x10 | setgain() 3 | 0x11 | setcolors(), setgain(), setexposure(), sethvflip() @@ -72,6 +74,8 @@ #include linux/input.h #include media/v4l2-chip-ident.h +#include linux/leds.h +#include linux/workqueue.h #include gspca.h MODULE_AUTHOR(Thomas Kaiser tho...@kaiser-linux.li); @@ -81,6 +85,10 @@ /* specific webcam descriptor for pac7302 */ struct sd { struct gspca_dev gspca_dev; /* !! must be the first item */ +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) + struct gspca_led feedback_led; + struct work_struct led_work; +#endif unsigned char brightness; unsigned char contrast; @@ -91,6 +99,7 @@ unsigned char gain; unsigned char exposure; unsigned char autogain; + unsigned char led; __u8 hflip; __u8 vflip; u8 flags; @@ -126,6 +135,7 @@ static int sd_getgain(struct gspca_dev *gspca_dev, __s32 *val); static int sd_setexposure(struct gspca_dev *gspca_dev, __s32 val); static int sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val); +static void set_streaming_led(struct gspca_dev *gspca_dev, u8 streaming); static const struct ctrl sd_ctrls[] = { /* This control is pac7302 only */ @@ -550,6 +560,39 @@ /* not reached */ } +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) +/* Set the LED, may sleep */ +static void led_work(struct work_struct *work) +{ + struct sd *sd = container_of(work, struct sd, led_work); + struct gspca_dev *gspca_dev = sd-gspca_dev; + + mutex_lock(gspca_dev-usb_lock); + set_streaming_led(gspca_dev, gspca_dev-streaming); + mutex_unlock(gspca_dev-usb_lock); +} + +/* LED state set request, must not sleep */ +static void led_set(struct led_classdev *led_cdev, + enum led_brightness brightness) +{ + u8 new_brightness; + struct gspca_led *led = container_of(led_cdev, struct gspca_led, led_cdev); + struct gspca_dev *gspca_dev = led-parent; + struct sd *sd = container_of(gspca_dev, struct sd, gspca_dev); + + if (brightness == LED_OFF) + new_brightness = 0; + else + new_brightness = 1; + + if (sd-led != new_brightness gspca_dev-present) { + sd-led = new_brightness; + schedule_work(sd-led_work); + } +} +#endif + /* this function is called at probe time for pac7302 */ static int sd_config(struct gspca_dev *gspca_dev, const struct usb_device_id *id) @@ -563,6 +606,20 @@ cam-cam_mode = vga_mode; /* only 640x480 */ cam-nmodes = ARRAY_SIZE(vga_mode); +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) + INIT_WORK(sd-led_work, led_work); + strncpy(sd-feedback_led.name, video%d::feedback, + sizeof(sd-feedback_led.name)); +#ifdef CONFIG_LEDS_TRIGGERS + strncpy(sd-feedback_led.trigger_name, video%d, + sizeof(sd-feedback_led.trigger_name)); +#endif + sd-feedback_led.led_cdev.brightness_set = led_set; + sd-feedback_led.parent = gspca_dev; + cam-leds = sd-feedback_led; + cam-nleds = 1; +#endif + sd-brightness = BRIGHTNESS_DEF; sd-contrast = CONTRAST_DEF; sd-colors = COLOR_DEF; @@ -572,6 +629,7 @@ sd-gain = GAIN_DEF; sd-exposure = EXPOSURE_DEF; sd-autogain = AUTOGAIN_DEF; + sd-led = 0; sd-hflip = HFLIP_DEF; sd-vflip = VFLIP_DEF; sd-flags = id-driver_info; @@ -716,6 +774,27 @@ reg_w(gspca_dev, 0x11, 0x01); } +static void set_streaming_led(struct gspca_dev *gspca_dev, u8
[RFC, PATCH 3/3] gspca pac7302: remove LED blinking when switching stream on and off
From: Márton Németh nm...@freemail.hu The init sequences for PAC7302 contained register settings affecting the LED state which can result blinking of the LED when it is set to always on or always off. The blinking happened when the stream was switched on or off. Remove the register changes from the init sequence and handle it with the function set_streaming_led(). Signed-off-by: Márton Németh nm...@freemail.hu --- --- a/linux/drivers/media/video/gspca/pac7302.c.orig2010-03-03 00:05:04.0 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c 2010-03-03 00:13:07.0 +0100 @@ -317,13 +317,6 @@ static const struct v4l2_pix_format vga_ #define END_OF_SEQUENCE0 /* pac 7302 */ -static const __u8 init_7302[] = { -/* index,value */ - 0xff, 0x01, /* page 1 */ - 0x78, 0x00, /* deactivate */ - 0xff, 0x01, - 0x78, 0x40, /* led off */ -}; static const __u8 start_7302[] = { /* index, len, [value]* */ 0xff, 1,0x00, /* page 0 */ @@ -359,7 +352,8 @@ static const __u8 start_7302[] = { 0xff, 1,0x01, /* page 1 */ 0x12, 3,0x02, 0x00, 0x01, 0x3e, 2,0x00, 0x00, - 0x76, 5,0x01, 0x20, 0x40, 0x00, 0xf2, + 0x76, 2,0x01, 0x20, + 0x79, 2,0x00, 0xf2, 0x7c, 1,0x00, 0x7f, 10, 0x4b, 0x0f, 0x01, 0x2c, 0x02, 0x58, 0x03, 0x20, 0x02, 0x00, @@ -383,8 +377,6 @@ static const __u8 start_7302[] = { 0x2a, 5,0xc8, 0x00, 0x18, 0x12, 0x22, 0x64, 8,0x00, 0x00, 0xf0, 0x01, 0x14, 0x44, 0x44, 0x44, 0x6e, 1,0x08, - 0xff, 1,0x01, /* page 1 */ - 0x78, 1,0x00, 0, END_OF_SEQUENCE /* end of sequence */ }; @@ -482,15 +474,6 @@ static void reg_w(struct gspca_dev *gspc } } -static void reg_w_seq(struct gspca_dev *gspca_dev, - const __u8 *seq, int len) -{ - while (--len = 0) { - reg_w(gspca_dev, seq[0], seq[1]); - seq += 2; - } -} - /* load the beginning of a page */ static void reg_w_page(struct gspca_dev *gspca_dev, const __u8 *page, int len) @@ -798,7 +781,7 @@ static void set_streaming_led(struct gsp /* this function is called at probe and resume time for pac7302 */ static int sd_init(struct gspca_dev *gspca_dev) { - reg_w_seq(gspca_dev, init_7302, sizeof(init_7302)/2); + set_streaming_led(gspca_dev, 0); return gspca_dev-usb_err; } -- 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] Input: scancode in get/set_keycodes should be unsigned
Dmitry Torokhov wrote: On Sun, Feb 28, 2010 at 07:44:32AM +0100, Németh Márton wrote: Hi, Dmitry Torokhov wrote: The HID layer has some scan codes of the form 0xffbc for logitech devices which do not work if scancode is typed as signed int, so we need to switch to unsigned int instead. While at it keycode being signed does not make much sense either. Are the scan codes and key codes always 4 bytes long? Then the u32 data type could be used to take 16 bit (or 64 bit) processors also into consideration. We do not support 16 bit processors and for 64 bit 'unsigned int' is still 32 bits. OK, then: Acked-by: Márton Németh nm...@freemail.hu -- 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] tlg2300: cleanups when power management is not configured
From: Márton Németh nm...@freemail.hu When power management is not configured (CONFIG_PM) then some code is no longer necessary. This patch will remove the following compiler warnings: * pd-dvb.c: In function 'poseidon_fe_release': * pd-dvb.c:101: warning: unused variable 'pd' * pd-video.c:14: warning: 'pm_video_suspend' declared 'static' but never defined * pd-video.c:15: warning: 'pm_video_resume' declared 'static' but never defined Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 37581bb7e6f1 linux/drivers/media/video/tlg2300/pd-dvb.c --- a/linux/drivers/media/video/tlg2300/pd-dvb.cWed Feb 24 22:48:50 2010 -0300 +++ b/linux/drivers/media/video/tlg2300/pd-dvb.cSun Feb 28 15:13:05 2010 +0100 @@ -96,15 +96,17 @@ return ret; } +#ifdef CONFIG_PM static void poseidon_fe_release(struct dvb_frontend *fe) { struct poseidon *pd = fe-demodulator_priv; -#ifdef CONFIG_PM pd-pm_suspend = NULL; pd-pm_resume = NULL; +} +#else +#define poseidon_fe_release NULL #endif -} static s32 poseidon_fe_sleep(struct dvb_frontend *fe) { diff -r 37581bb7e6f1 linux/drivers/media/video/tlg2300/pd-video.c --- a/linux/drivers/media/video/tlg2300/pd-video.c Wed Feb 24 22:48:50 2010 -0300 +++ b/linux/drivers/media/video/tlg2300/pd-video.c Sun Feb 28 15:13:05 2010 +0100 @@ -11,8 +11,10 @@ #include pd-common.h #include vendorcmds.h +#ifdef CONFIG_PM static int pm_video_suspend(struct poseidon *pd); static int pm_video_resume(struct poseidon *pd); +#endif static void iso_bubble_handler(struct work_struct *w); int usb_transfer_mode; -- 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] nGene: use NULL when pointer is needed
From: Márton Németh nm...@freemail.hu Use NULL when calling a function with pointer parameter, initializing a pointer and returning a pointer. This will remove the following sparse warning at different locations (see make C=1): * warning: Using plain integer as NULL pointer Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 37581bb7e6f1 linux/drivers/media/dvb/ngene/ngene-core.c --- a/linux/drivers/media/dvb/ngene/ngene-core.cWed Feb 24 22:48:50 2010 -0300 +++ b/linux/drivers/media/dvb/ngene/ngene-core.cSun Feb 28 15:28:56 2010 +0100 @@ -994,7 +994,7 @@ msg[0].buf, msg[0].len)) goto done; if (num == 1 (msg[0].flags I2C_M_RD)) - if (!ngene_command_i2c_read(dev, msg[0].addr, 0, 0, + if (!ngene_command_i2c_read(dev, msg[0].addr, NULL, 0, msg[0].buf, msg[0].len, 0)) goto done; @@ -1793,7 +1793,7 @@ if (chan-users 0) #endif dvb_dmx_swfilter(chan-demux, buf, len); - return 0; + return NULL; } u8 fill_ts[188] = { 0x47, 0x1f, 0xff, 0x10 }; @@ -1900,7 +1900,7 @@ state); if (!state) { spin_lock_irq(chan-state_lock); - chan-pBufferExchange = 0; + chan-pBufferExchange = NULL; dvb_ringbuffer_flush(dev-tsout_rbuf); spin_unlock_irq(chan-state_lock); } @@ -2226,7 +2226,7 @@ dvbdemux-feednum = 256; dvbdemux-start_feed = start_feed; dvbdemux-stop_feed = stop_feed; - dvbdemux-write_to_decoder = 0; + dvbdemux-write_to_decoder = NULL; dvbdemux-dmx.capabilities = (DMX_TS_FILTERING | DMX_SECTION_FILTERING | DMX_MEMORY_BASED_FILTERING); @@ -2383,8 +2383,8 @@ return; free_ringbuffer(dev, rb); for (j = 0; j tb-NumBuffers; j++, Cur = Cur-Next) { - Cur-Buffer2 = 0; - Cur-scList2 = 0; + Cur-Buffer2 = NULL; + Cur-scList2 = NULL; Cur-ngeneBuffer.Address_of_first_entry_2 = 0; Cur-ngeneBuffer.Number_of_entries_2 = 0; } @@ -2430,7 +2430,7 @@ u64 PARingBufferNext; struct SBufferHeader *Cur, *Next; - descr-Head = 0; + descr-Head = NULL; descr-MemSize = 0; descr-PAHead = 0; descr-NumBuffers = 0; @@ -3619,7 +3619,7 @@ if (chan-fe) { dvb_unregister_frontend(chan-fe); dvb_frontend_detach(chan-fe); - chan-fe = 0; + chan-fe = NULL; } dvbdemux-dmx.close(dvbdemux-dmx); dvbdemux-dmx.remove_frontend(dvbdemux-dmx, @@ -3765,7 +3765,7 @@ release_channel(dev-channel[i]); ngene_stop(dev); ngene_release_buffers(dev); - pci_set_drvdata(pdev, 0); + pci_set_drvdata(pdev, NULL); pci_disable_device(pdev); } @@ -3840,7 +3840,7 @@ ngene_release_buffers(dev); fail0: pci_disable_device(pci_dev); - pci_set_drvdata(pci_dev, 0); + pci_set_drvdata(pci_dev, NULL); return stat; } -- 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] tlg2300: make local variables and functions static
From: Márton Németh nm...@freemail.hu Make the local variables and functions static. Some of them are not exported by their symbol name but used trough other means. For example a pointer of the operation structure is passed through a function call. This will remove the following sparse warnings (see make C=1): * pd-video.c:20:5: warning: symbol 'usb_transfer_mode' was not declared. Should it be static? * pd-video.c:621:5: warning: symbol 'fire_all_urb' was not declared. Should it be static? * pd-video.c:881:5: warning: symbol 'vidioc_s_std' was not declared. Should it be static? * pd-video.c:1024:5: warning: symbol 'vidioc_g_audio' was not declared. Should it be static? * pd-video.c:1033:5: warning: symbol 'vidioc_s_audio' was not declared. Should it be static? * pd-video.c:1193:5: warning: symbol 'usb_transfer_stop' was not declared. Should it be static? * pd-video.c:1522:14: warning: symbol 'pd_video_poll' was not declared. Should it be static? * pd-video.c:1528:9: warning: symbol 'pd_video_read' was not declared. Should it be static? * pd-radio.c:164:5: warning: symbol 'tlg_fm_vidioc_g_tuner' was not declared. Should it be static? * pd-radio.c:206:5: warning: symbol 'fm_get_freq' was not declared. Should it be static? * pd-radio.c:249:5: warning: symbol 'fm_set_freq' was not declared. Should it be static? * pd-radio.c:261:5: warning: symbol 'tlg_fm_vidioc_g_ctrl' was not declared. Should it be static? * pd-radio.c:267:5: warning: symbol 'tlg_fm_vidioc_g_exts_ctrl' was not declared. Should it be static? * pd-radio.c:288:5: warning: symbol 'tlg_fm_vidioc_s_exts_ctrl' was not declared. Should it be static? * pd-radio.c:315:5: warning: symbol 'tlg_fm_vidioc_s_ctrl' was not declared. Should it be static? * pd-radio.c:321:5: warning: symbol 'tlg_fm_vidioc_queryctrl' was not declared. Should it be static? * pd-radio.c:340:5: warning: symbol 'tlg_fm_vidioc_querymenu' was not declared. Should it be static? * pd-main.c:58:12: warning: symbol 'firmware_name' was not declared. Should it be static? * pd-main.c:59:19: warning: symbol 'poseidon_driver' was not declared. Should it be static? Signed-off-by: Márton Németh nm...@freemail.hu --- diff -upr v4l-dvb.orig/linux/drivers/media/video/tlg2300/pd-main.c v4l-dvb/linux/drivers/media/video/tlg2300/pd-main.c --- v4l-dvb.orig/linux/drivers/media/video/tlg2300/pd-main.c2010-02-28 14:54:31.0 +0100 +++ v4l-dvb/linux/drivers/media/video/tlg2300/pd-main.c 2010-02-28 15:49:10.0 +0100 @@ -55,8 +55,8 @@ int debug_mode; module_param(debug_mode, int, 0644); MODULE_PARM_DESC(debug_mode, 0 = disable, 1 = enable, 2 = verbose); -const char *firmware_name = tlg2300_firmware.bin; -struct usb_driver poseidon_driver; +static const char *firmware_name = tlg2300_firmware.bin; +static struct usb_driver poseidon_driver; static LIST_HEAD(pd_device_list); /* @@ -501,7 +501,7 @@ static void poseidon_disconnect(struct u kref_put(pd-kref, poseidon_delete); } -struct usb_driver poseidon_driver = { +static struct usb_driver poseidon_driver = { .name = poseidon, .probe = poseidon_probe, .disconnect = poseidon_disconnect, diff -upr v4l-dvb.orig/linux/drivers/media/video/tlg2300/pd-radio.c v4l-dvb/linux/drivers/media/video/tlg2300/pd-radio.c --- v4l-dvb.orig/linux/drivers/media/video/tlg2300/pd-radio.c 2010-02-28 14:54:31.0 +0100 +++ v4l-dvb/linux/drivers/media/video/tlg2300/pd-radio.c2010-02-28 15:48:07.0 +0100 @@ -161,7 +161,7 @@ static const struct v4l2_file_operations .ioctl = video_ioctl2, }; -int tlg_fm_vidioc_g_tuner(struct file *file, void *priv, struct v4l2_tuner *vt) +static int tlg_fm_vidioc_g_tuner(struct file *file, void *priv, struct v4l2_tuner *vt) { struct tuner_fm_sig_stat_s fm_stat = {}; int ret, status, count = 5; @@ -203,7 +203,7 @@ int tlg_fm_vidioc_g_tuner(struct file *f return 0; } -int fm_get_freq(struct file *file, void *priv, struct v4l2_frequency *argp) +static int fm_get_freq(struct file *file, void *priv, struct v4l2_frequency *argp) { struct poseidon *p = file-private_data; @@ -246,7 +246,7 @@ error: return ret; } -int fm_set_freq(struct file *file, void *priv, struct v4l2_frequency *argp) +static int fm_set_freq(struct file *file, void *priv, struct v4l2_frequency *argp) { struct poseidon *p = file-private_data; @@ -258,13 +258,13 @@ int fm_set_freq(struct file *file, void return set_frequency(p, argp-frequency); } -int tlg_fm_vidioc_g_ctrl(struct file *file, void *priv, +static int tlg_fm_vidioc_g_ctrl(struct file *file, void *priv, struct v4l2_control *arg) { return 0; } -int tlg_fm_vidioc_g_exts_ctrl(struct file *file, void *fh, +static int tlg_fm_vidioc_g_exts_ctrl(struct file *file, void *fh, struct v4l2_ext_controls *ctrls) { struct poseidon *p =
Re: [PATCH 1/3] add feedback LED control
Jean-Francois Moine wrote: On Sun, 28 Feb 2010 08:55:04 +0100 Németh Márton nm...@freemail.hu wrote: On some webcams a feedback LED can be found. This LED usually shows the state of streaming mode: this is the Auto mode. The LED can be programmed to constantly switched off state (e.g. for power saving reasons, preview mode) or on state (e.g. the application shows motion detection or on-air). Hi, There may be many LEDs on the webcams. One LED may be used for the streaming state, Some other ones may be used to give more light in dark rooms. One webcam, the microscope 093a:050f, has a top and a bottom lights/illuminators; an other one, the MSI StarCam 370i 0c45:60c0, has an infra-red light. That's why I proposed to have bit fields in the control value to switch on/off each LED. With a bitfield on and off state can be specified. What about the auto mode? Should two bits grouped together to have auto, on and off state? Is there already a similar control? Is the brightness of the background light LEDs adjustable or are they just on/off? If yes, then maybe the feedback LEDs and the background light LEDs should be treated as different kind. Regards, Márton Németh -- 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
az6027: variables may be used uninitialized in az6027_i2c_xfer()
Hi Adams, Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. [...] Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log linux-2.6.29.1-i686: WARNINGS /home/hans/work/build/v4l-dvb-master/v4l/az6027.c: In function 'az6027_i2c_xfer': /home/hans/work/build/v4l-dvb-master/v4l/az6027.c:942: warning: 'index' may be used uninitialized in this function /home/hans/work/build/v4l-dvb-master/v4l/az6027.c:943: warning: 'value' may be used uninitialized in this function /home/hans/work/build/v4l-dvb-master/v4l/az6027.c:944: warning: 'length' may be used uninitialized in this function /home/hans/work/build/v4l-dvb-master/v4l/az6027.c:945: warning: 'req' may be used uninitialized in this function I checked what can cause these warning messages and found that in line 990 of linux/drivers/media/dvb/dvb-usb/az6027.c the function az6027_usb_out_op() is called. Before that call it seems that the condition (msg[i].addr == 0xd0) is checked for the second time which is redundant. Regards, Márton Németh -- 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] az6027: remove redundant condition check
From: Márton Németh nm...@freemail.hu The condition (msg[i].addr == 0xd0) is checked twice the second one is not necessary. This will remove the following compiler warning: az6027.c: In function 'az6027_i2c_xfer': az6027.c:942: warning: 'index' may be used uninitialized in this function az6027.c:943: warning: 'value' may be used uninitialized in this function az6027.c:944: warning: 'length' may be used uninitialized in this function az6027.c:945: warning: 'req' may be used uninitialized in this function Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 37581bb7e6f1 linux/drivers/media/dvb/dvb-usb/az6027.c --- a/linux/drivers/media/dvb/dvb-usb/az6027.c Wed Feb 24 22:48:50 2010 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/az6027.c Mon Mar 01 08:09:35 2010 +0100 @@ -976,17 +976,14 @@ i++; } else { - if (msg[i].addr == 0xd0) { - /* demod 16bit addr */ - req = 0xBD; - index = (((msg[i].buf[0] 8) 0xff00) | (msg[i].buf[1] 0x00ff)); - value = msg[i].addr + (2 8); - length = msg[i].len - 2; - len = msg[i].len - 2; - for (j = 0; j len; j++) - data[j] = msg[i].buf[j + 2]; - - } + /* demod 16bit addr */ + req = 0xBD; + index = (((msg[i].buf[0] 8) 0xff00) | (msg[i].buf[1] 0x00ff)); + value = msg[i].addr + (2 8); + length = msg[i].len - 2; + len = msg[i].len - 2; + for (j = 0; j len; j++) + data[j] = msg[i].buf[j + 2]; az6027_usb_out_op(d, req, value, index, data, length); } } -- 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/2] gspca pac7302: allow controlling LED separately
Hi, I missed the CONFIG_LEDS_CLASS_MODULE configuration option in the previous version of this patch, now it is added. Regards, Márton Németh --- From: Márton Németh nm...@freemail.hu On Labtec Webcam 2200 there is a feedback LED which can be controlled independent from the streaming. The feedback LED can be used from user space application to show for example detected motion or to distinguish between the preview and on-air state of the video stream. The default value of the LED trigger keeps the previous behaviour: LED is off when the stream is off, LED is on if the stream is on. The code is working in the following three cases: (1) when the LED subsystem ins not configured at all; (2) when the LED subsystem is available, but the LED triggers are not available and (3) when both the LED subsystem and LED triggers are configured. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r d8fafa7d88dc linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Thu Feb 18 19:02:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Sat Feb 27 09:10:44 2010 +0100 @@ -6,6 +6,7 @@ * * Separated from Pixart PAC7311 library by Márton Németh * Camera button input handling by Márton Németh nm...@freemail.hu + * LED control by Márton Németh nm...@freemail.hu * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu * * This program is free software; you can redistribute it and/or modify @@ -62,6 +63,7 @@ 0 | 0xc6 | setwhitebalance() 0 | 0xc7 | setbluebalance() 0 | 0xdc | setbrightcont(), setcolors() +1 | 0x78 | set_streaming_led() 3 | 0x02 | setexposure() 3 | 0x10 | setgain() 3 | 0x11 | setcolors(), setgain(), setexposure(), sethvflip() @@ -72,6 +74,8 @@ #include linux/input.h #include media/v4l2-chip-ident.h +#include linux/leds.h +#include linux/workqueue.h #include gspca.h MODULE_AUTHOR(Thomas Kaiser tho...@kaiser-linux.li); @@ -91,6 +95,7 @@ unsigned char gain; unsigned char exposure; unsigned char autogain; + unsigned char led; __u8 hflip; __u8 vflip; u8 flags; @@ -101,6 +106,16 @@ u8 autogain_ignore_frames; atomic_t avg_lum; + +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) + struct led_classdev led_cdev; + struct work_struct led_work; + char name[32]; +#ifdef CONFIG_LEDS_TRIGGERS + struct led_trigger led_trigger; + char trigger_name[32]; +#endif +#endif }; /* V4L2 controls supported by the driver */ @@ -572,6 +587,7 @@ sd-gain = GAIN_DEF; sd-exposure = EXPOSURE_DEF; sd-autogain = AUTOGAIN_DEF; + sd-led = 0; sd-hflip = HFLIP_DEF; sd-vflip = VFLIP_DEF; sd-flags = id-driver_info; @@ -716,6 +732,58 @@ reg_w(gspca_dev, 0x11, 0x01); } +static void set_streaming_led(struct gspca_dev *gspca_dev, u8 streaming) +{ + struct sd *sd = (struct sd *) gspca_dev; + u8 data = 0; + + if (sd-led) { + if (streaming) + data = 0x01; + else + data = 0x00; + } else { + if (streaming) + data = 0x41; + else + data = 0x40; + } + + reg_w(gspca_dev, 0xff, 0x01); + reg_w(gspca_dev, 0x78, data); +} + +#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) +/* Set the LED, may sleep */ +static void led_work(struct work_struct *work) +{ + struct sd *sd = container_of(work, struct sd, led_work); + struct gspca_dev *gspca_dev = sd-gspca_dev; + + mutex_lock(gspca_dev-usb_lock); + set_streaming_led(gspca_dev, gspca_dev-streaming); + mutex_unlock(gspca_dev-usb_lock); +} + +/* LED state set request, must not sleep */ +static void led_set(struct led_classdev *led_cdev, + enum led_brightness value) +{ + u8 new_value; + struct sd *sd = container_of(led_cdev, struct sd, led_cdev); + + if (value == LED_OFF) + new_value = 0; + else + new_value = 1; + + if (sd-led != new_value) { + sd-led = new_value; + schedule_work(sd-led_work); + } +} +#endif + /* this function is called at probe and resume time for pac7302 */ static int sd_init(struct gspca_dev *gspca_dev) { @@ -747,27 +815,60 @@ atomic_set(sd-avg_lum, -1); /* start stream */ - reg_w(gspca_dev, 0xff, 0x01); - reg_w(gspca_dev, 0x78, 0x01); + +#if (defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)) defined(CONFIG_LEDS_TRIGGERS) + led_trigger_event(sd-led_trigger, LED_FULL); +#elif defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE) + sd-led_cdev.brightness = sd-led_cdev.max_brightness; + if (!(sd-led_cdev.flags LED_SUSPENDED)) +
Re: [PATCH 1/2] gspca pac7302: allow controlling LED separately
Hi, Hans de Goede wrote: Hi, On 02/27/2010 01:20 AM, Németh Márton wrote: From: Márton Némethnm...@freemail.hu On Labtec Webcam 2200 there is a feedback LED which can be controlled independent from the streaming. This is true for a lot of cameras, so if we are going to add a way to support control of the LED separate of the streaming state, we should do that at the gspca_main level, and let sub drivers which support this export a set_led callback function. If the code is moved to gspca_main level, what shall be the name of the LED? According to Documentation/leds-class.txt, chapter LED Device Naming my proposal for devicename would be: * /sys/class/leds/video-0::camera * /sys/class/leds/video-1::camera * /sys/class/leds/video-2::camera * ... or * /sys/class/leds/video0::camera * /sys/class/leds/video1::camera * /sys/class/leds/video2::camera * ... Which is the right one? I must say I personally don't see much of a use case for this feature, but I believe JF Moine does, so I'll leave further comments and review of this to JF. I do believe it is important that if we go this way we do so add the gspca_main level. 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: [PATCH 1/2] gspca pac7302: allow controlling LED separately
Hi, Jean-Francois Moine wrote: On Sat, 27 Feb 2010 08:53:16 +0100 Hans de Goede hdego...@redhat.com wrote: This is true for a lot of cameras, so if we are going to add a way to support control of the LED separate of the streaming state, we should do that at the gspca_main level, and let sub drivers which support this export a set_led callback function. I must say I personally don't see much of a use case for this feature, but I believe JF Moine does, so I'll leave further comments and review of this to JF. I do believe it is important that if we go this way we do so add the gspca_main level. Hi, I don't like this mechanism to switch on or off the webcam LEDs. Here are some arguments (some of them were sent last year to the list): I could accept both the V4L2 control solution or the LED subclass solution for handling the camera LED. I miss a little the positive side of using the LED subclass from the list, so I try take the role of that side and add them. 1) End users. Many Linux users don't know the kernel internals, nor which of the too many applications they should use to make their devices work. Actually, there are a few X11 programs in common Linux distros which can handle the webcam parameters: I just know about vlc and v4l2ucp, and they don't even handle the VIDIOC_G_JPEGCOMP and VIDIOC_S_JPEGCOMP ioctls which are part of the v4l2 API. The LED interface uses the /sys file system. Will the webcam programs offer access to this interface? I don't believe it. So, the users will have to search how they can switch on or off the LEDs of their webcams, and then, when found, they should start a X terminal and run a command to do the job! The programs like v4l2ucp can be extended to handle the /sys/class/leds interface. This is work but the user will not recognise the difference as long as the GUI supports it. On the other hand, a webcam LED control, whether general or private, is available in the graphical interface as soon as the driver offers it. 2) Memory overhead. Using the led class adds more kernel code and asks the webcam drivers to create a new device. Also, the function called for changing the LED brighness cannot sleep, so the use a workqueue is required. Let me show the numbers on a 32bit machine: sizeof(struct gspca_dev) = 2032 bytes sizeof(struct led_classdev) = 112 bytes sizeof(struct work_struct) = 28 bytes sizeof(struct led_trigger) = 52 bytes Additionally two strings are also needed one for the LED device name and one for the LED trigger. Let's take 32 bytes for each (this value can be made smaller). This means that the necessary memory is 112+28+52+2*32 = 256 bytes. The pac7302 driver subdriver structure with LED device, workqueue and LED trigger is: sizeof(struct sd) = 2308 bytes So the memory usage increase is 1-2308/2032 = 13.6%. I would compare the structure size with the memory page size of the x86 system which is 4096 bytes (see the return value of getpagesize(2)). On contrary, with a webcam control, only one byte (for 8 LEDs) is added to the webcam structure and the change is immediatly done in the ioctl. 3) Development. If nobody wants a LED control in the v4l2 interface, I think the code added to access the led class could be splitted between the different subsystem. For example, the workqueue handling could be done in the led class itself... Advantages of LED subsystem are: 4) Flexible usage of the camera LED for purposes unrelated to camera or unusual way, e.g. just blinking the LED with ledtrig-timer. 5) The status of the LED can be read back by reading /sys/class/leds/video0::camera/brightness. This is not possible when the auto menu item is selected from a V4L2 based menu control. Regards, Márton Németh -- 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] Input: scancode in get/set_keycodes should be unsigned
Hi, Dmitry Torokhov wrote: The HID layer has some scan codes of the form 0xffbc for logitech devices which do not work if scancode is typed as signed int, so we need to switch to unsigned int instead. While at it keycode being signed does not make much sense either. Are the scan codes and key codes always 4 bytes long? Then the u32 data type could be used to take 16 bit (or 64 bit) processors also into consideration. Regards, Márton Németh -- 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/3] add feedback LED control
From: Márton Németh nm...@freemail.hu On some webcams a feedback LED can be found. This LED usually shows the state of streaming mode: this is the Auto mode. The LED can be programmed to constantly switched off state (e.g. for power saving reasons, preview mode) or on state (e.g. the application shows motion detection or on-air). Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r d8fafa7d88dc linux/Documentation/DocBook/v4l/controls.xml --- a/linux/Documentation/DocBook/v4l/controls.xml Thu Feb 18 19:02:51 2010 +0100 +++ b/linux/Documentation/DocBook/v4l/controls.xml Sun Feb 28 08:41:17 2010 +0100 @@ -311,6 +311,17 @@ Applications depending on particular custom controls should check the driver name and version, see xref linkend=querycap /./entry /row + row id=v4l2-led + entryconstantV4L2_CID_LED/constant/entry + entryenum/entry + entryControls the feedback LED on the camera. In auto mode +the LED is on when the streaming is active. The LED is off when not streaming. +The LED can be also turned on and off independent from streaming. +Possible values for constantenum v4l2_led/constant are: +constantV4L2_CID_LED_AUTO/constant (0), +constantV4L2_CID_LED_ON/constant (1) and +constantV4L2_CID_LED_OFF/constant (2)./entry + /row /tbody /tgroup /table diff -r d8fafa7d88dc linux/Documentation/DocBook/v4l/videodev2.h.xml --- a/linux/Documentation/DocBook/v4l/videodev2.h.xml Thu Feb 18 19:02:51 2010 +0100 +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml Sun Feb 28 08:41:17 2010 +0100 @@ -1024,8 +1024,14 @@ #define V4L2_CID_ROTATE (V4L2_CID_BASE+34) #define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35) +#define V4L2_CID_LED(V4L2_CID_BASE+36) +enum v4l2_led { +V4L2_LED_AUTO = 0, +V4L2_LED_ON = 1, +V4L2_LED_OFF= 2, +}; /* last CID + 1 */ -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36) +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+37) /* MPEG-class control IDs defined by V4L2 */ #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900) diff -r d8fafa7d88dc linux/drivers/media/video/v4l2-common.c --- a/linux/drivers/media/video/v4l2-common.c Thu Feb 18 19:02:51 2010 +0100 +++ b/linux/drivers/media/video/v4l2-common.c Sun Feb 28 08:41:17 2010 +0100 @@ -349,6 +349,12 @@ 75 useconds, NULL, }; + static const char *led[] = { + Auto, + On, + Off, + NULL, + }; switch (id) { case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ: @@ -389,6 +395,8 @@ return colorfx; case V4L2_CID_TUNE_PREEMPHASIS: return tune_preemphasis; + case V4L2_CID_LED: + return led; default: return NULL; } @@ -434,6 +442,7 @@ case V4L2_CID_COLORFX: return Color Effects; case V4L2_CID_ROTATE: return Rotate; case V4L2_CID_BG_COLOR: return Background color; + case V4L2_CID_LED: return Feedback LED; /* MPEG controls */ case V4L2_CID_MPEG_CLASS: return MPEG Encoder Controls; @@ -575,6 +584,7 @@ case V4L2_CID_EXPOSURE_AUTO: case V4L2_CID_COLORFX: case V4L2_CID_TUNE_PREEMPHASIS: + case V4L2_CID_LED: qctrl-type = V4L2_CTRL_TYPE_MENU; step = 1; break; diff -r d8fafa7d88dc linux/include/linux/videodev2.h --- a/linux/include/linux/videodev2.h Thu Feb 18 19:02:51 2010 +0100 +++ b/linux/include/linux/videodev2.h Sun Feb 28 08:41:17 2010 +0100 @@ -1030,8 +1030,14 @@ #define V4L2_CID_ROTATE(V4L2_CID_BASE+34) #define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35) +#define V4L2_CID_LED (V4L2_CID_BASE+36) +enum v4l2_led { + V4L2_LED_AUTO = 0, + V4L2_LED_ON = 1, + V4L2_LED_OFF= 2, +}; /* last CID + 1 */ -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36) +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+37) /* MPEG-class control IDs defined by V4L2 */ #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900) -- 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 2/3] gspca pac7302: add LED control
From: Márton Németh nm...@freemail.hu On Labtec Webcam 2200 there is a feedback LED which can be controlled independent from the streaming. The feedback LED can be used from user space application to show for example detected motion or to distinguish between the preview and on-air state of the video stream. The default value of the LED control is Auto which keeps the previous behaviour: LED is off when the stream is off, LED is on if the stream is on. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r d8fafa7d88dc linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Thu Feb 18 19:02:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Sun Feb 28 08:41:17 2010 +0100 @@ -6,6 +6,7 @@ * * Separated from Pixart PAC7311 library by Márton Németh * Camera button input handling by Márton Németh nm...@freemail.hu + * LED control by Márton Németh nm...@freemail.hu * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu * * This program is free software; you can redistribute it and/or modify @@ -62,6 +63,7 @@ 0 | 0xc6 | setwhitebalance() 0 | 0xc7 | setbluebalance() 0 | 0xdc | setbrightcont(), setcolors() +1 | 0x78 | set_streaming_led() 3 | 0x02 | setexposure() 3 | 0x10 | setgain() 3 | 0x11 | setcolors(), setgain(), setexposure(), sethvflip() @@ -91,6 +93,7 @@ unsigned char gain; unsigned char exposure; unsigned char autogain; + unsigned char led; __u8 hflip; __u8 vflip; u8 flags; @@ -126,6 +129,8 @@ static int sd_getgain(struct gspca_dev *gspca_dev, __s32 *val); static int sd_setexposure(struct gspca_dev *gspca_dev, __s32 val); static int sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val); +static int sd_setled(struct gspca_dev *gspca_dev, __s32 val); +static int sd_getled(struct gspca_dev *gspca_dev, __s32 *val); static const struct ctrl sd_ctrls[] = { /* This control is pac7302 only */ @@ -293,6 +298,20 @@ .set = sd_setvflip, .get = sd_getvflip, }, + { + { + .id = V4L2_CID_LED, + .type= V4L2_CTRL_TYPE_MENU, + .name= LED, + .minimum = 0, + .maximum = 2, /* 0: Auto, 1: On, 2: Off */ + .step= 1, +#define LED_DEF V4L2_LED_AUTO + .default_value = LED_DEF, + }, + .set = sd_setled, + .get = sd_getled, + }, }; static const struct v4l2_pix_format vga_mode[] = { @@ -572,6 +591,7 @@ sd-gain = GAIN_DEF; sd-exposure = EXPOSURE_DEF; sd-autogain = AUTOGAIN_DEF; + sd-led = LED_DEF; sd-hflip = HFLIP_DEF; sd-vflip = VFLIP_DEF; sd-flags = id-driver_info; @@ -716,6 +736,36 @@ reg_w(gspca_dev, 0x11, 0x01); } +static void set_streaming_led(struct gspca_dev *gspca_dev, u8 streaming) +{ + struct sd *sd = (struct sd *) gspca_dev; + u8 data = 0; + + switch (sd-led) { + case V4L2_LED_AUTO: + if (streaming) + data = 0x01; + else + data = 0x40; + break; + case V4L2_LED_ON: + if (streaming) + data = 0x01; + else + data = 0x00; + break; + case V4L2_LED_OFF: + if (streaming) + data = 0x41; + else + data = 0x40; + break; + } + + reg_w(gspca_dev, 0xff, 0x01); + reg_w(gspca_dev, 0x78, data); +} + /* this function is called at probe and resume time for pac7302 */ static int sd_init(struct gspca_dev *gspca_dev) { @@ -747,18 +797,15 @@ atomic_set(sd-avg_lum, -1); /* start stream */ - reg_w(gspca_dev, 0xff, 0x01); - reg_w(gspca_dev, 0x78, 0x01); + set_streaming_led(gspca_dev, 1); return gspca_dev-usb_err; } static void sd_stopN(struct gspca_dev *gspca_dev) { - /* stop stream */ - reg_w(gspca_dev, 0xff, 0x01); - reg_w(gspca_dev, 0x78, 0x00); + set_streaming_led(gspca_dev, 0); } /* called on streamoff with alt 0 and on disconnect for pac7302 */ @@ -766,8 +813,7 @@ { if (!gspca_dev-present) return; - reg_w(gspca_dev, 0xff, 0x01); - reg_w(gspca_dev, 0x78, 0x40); + set_streaming_led(gspca_dev, 0); } /* Include pac common sof detection functions */ @@ -1121,6 +1167,44 @@ return 0; } +static int sd_setled(struct gspca_dev *gspca_dev, __s32 val) +{ + struct sd *sd = (struct sd *) gspca_dev; + + sd-led = val; + set_streaming_led(gspca_dev, gspca_dev-streaming); + return gspca_dev-usb_err; +} + +static int sd_getled(struct gspca_dev *gspca_dev, __s32 *val) +{ + struct sd *sd = (struct sd *) gspca_dev; + +
[PATCH 3/3] gspca pac7302: remove LED blinking when switching stream on and off
From: Márton Németh nm...@freemail.hu The init sequences for PAC7302 contained register settings affecting the LED state which can result blinking of the LED when it is set to always on or always off. The blinking happened when the stream was switched on or off. Remove the register changes from the init sequence and handle it with the function set_streaming_led(). Signed-off-by: Márton Németh nm...@freemail.hu --- --- a/linux/drivers/media/video/gspca/pac7302.c.orig2010-02-28 08:39:30.0 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c 2010-02-28 08:44:18.0 +0100 @@ -326,13 +326,6 @@ #define END_OF_SEQUENCE0 /* pac 7302 */ -static const __u8 init_7302[] = { -/* index,value */ - 0xff, 0x01, /* page 1 */ - 0x78, 0x00, /* deactivate */ - 0xff, 0x01, - 0x78, 0x40, /* led off */ -}; static const __u8 start_7302[] = { /* index, len, [value]* */ 0xff, 1,0x00, /* page 0 */ @@ -368,7 +361,8 @@ 0xff, 1,0x01, /* page 1 */ 0x12, 3,0x02, 0x00, 0x01, 0x3e, 2,0x00, 0x00, - 0x76, 5,0x01, 0x20, 0x40, 0x00, 0xf2, + 0x76, 2,0x01, 0x20, + 0x79, 2,0x00, 0xf2, 0x7c, 1,0x00, 0x7f, 10, 0x4b, 0x0f, 0x01, 0x2c, 0x02, 0x58, 0x03, 0x20, 0x02, 0x00, @@ -392,8 +386,6 @@ 0x2a, 5,0xc8, 0x00, 0x18, 0x12, 0x22, 0x64, 8,0x00, 0x00, 0xf0, 0x01, 0x14, 0x44, 0x44, 0x44, 0x6e, 1,0x08, - 0xff, 1,0x01, /* page 1 */ - 0x78, 1,0x00, 0, END_OF_SEQUENCE /* end of sequence */ }; @@ -491,15 +483,6 @@ } } -static void reg_w_seq(struct gspca_dev *gspca_dev, - const __u8 *seq, int len) -{ - while (--len = 0) { - reg_w(gspca_dev, seq[0], seq[1]); - seq += 2; - } -} - /* load the beginning of a page */ static void reg_w_page(struct gspca_dev *gspca_dev, const __u8 *page, int len) @@ -769,7 +752,7 @@ /* this function is called at probe and resume time for pac7302 */ static int sd_init(struct gspca_dev *gspca_dev) { - reg_w_seq(gspca_dev, init_7302, sizeof(init_7302)/2); + set_streaming_led(gspca_dev, 0); return gspca_dev-usb_err; } -- 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/2] gspca pac7302: allow controlling LED separately
From: Márton Németh nm...@freemail.hu On Labtec Webcam 2200 there is a feedback LED which can be controlled independent from the streaming. The feedback LED can be used from user space application to show for example detected motion or to distinguish between the preview and on-air state of the video stream. The default value of the LED trigger keeps the previous behaviour: LED is off when the stream is off, LED is on if the stream is on. The code is working in the following three cases: (1) when the LED subsystem ins not configured at all; (2) when the LED subsystem is available, but the LED triggers are not available and (3) when both the LED subsystem and LED triggers are configured. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 4f102b2f7ac1 linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Thu Jan 28 20:35:40 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Sat Feb 27 00:57:32 2010 +0100 @@ -6,6 +6,7 @@ * * Separated from Pixart PAC7311 library by Márton Németh * Camera button input handling by Márton Németh nm...@freemail.hu + * LED control by Márton Németh nm...@freemail.hu * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu * * This program is free software; you can redistribute it and/or modify @@ -62,6 +63,7 @@ 0 | 0xc6 | setwhitebalance() 0 | 0xc7 | setbluebalance() 0 | 0xdc | setbrightcont(), setcolors() +1 | 0x78 | set_streaming_led() 3 | 0x02 | setexposure() 3 | 0x10 | setgain() 3 | 0x11 | setcolors(), setgain(), setexposure(), sethvflip() @@ -72,6 +74,8 @@ #include linux/input.h #include media/v4l2-chip-ident.h +#include linux/leds.h +#include linux/workqueue.h #include gspca.h MODULE_AUTHOR(Thomas Kaiser tho...@kaiser-linux.li); @@ -91,6 +95,7 @@ unsigned char gain; unsigned char exposure; unsigned char autogain; + unsigned char led; __u8 hflip; __u8 vflip; u8 flags; @@ -101,6 +106,16 @@ u8 autogain_ignore_frames; atomic_t avg_lum; + +#ifdef CONFIG_LEDS_CLASS + struct led_classdev led_cdev; + struct work_struct led_work; + char name[32]; +#ifdef CONFIG_LEDS_TRIGGERS + struct led_trigger led_trigger; + char trigger_name[32]; +#endif +#endif }; /* V4L2 controls supported by the driver */ @@ -572,6 +587,7 @@ sd-gain = GAIN_DEF; sd-exposure = EXPOSURE_DEF; sd-autogain = AUTOGAIN_DEF; + sd-led = 0; sd-hflip = HFLIP_DEF; sd-vflip = VFLIP_DEF; sd-flags = id-driver_info; @@ -716,6 +732,58 @@ reg_w(gspca_dev, 0x11, 0x01); } +static void set_streaming_led(struct gspca_dev *gspca_dev, u8 streaming) +{ + struct sd *sd = (struct sd *) gspca_dev; + u8 data = 0; + + if (sd-led) { + if (streaming) + data = 0x01; + else + data = 0x00; + } else { + if (streaming) + data = 0x41; + else + data = 0x40; + } + + reg_w(gspca_dev, 0xff, 0x01); + reg_w(gspca_dev, 0x78, data); +} + +#ifdef CONFIG_LEDS_CLASS +/* Set the LED, may sleep */ +static void led_work(struct work_struct *work) +{ + struct sd *sd = container_of(work, struct sd, led_work); + struct gspca_dev *gspca_dev = sd-gspca_dev; + + mutex_lock(gspca_dev-usb_lock); + set_streaming_led(gspca_dev, gspca_dev-streaming); + mutex_unlock(gspca_dev-usb_lock); +} + +/* LED state set request, must not sleep */ +static void led_set(struct led_classdev *led_cdev, + enum led_brightness value) +{ + u8 new_value; + struct sd *sd = container_of(led_cdev, struct sd, led_cdev); + + if (value == LED_OFF) + new_value = 0; + else + new_value = 1; + + if (sd-led != new_value) { + sd-led = new_value; + schedule_work(sd-led_work); + } +} +#endif + /* this function is called at probe and resume time for pac7302 */ static int sd_init(struct gspca_dev *gspca_dev) { @@ -747,27 +815,60 @@ atomic_set(sd-avg_lum, -1); /* start stream */ - reg_w(gspca_dev, 0xff, 0x01); - reg_w(gspca_dev, 0x78, 0x01); + +#if defined(CONFIG_LEDS_CLASS) defined(CONFIG_LEDS_TRIGGERS) + led_trigger_event(sd-led_trigger, LED_FULL); +#elif defined(CONFIG_LEDS_CLASS) + sd-led_cdev.brightness = sd-led_cdev.max_brightness; + if (!(sd-led_cdev.flags LED_SUSPENDED)) + sd-led_cdev.brightness_set(sd-led_cdev, + sd-led_cdev.brightness); +#else + sd-led = 1; +#endif + set_streaming_led(gspca_dev, 1); return gspca_dev-usb_err; } static void sd_stopN(struct gspca_dev *gspca_dev) { + struct sd *sd = container_of(gspca_dev, struct sd,
[PATCH 2/2] gspca pac7302: remove LED blinking when switching stream on and off
From: Márton Németh nm...@freemail.hu The init sequences for PAC7302 contained register settings affecting the LED state which can result blinking of the LED when it is set to always on or always off. The blinking happened when the stream was switched on or off. Remove the register changes from the init sequence and handle it with the function set_streaming_led(). Signed-off-by: Márton Németh nm...@freemail.hu --- --- a/linux/drivers/media/video/gspca/pac7302.c.orig2010-02-27 01:00:30.0 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c 2010-02-27 01:00:49.0 +0100 @@ -322,13 +322,6 @@ #define END_OF_SEQUENCE0 /* pac 7302 */ -static const __u8 init_7302[] = { -/* index,value */ - 0xff, 0x01, /* page 1 */ - 0x78, 0x00, /* deactivate */ - 0xff, 0x01, - 0x78, 0x40, /* led off */ -}; static const __u8 start_7302[] = { /* index, len, [value]* */ 0xff, 1,0x00, /* page 0 */ @@ -364,7 +357,8 @@ 0xff, 1,0x01, /* page 1 */ 0x12, 3,0x02, 0x00, 0x01, 0x3e, 2,0x00, 0x00, - 0x76, 5,0x01, 0x20, 0x40, 0x00, 0xf2, + 0x76, 2,0x01, 0x20, + 0x79, 2,0x00, 0xf2, 0x7c, 1,0x00, 0x7f, 10, 0x4b, 0x0f, 0x01, 0x2c, 0x02, 0x58, 0x03, 0x20, 0x02, 0x00, @@ -388,8 +382,6 @@ 0x2a, 5,0xc8, 0x00, 0x18, 0x12, 0x22, 0x64, 8,0x00, 0x00, 0xf0, 0x01, 0x14, 0x44, 0x44, 0x44, 0x6e, 1,0x08, - 0xff, 1,0x01, /* page 1 */ - 0x78, 1,0x00, 0, END_OF_SEQUENCE /* end of sequence */ }; @@ -487,15 +479,6 @@ } } -static void reg_w_seq(struct gspca_dev *gspca_dev, - const __u8 *seq, int len) -{ - while (--len = 0) { - reg_w(gspca_dev, seq[0], seq[1]); - seq += 2; - } -} - /* load the beginning of a page */ static void reg_w_page(struct gspca_dev *gspca_dev, const __u8 *page, int len) @@ -787,7 +770,7 @@ /* this function is called at probe and resume time for pac7302 */ static int sd_init(struct gspca_dev *gspca_dev) { - reg_w_seq(gspca_dev, init_7302, sizeof(init_7302)/2); + set_streaming_led(gspca_dev, 0); return gspca_dev-usb_err; } -- 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
Linux testers wanted for Genius iSlim 310
Hi, based on the information from installing the Windows driver the Genius iSlim 310 is a potential candidate that the gspca_pac7302 driver under Linux may handle, see http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302#Identification . If you have access to Genius iSlim 310 and would like to give a try please apply the patch in this email, compile and install the patched kernel, check dmesg for messages and try whether the webcam is working for example with cheese. Regards, Márton Németh --- From: Márton Németh nm...@freemail.hu On the schematics in PixArt PAC7301/PAC7302 datasheet (http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf) pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes the possible product ID range 0x2620..0x262f. In this range there are some known webcams, however, there are some PIDs with unknown or future devices. Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is probable that this driver will work correctly independent of the used PID. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r dfa82cf98a85 linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Sat Jan 30 20:03:02 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 31 11:08:21 2010 +0100 @@ -96,6 +96,7 @@ u8 flags; #define FL_HFLIP 0x01 /* mirrored by default */ #define FL_VFLIP 0x02 /* vertical flipped by default */ +#define FL_EXPERIMENTAL 0x80 /* USB IDs based on heuristic without any known product */ u8 sof_read; u8 autogain_ignore_frames; @@ -1220,17 +1221,33 @@ }; /* -- module initialisation -- */ +/* Note on FL_EXPERIMENTAL: + * On the schematics in PixArt PAC7301/PAC7302 datasheet + * (http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf) + * pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes + * the possible product ID range 0x2620..0x262f. In this range there are some + * known webcams, however, there are some PIDs with unknown or future devices. + * Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is + * probable that this driver will work correctly independent of the used PID. + */ static const struct usb_device_id device_table[] __devinitconst = { {USB_DEVICE(0x06f8, 0x3009)}, {USB_DEVICE(0x093a, 0x2620)}, {USB_DEVICE(0x093a, 0x2621)}, {USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP}, + {USB_DEVICE(0x093a, 0x2623), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP}, + {USB_DEVICE(0x093a, 0x2625), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x2626)}, + {USB_DEVICE(0x093a, 0x2627), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x2628)}, {USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP}, {USB_DEVICE(0x093a, 0x262a)}, + {USB_DEVICE(0x093a, 0x262b), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x262c)}, + {USB_DEVICE(0x093a, 0x262d), .driver_info = FL_EXPERIMENTAL }, + {USB_DEVICE(0x093a, 0x262e), .driver_info = FL_EXPERIMENTAL }, + {USB_DEVICE(0x093a, 0x262f), .driver_info = FL_EXPERIMENTAL }, {} }; MODULE_DEVICE_TABLE(usb, device_table); @@ -1239,6 +1256,17 @@ static int __devinit sd_probe(struct usb_interface *intf, const struct usb_device_id *id) { + if ((u8)id-driver_info FL_EXPERIMENTAL) { + PDEBUG(D_ERR | D_PROBE, WARNING: USB device ID %04x:%04x is + not known, but based on some heuristics this driver + tries to handle it., + id-idVendor, id-idProduct); + PDEBUG(D_ERR | D_PROBE, WARNING: Plase send an email to + linux-media@vger.kernel.org with 'lsusb -v' output, + the vendor and name of the product and whether the + device is working or not.); + } + return gspca_dev_probe(intf, id, sd_desc, sizeof(struct sd), THIS_MODULE); } -- 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] soc_camera: match signedness of soc_camera_limit_side()
Hi Guennadi, Guennadi Liakhovetski wrote: Hi Németh On Tue, 9 Feb 2010, Guennadi Liakhovetski wrote: Ok, I modified your patch a bit, how about the below version? If you agree, I'll commit it in that form (after converting to utf-8): From: Márton Németh nm...@freemail.hu The first two parameters of soc_camera_limit_side() are usually pointers to struct v4l2_rect elements. They are signed, so adjust the prototype accordingly. This will remove the following sparse warning (see make C=1): * incorrect type in argument 1 (different signedness) expected unsigned int *start got signed int *noident as well as a couple more signedness mismatches. Signed-off-by: Márton Németh nm...@freemail.hu Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de please confirm, if you agree with my version of your patch, or I'll have to leave it out from my pull request. I confirm. Sorry about the late response, I was not able to access my emails for a while. Regards, Márton Németh --- diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 1a34d29..e5bae4c 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -325,7 +325,7 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) if (ret 0) return ret; -dev_dbg(client-dev, Frame %ux%u pixel\n, rect.width, rect.height); +dev_dbg(client-dev, Frame %dx%d pixel\n, rect.width, rect.height); mt9v022-rect = rect; diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c index bd297f5..d477e30 100644 --- a/drivers/media/video/mx3_camera.c +++ b/drivers/media/video/mx3_camera.c @@ -796,7 +796,7 @@ static int acquire_dma_channel(struct mx3_camera_dev *mx3_cam) * FIXME: learn to use stride != width, then we can keep stride properly aligned * and support arbitrary (even) widths. */ -static inline void stride_align(__s32 *width) +static inline void stride_align(__u32 *width) { if (((*width + 7) ~7) 4096) *width = (*width + 7) ~7; @@ -844,7 +844,7 @@ static int mx3_camera_set_crop(struct soc_camera_device *icd, * So far only direct camera-to-memory is supported */ if (channel_change_requested(icd, rect)) { -int ret = acquire_dma_channel(mx3_cam); +ret = acquire_dma_channel(mx3_cam); if (ret 0) return ret; } diff --git a/drivers/media/video/rj54n1cb0c.c b/drivers/media/video/rj54n1cb0c.c index 9277194..bbd9c11 100644 --- a/drivers/media/video/rj54n1cb0c.c +++ b/drivers/media/video/rj54n1cb0c.c @@ -555,15 +555,15 @@ static int rj54n1_commit(struct i2c_client *client) return ret; } -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h, - u32 *out_w, u32 *out_h); +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h, + s32 *out_w, s32 *out_h); static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) { struct i2c_client *client = sd-priv; struct rj54n1 *rj54n1 = to_rj54n1(client); struct v4l2_rect *rect = a-c; -unsigned int dummy = 0, output_w, output_h, +int dummy = 0, output_w, output_h, input_w = rect-width, input_h = rect-height; int ret; @@ -577,7 +577,7 @@ static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) output_w = (input_w * 1024 + rj54n1-resize / 2) / rj54n1-resize; output_h = (input_h * 1024 + rj54n1-resize / 2) / rj54n1-resize; -dev_dbg(client-dev, Scaling for %ux%u : %u = %ux%u\n, +dev_dbg(client-dev, Scaling for %dx%d : %u = %dx%d\n, input_w, input_h, rj54n1-resize, output_w, output_h); ret = rj54n1_sensor_scale(sd, input_w, input_h, output_w, output_h); @@ -638,8 +638,8 @@ static int rj54n1_g_fmt(struct v4l2_subdev *sd, * the output one, updates the window sizes and returns an error or the resize * coefficient on success. Note: we only use the Fixed Scaling on this camera. */ -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h, - u32 *out_w, u32 *out_h) +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h, + s32 *out_w, s32 *out_h) { struct i2c_client *client = sd-priv; struct rj54n1 *rj54n1 = to_rj54n1(client); @@ -749,7 +749,7 @@ static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h, * improve the image quality or stability for larger frames (see comment * above), but I didn't check the framerate. */ -skip = min(resize / 1024, (unsigned)15); +skip = min(resize / 1024, 15U); inc_sel = 1 skip; @@ -819,7 +819,7 @@
[PATCH] gspca pac7302: add USB PID range based on heuristics
From: Márton Németh nm...@freemail.hu On the schematics in PixArt PAC7301/PAC7302 datasheet (http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf) pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes the possible product ID range 0x2620..0x262f. In this range there are some known webcams, however, there are some PIDs with unknown or future devices. Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is probable that this driver will work correctly independent of the used PID. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r dfa82cf98a85 linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Sat Jan 30 20:03:02 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 31 11:08:21 2010 +0100 @@ -96,6 +96,7 @@ u8 flags; #define FL_HFLIP 0x01 /* mirrored by default */ #define FL_VFLIP 0x02 /* vertical flipped by default */ +#define FL_EXPERIMENTAL 0x80 /* USB IDs based on heuristic without any known product */ u8 sof_read; u8 autogain_ignore_frames; @@ -1220,17 +1221,33 @@ }; /* -- module initialisation -- */ +/* Note on FL_EXPERIMENTAL: + * On the schematics in PixArt PAC7301/PAC7302 datasheet + * (http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf) + * pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes + * the possible product ID range 0x2620..0x262f. In this range there are some + * known webcams, however, there are some PIDs with unknown or future devices. + * Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is + * probable that this driver will work correctly independent of the used PID. + */ static const struct usb_device_id device_table[] __devinitconst = { {USB_DEVICE(0x06f8, 0x3009)}, {USB_DEVICE(0x093a, 0x2620)}, {USB_DEVICE(0x093a, 0x2621)}, {USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP}, + {USB_DEVICE(0x093a, 0x2623), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP}, + {USB_DEVICE(0x093a, 0x2625), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x2626)}, + {USB_DEVICE(0x093a, 0x2627), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x2628)}, {USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP}, {USB_DEVICE(0x093a, 0x262a)}, + {USB_DEVICE(0x093a, 0x262b), .driver_info = FL_EXPERIMENTAL }, {USB_DEVICE(0x093a, 0x262c)}, + {USB_DEVICE(0x093a, 0x262d), .driver_info = FL_EXPERIMENTAL }, + {USB_DEVICE(0x093a, 0x262e), .driver_info = FL_EXPERIMENTAL }, + {USB_DEVICE(0x093a, 0x262f), .driver_info = FL_EXPERIMENTAL }, {} }; MODULE_DEVICE_TABLE(usb, device_table); @@ -1239,6 +1256,17 @@ static int __devinit sd_probe(struct usb_interface *intf, const struct usb_device_id *id) { + if ((u8)id-driver_info FL_EXPERIMENTAL) { + PDEBUG(D_ERR | D_PROBE, WARNING: USB device ID %04x:%04x is + not known, but based on some heuristics this driver + tries to handle it., + id-idVendor, id-idProduct); + PDEBUG(D_ERR | D_PROBE, WARNING: Plase send an email to + linux-media@vger.kernel.org with 'lsusb -v' output, + the vendor and name of the product and whether the + device is working or not.); + } + return gspca_dev_probe(intf, id, sd_desc, sizeof(struct sd), THIS_MODULE); } -- 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 libv4l tree, RFC] libv4l: skip false Pixart markers with buffer copy
Hi, This is a proof-of-concept patch to try to decode the JPEG with PixArt markers. Please check whether it is working at your side. My experience is that the number of frames with glitch are reduced. Regards, Márton Németh --- From: Márton Németh nm...@freemail.hu Before trying to decode the image data filter the PixArt markers out. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 966f60c672e9 v4l2-apps/libv4l/libv4lconvert/tinyjpeg-internal.h --- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg-internal.hTue Feb 02 11:34:06 2010 +0100 +++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg-internal.hThu Feb 04 09:13:24 2010 +0100 @@ -91,8 +91,11 @@ /* Private variables */ const unsigned char *stream_begin, *stream_end; unsigned int stream_length; + unsigned char *stream_begin_filtered, *stream_end_filtered; + unsigned int stream_length_filtered; const unsigned char *stream; /* Pointer to the current stream */ + unsigned char *stream_filtered; unsigned int reservoir, nbits_in_reservoir; struct component component_infos[COMPONENTS]; diff -r 966f60c672e9 v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c --- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Tue Feb 02 11:34:06 2010 +0100 +++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Thu Feb 04 09:13:24 2010 +0100 @@ -312,19 +312,18 @@ /* Special Pixart versions of the *_nbits functions, these remove the special ff ff ff xx sequences pixart cams insert from the bitstream */ -#define pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted) \ +#define pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,stream_end,nbits_wanted) \ do { \ while (nbits_in_reservoirnbits_wanted) \ { \ unsigned char c; \ - if (stream = priv-stream_end) { \ + if (stream = stream_end) { \ snprintf(priv-error_string, sizeof(priv-error_string), \ fill_nbits error: need %u more bits\n, \ nbits_wanted - nbits_in_reservoir); \ longjmp(priv-jump_state, -EIO); \ } \ c = *stream++; \ - reservoir = 8; \ if (c == 0xff) { \ switch (stream[0]) { \ case 0x00: \ @@ -332,7 +331,7 @@ break; \ case 0xd9: /* EOF marker */ \ stream++; \ - if (stream != priv-stream_end) { \ + if (stream != stream_end) { \ snprintf(priv-error_string, sizeof(priv-error_string), \ Pixart JPEG error: premature EOF\n); \ longjmp(priv-jump_state, -EIO); \ @@ -340,14 +339,22 @@ break; \ case 0xff: \ if (stream[1] == 0xff) { \ - if (stream[2] 7) { \ + if (stream[2] == 0) { \ + stream += 3; \ + c = *stream++; \ + break; \ + } else if (stream[2] == 1) { \ + stream += 3; \ + c = *stream++; \ + break; \ + } else if (stream[2] == 2) { \ stream += 3; \ c = *stream++; \ break; \ } else if (stream[2] == 0xff) { \ - /* four 0xff in a row: the first belongs to the image data */ \ + /* four 0xff in a row: the first belongs to the image */ \ break; \ - }\ + } \ } \ /* Error fall through */ \ default: \ @@ -358,15 +365,16 @@ longjmp(priv-jump_state, -EIO); \ } \ } \ + reservoir = 8; \ reservoir |= c; \ nbits_in_reservoir+=8; \ } \ } while(0); /* Signed version */ -#define pixart_get_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted,result) \ +#define pixart_get_nbits(reservoir,nbits_in_reservoir,stream,stream_end,nbits_wanted,result) \ do { \ - pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,(nbits_wanted)); \ + pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,stream_end,(nbits_wanted)); \ result = ((reservoir)(nbits_in_reservoir-(nbits_wanted))); \ nbits_in_reservoir -= (nbits_wanted); \ reservoir = ((1Unbits_in_reservoir)-1); \ @@ -374,9 +382,9 @@ result += (0xUL(nbits_wanted))+1; \ } while(0); -#define pixart_look_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted,result) \ +#define pixart_look_nbits(reservoir,nbits_in_reservoir,stream,stream_end,nbits_wanted,result) \ do { \ - pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,(nbits_wanted)); \ + pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,stream_end,(nbits_wanted)); \ result = ((reservoir)(nbits_in_reservoir-(nbits_wanted))); \ } while(0); @@ -443,7 +451,8 @@ unsigned int extra_nbits, nbits; uint16_t *slowtable; - pixart_look_nbits(priv-reservoir, priv-nbits_in_reservoir, priv-stream, HUFFMAN_HASH_NBITS, hcode); + pixart_look_nbits(priv-reservoir, priv-nbits_in_reservoir,
Re: [PATCH ] libv4l: skip false Pixart markers
Hans de Goede wrote: Hi, On 02/01/2010 11:13 PM, Németh Márton wrote: From: Márton Némethnm...@freemail.hu The byte sequence 0xff, 0xff, 0xff 0xff is not a real marker to skip, instead it is one byte from the image and the following three 0xff bytes might belong to a real marker. Modify pixart_fill_nbits() macro to pass the first 0xff byte as an image data. Oh, good catch. I'm still seeing the occasional bad frame though :( The same at my side, this patch alone does not solve the whole problem complete. I have the feeling that at least same of the corrupted frames will not come with this patch, through I haven't verified this with measurement. On the other hand, in my previous email used a little bit different code: I jumped over the 1024 and 512 bytes without parsing it. That would be maybe necessary to add. By the way, is there any reason why pixart_fill_nbits() is a macro? While on the subject of the pac7302. I've been playing around a bit, and I have the feeling that if we were to go for a lower auto gain target (set autogain off and lower exposure, you can do this ie with v4l2ucp), combined with a gamma correction of 1500 (again use ie v4l2ucp), the images is much better (less over exposed, more contrast). Do you agree ? Well, my Labtec Webcam 2200 works only with acceptable indoors, when I try to capture something outdoors under direct sunshine conditions I get overexposed frames. I found, however, an interesting pointer in two cameras' user's manual, see the Note column: http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302#Identification There is a setting indoor/outdoor which is currently not available in gspca_pac7302 driver. Maybe this would be an interesting point to figure out which register is related to this setting. Regards, Márton Németh Signed-off-by: Márton Némethnm...@freemail.hu --- diff -r f23c5a878fb1 v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c --- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Mon Feb 01 13:32:46 2010 +0100 +++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Mon Feb 01 23:05:39 2010 +0100 @@ -339,10 +339,15 @@ } \ break; \ case 0xff: \ -if (stream[1] == 0xff (stream[2] 7 || stream[2] == 0xff)) { \ - stream += 3; \ - c = *stream++; \ - break; \ +if (stream[1] == 0xff) { \ +if (stream[2] 7) { \ +stream += 3; \ +c = *stream++; \ +break; \ +} else if (stream[2] == 0xff) { \ +/* four 0xff in a row: the first belongs to the image data */ \ +break; \ +}\ } \ /* Error fall through */ \ default: \ -- 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: possible problem found in PAC7302 JPEG decoding
Hi Thomas, Thomas Kaiser wrote: On 02/01/2010 10:23 PM, Németh Márton wrote: Hello Hans, while I was dealing with Labtec Webcam 2200 and with gspca_pac7302 driver I recognised the following behaviour. The stream received from the webcam is splitted by the gspca_pac7302 subdriver when the byte sequence 0xff, 0xff, 0x00, 0xff, 0x96 is found (pac_find_sof()). Before transmitting the data to the userspace a JPEG header is added (pac_start_frame()) and the footer after the bytes 0xff, 0xd9 are removed. The data buffer which arrives to userspace looks like as follows (maybe not every detail is exact): 1. JPEG header 2. Some bytes of image data (near to 1024 bytes) 3. The byte sequence 0xff, 0xff, 0xff, 0x01 followed by 1024 bytes of data. This marker sequence and data repeats a couple of time. Exactly how much depends on the image content. 4. The byte sequence 0xff, 0xff, 0xff, 0x02 followed by 512 bytes of data. This marker sequence and data also repeats a couple of time. 5. The byte sequence 0xff, 0xff, 0xff, 0x00 followed by a variable amount of image data bytes. 6. The End of Image (EOI) marker 0xff, 0xd9. Now what can be wrong with the libv4l? In libv4lconvert/tinyjpeg.c, line 315 there is a huge macro which tries to remove the 0xff, 0xff, 0xff, xx byte sequence from the received image. This fails, however, if the image contains 0xff bytes just before the 0xff, 0xff, 0xff, xx sequence because one byte from the image data (the first 0xff) is removed, then the three 0xff bytes from the marker is also removed. The xx (which really belongs to the marker) is left in the image data instead of the original 0xff byte. Based on my experiments this problem sometimes causes corrupted image decoding or that the JPEG image cannot be decoded at all. Hello Németh I remember the problem as I was working on the PAC7311. http://www.kaiser-linux.li/index.php?title=PAC7311 This is the code I used in the JPEG decoder to remove the 0xff 0xff 0xff 0xnn markers. See http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz decoder/gspcadecoder.c pac7311_decode() Do you remember whether this code was working properly always? Regards, Márton Németh -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hi, Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. [snip] Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log linux-2.6.16.62-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:48:29: error: linux/usb/input.h: No such file or directory /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:182: warning: implicit declaration of function 'usb_to_input_id' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: request for member 'parent' in something not a structure or union /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: request for member 'parent' in something not a structure or union linux-2.6.17.14-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:48:29: error: linux/usb/input.h: No such file or directory /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:182: warning: implicit declaration of function 'usb_to_input_id' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: request for member 'parent' in something not a structure or union /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: request for member 'parent' in something not a structure or union linux-2.6.18.8-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: request for member 'parent' in something not a structure or union /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: request for member 'parent' in something not a structure or union linux-2.6.19.7-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: 'struct input_dev' has no member named 'dev' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: 'struct input_dev' has no member named 'dev' linux-2.6.20.21-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: 'struct input_dev' has no member named 'dev' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: 'struct input_dev' has no member named 'dev' linux-2.6.21.7-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: 'struct input_dev' has no member named 'dev' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: 'struct input_dev' has no member named 'dev' It seems that the camera button input support is not compatible with kernel version 2.6.21.7 and before because of different reasons. 1. Between 2.6.16.62 and 2.6.17.14: there is no linux/usb/input.h . The linux/usb/input.h was earlier linux/usb_input.h, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=include/linux/usb/input.h;h=0e010b220e85b3f9ea861f2ab009809d17014910;hb=HEAD 2. Between 2.6.16.62 and 2.6.17.14: there is no 'usb_to_input_id'. This was introduced with the commit 16a334c0de5a94b1d10a1ac9a33f4dedac89a075, exactly in the same place: in linux/usb_input.h . http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=16a334c0de5a94b1d10a1ac9a33f4dedac89a075 3. Between 2.6.16.62 and 2.6.18.8: there is no 'parent' field of struct device. The struct device is defined in linux/device.h . I couldn't find what exactly happened here, yet. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=include/linux/device.h;h=a62799f2ab0019863d30e4f55f7677c5bd97d124;hb=HEAD 4. Between linux-2.6.19.7 and 2.6.21.7: 'struct input_dev' has no member named 'dev'. The 'dev' member was introduced with commit 9657d75c5f0f7d0a9cb507521d3ad1436aea28c9 when a convert was made from class devices to standard devices. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9657d75c5f0f7d0a9cb507521d3ad1436aea28c9 The main question is that does gspca need to support kernel version 2.6.21.7 and before? If yes, then should the input support disabled in 2.6.21.7 and before? Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
libv4l: possible problem found in PAC7302 JPEG decoding
Hello Hans, while I was dealing with Labtec Webcam 2200 and with gspca_pac7302 driver I recognised the following behaviour. The stream received from the webcam is splitted by the gspca_pac7302 subdriver when the byte sequence 0xff, 0xff, 0x00, 0xff, 0x96 is found (pac_find_sof()). Before transmitting the data to the userspace a JPEG header is added (pac_start_frame()) and the footer after the bytes 0xff, 0xd9 are removed. The data buffer which arrives to userspace looks like as follows (maybe not every detail is exact): 1. JPEG header 2. Some bytes of image data (near to 1024 bytes) 3. The byte sequence 0xff, 0xff, 0xff, 0x01 followed by 1024 bytes of data. This marker sequence and data repeats a couple of time. Exactly how much depends on the image content. 4. The byte sequence 0xff, 0xff, 0xff, 0x02 followed by 512 bytes of data. This marker sequence and data also repeats a couple of time. 5. The byte sequence 0xff, 0xff, 0xff, 0x00 followed by a variable amount of image data bytes. 6. The End of Image (EOI) marker 0xff, 0xd9. Now what can be wrong with the libv4l? In libv4lconvert/tinyjpeg.c, line 315 there is a huge macro which tries to remove the 0xff, 0xff, 0xff, xx byte sequence from the received image. This fails, however, if the image contains 0xff bytes just before the 0xff, 0xff, 0xff, xx sequence because one byte from the image data (the first 0xff) is removed, then the three 0xff bytes from the marker is also removed. The xx (which really belongs to the marker) is left in the image data instead of the original 0xff byte. Based on my experiments this problem sometimes causes corrupted image decoding or that the JPEG image cannot be decoded at all. I have done my experiments with a modified gspca_pac7302 kernel space driver (the JPEG header is not added and the footer is not removed). In userspace I added the JPEG header and then applied the following filter function to the received data. The result is that I do not get any corrupted frame anymore. The filter function in userspace is based on a state machine like this: static int memcpy_filter(unsigned char *dest, unsigned char *src, int n) { int i = 0; int j = 0; int state = 0; int last_i = 0; i = 5; j = 0; /* Skip the first 5 bytes: 0xff 0xff 0x00 0xff 0x96 */ memcpy((dest[j]), (src[i]), 1024-5); i += 1024-5; j += 1024-5; while (i n) { switch (state) { case 0: if (src[i] == 0xff) state = 1; else { state = 0; dest[j++] = src[i]; } break; case 1: if (src[i] == 0xff) state = 2; else { state = 0; dest[j++] = src[i-1]; dest[j++] = src[i]; } break; case 2: switch (src[i]) { case 0xff: state = 3; break; default: state = 0; dest[j++] = src[i-2]; dest[j++] = src[i-1]; dest[j++] = src[i]; } break; case 3: switch (src[i]) { case 0: /* found 0xff 0xff 0xff 0x00 */ state = 0; break; case 1: /* found 0xff 0xff 0xff 0x01 */ last_i = i+1; memcpy((dest[j]), (src[i+1]), 1024); i += 1024; j += 1024; state = 0; break; case 2: /* found 0xff 0xff 0xff 0x02 */ last_i = i+1;
[PATCH ] libv4l: skip false Pixart markers
From: Márton Németh nm...@freemail.hu The byte sequence 0xff, 0xff, 0xff 0xff is not a real marker to skip, instead it is one byte from the image and the following three 0xff bytes might belong to a real marker. Modify pixart_fill_nbits() macro to pass the first 0xff byte as an image data. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r f23c5a878fb1 v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c --- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Mon Feb 01 13:32:46 2010 +0100 +++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Mon Feb 01 23:05:39 2010 +0100 @@ -339,10 +339,15 @@ } \ break; \ case 0xff: \ - if (stream[1] == 0xff (stream[2] 7 || stream[2] == 0xff)) { \ - stream += 3; \ - c = *stream++; \ - break; \ + if (stream[1] == 0xff) { \ + if (stream[2] 7) { \ + stream += 3; \ + c = *stream++; \ + break; \ + } else if (stream[2] == 0xff) { \ + /* four 0xff in a row: the first belongs to the image data */ \ + break; \ + }\ } \ /* Error fall through */ \ default: \ -- 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: PAC7302 short datasheet from PixArt
Hi, Theodore Kilgore wrote: On Sat, 30 Jan 2010, Németh Márton wrote: Hi, if anyone interested there is a brief overview datasheet about PixArt PAC7301/PAC7302 at http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf [...] Now, as to the substance of the mail above, thanks a lot. I had a bunch of the PixArt datasheets already, but I had missed that one. I would have a question, though: This datasheet gives a lot of information about pinouts on the sensor chip and such good stuff which might be useful if one were constructing a circuit board on which to put the chip. What it does not give, very unfortunately, is any information about the command set which needs to be sent across the USB connection, which in turn actuates the circuits which in turn sends something to the sensor across one of those pins. For example, to set green gain one has to do something on connector X. But how does one send a command from the computer which does something on connector X? Some other datasheets from some other companies (Omnivision, for example) do seem occasionally to provide such information. Thus, a question for you or for anyone else who reads it: Has anyone figured out any shortcuts for matching up the missing pieces of information? Probably the answer is no but I think this is the kind of question which is worth asking again on some periodic basis. I have created some notes about my experiments, but they are only based on trial-and-error. I started to created a PixArt PAC7301/PAC7302 Wiki page this morning but the communication protocol details I could found out is not yet finished. The page can be found at http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302 . I hope I'll have the time to add a section about the communication protocol details I could find out from the current gspca_pac7302 driver source code and my experiments. Regards, Márton Németh -- 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
pac7302 sporadic plug-in problem fix for 2.6.33?
Dear Jean-Francois and Mauro, I just compiled the vanilla 2.6.33-rc6 kernel and tested together with Labtec Webcam 2200. I realized that this version still has the plug-in problem which was fixed at http://linuxtv.org/hg/~jfrancois/gspca/rev/ea88b3abee04 What do you think, is it possible that this simple but important patch will be pulled to final 2.6.33? If I understand correctly this kind of bugfixes are normally accepted in the current development phase. Regards, Márton Németh -- 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] uvcvideo: check minimum border of control
Mauro Carvalho Chehab wrote: Németh Márton wrote: Check also the minimum border of a value before setting it to a control value. See also http://bugzilla.kernel.org/show_bug.cgi?id=12824 . Patch didn't apply. Had you generated against our -git tree? http://git.linuxtv.org/v4l-dvb.git No, this is against http://git.linuxtv.org/pinchartl/uvcvideo.git . The latest patch which tried to fix http://bugzilla.kernel.org/show_bug.cgi?id=12824 missed to check the minimum border. Regards, Márton Németh Signed-off-by: Márton Németh nm...@freemail.hu --- drivers/media/video/uvc/uvc_ctrl.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/uvc/uvc_ctrl.c b/drivers/media/video/uvc/uvc_ctrl.c --- a/drivers/media/video/uvc/uvc_ctrl.c +++ b/drivers/media/video/uvc/uvc_ctrl.c @@ -1068,6 +1068,8 @@ int uvc_ctrl_set(struct uvc_video_chain *chain, uvc_ctrl_data(ctrl, UVC_CTRL_DATA_RES)); xctrl-value = min + (xctrl-value - min + step/2) / step * step; +if (xctrl-value min) +xctrl-value = min; if (xctrl-value max) xctrl-value = max; value = xctrl-value; -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: check minimum border of control
Mauro Carvalho Chehab wrote: Németh Márton wrote: Mauro Carvalho Chehab wrote: Németh Márton wrote: Check also the minimum border of a value before setting it to a control value. See also http://bugzilla.kernel.org/show_bug.cgi?id=12824 . Patch didn't apply. Had you generated against our -git tree? http://git.linuxtv.org/v4l-dvb.git No, this is against http://git.linuxtv.org/pinchartl/uvcvideo.git . The latest patch which tried to fix http://bugzilla.kernel.org/show_bug.cgi?id=12824 missed to check the minimum border. Ah, ok. Please specify on the subject when you're writing patches against a different tree. This helps me to tag accordingly at Patchwork, Could you please give me an example what do you mean? For example in this case. Regards, Márton Németh -- 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: Make failed - standard ubuntu 9.10
David Henig wrote: Thanks, this is sounding promising, only thing is I'm not seeing a .config in the v4l directory although it shows up with the locate command, am I missing something very obvious. Sorry if I'm telling evidence, but just a hint: every file starts with . is a hidden file. So you'll need something like ls -a lib/modules/2.6.31-17-generic/build/.config , see man ls. Regards, Márton Németh Devin Heitmueller wrote: On Fri, Jan 29, 2010 at 11:02 AM, David Henig dhhe...@googlemail.com wrote: Thanks, I appear to have the headers and no longer have to do the symlink, but still getting the same error - any help gratefully received, or do I need to get a vanilla kernel? Open up the file v4l/.config and change the line for firedtv from =m to =n. Then run make. This is a known packaging bug in Ubuntu's kernel headers. Cheers, Devin -- 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 gspca_jf tree] gspca zc3xx: signal when unknown packet received
Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 95d3956ea3e5 linux/drivers/media/video/gspca/zc3xx.c --- a/linux/drivers/media/video/gspca/zc3xx.c Fri Jan 29 15:05:25 2010 +0100 +++ b/linux/drivers/media/video/gspca/zc3xx.c Fri Jan 29 21:01:52 2010 +0100 @@ -7213,14 +7213,17 @@ u8 *data, /* interrupt packet data */ int len)/* interrput packet length */ { + int ret = -EINVAL; + if (len == 8 data[4] == 1) { input_report_key(gspca_dev-input_dev, KEY_CAMERA, 1); input_sync(gspca_dev-input_dev); input_report_key(gspca_dev-input_dev, KEY_CAMERA, 0); input_sync(gspca_dev-input_dev); + ret = 0; } - return 0; + return ret; } #endif -- 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] hdpvr-core: make module parameters local
From: Márton Németh nm...@freemail.hu The default_video_input and default_audio_input module parameters are only used inside the hdpvr-core.c file so make them static. This will remove the following sparse warnings (see make C=1): * warning: symbol 'default_video_input' was not declared. Should it be static? * warning: symbol 'default_audio_input' was not declared. Should it be static? Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 8b9a62386b64 linux/drivers/media/video/hdpvr/hdpvr-core.c --- a/linux/drivers/media/video/hdpvr/hdpvr-core.c Fri Jan 29 01:23:57 2010 -0200 +++ b/linux/drivers/media/video/hdpvr/hdpvr-core.c Fri Jan 29 21:25:45 2010 +0100 @@ -39,12 +39,12 @@ module_param(hdpvr_debug, int, S_IRUGO|S_IWUSR); MODULE_PARM_DESC(hdpvr_debug, enable debugging output); -uint default_video_input = HDPVR_VIDEO_INPUTS; +static uint default_video_input = HDPVR_VIDEO_INPUTS; module_param(default_video_input, uint, S_IRUGO|S_IWUSR); MODULE_PARM_DESC(default_video_input, default video input: 0=Component / 1=S-Video / 2=Composite); -uint default_audio_input = HDPVR_AUDIO_INPUTS; +static uint default_audio_input = HDPVR_AUDIO_INPUTS; module_param(default_audio_input, uint, S_IRUGO|S_IWUSR); MODULE_PARM_DESC(default_audio_input, default audio input: 0=RCA back / 1=RCA front / 2=S/PDIF); -- 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] smsir: make local variables static
From: Márton Németh nm...@freemail.hu Make the file local parameters static. This will remove the following sparse warnings (see make C=1): * warning: symbol 'ir_pos' was not declared. Should it be static? * warning: symbol 'ir_word' was not declared. Should it be static? * warning: symbol 'ir_toggle' was not declared. Should it be static? Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 8b9a62386b64 linux/drivers/media/dvb/siano/smsir.c --- a/linux/drivers/media/dvb/siano/smsir.c Fri Jan 29 01:23:57 2010 -0200 +++ b/linux/drivers/media/dvb/siano/smsir.c Fri Jan 29 21:39:06 2010 +0100 @@ -85,9 +85,9 @@ { } /* Terminating entry */ }; -u32 ir_pos; -u32ir_word; -u32 ir_toggle; +static u32 ir_pos; +static u32 ir_word; +static u32 ir_toggle; #define RC5_PUSH_BIT(dst, bit, pos)\ { dst = 1; dst |= bit; pos++; } -- 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 gspca_jf tree] gspca zc3xx: signal when unknown packet received
Hans de Goede wrote: Hi, Nack! Németh I know you mean well, but please don't go making semi random behavior changes to code you don't have hardware to test with. I thought it is easier to write the patch I was thinking of than trying to describe it in words. Maybe it was not the best idea, sorry about that. There is a good reason this code is written the way it is. Jean-Francois, If you wonder what this is all about, this is a patch on top of one of my trees which no one else has yet as I have not send any pull request yet, see: http://linuxtv.org/hg/~hgoede/gspca_jf So back to the reason why this code is written the way it is, the zc3xx sends a steady stream of interrupt packets consisting of usually 8 0 byes, we definitely do not want to print out an error message every time such a packet is received. On some cams when they are just plugged in the 6th byte (data[5]) becomes 1 a couple of times, probably a floating pin. And on all cams with a button, pressing that will make the 5th byte (data[4]) 1. As said these cam sends a steady stream of interrupt packets, reporting I guess the status of 8 gpio pins independent on whether this status has changed since the last packet or not. Based on your description the following two lines could be separated: input_report_key(gspca_dev-input_dev, KEY_CAMERA, 1); input_report_key(gspca_dev-input_dev, KEY_CAMERA, 0); The first line should go when we detect a 0-1 transient (button push), the second one when there is an 1-0 transient (button release). In case of pac7302 there was only one event at button push. So there was a need to simulate push and release. The camera haven't sent anything when the button was released. I've tested this with the following cams: Logitech QuickCam IM/Connect046d:08d9 zc3xx HV7131R Logitech QuickCam E2500 046d:089d zc3xx MC501CB Labtec notebook cam 046d:08aa zc3xx PAS202B Creative WebCam Notebook041e:401f zc3xx TAS5130C Creative Live! Cam Video IM 041e:4053 zc3xx TAS5130-VF250 Philips SPC 200NC 0471:0325 zc3xx PAS106 Creative WebCam NX Pro 041e:401e zc3xx HV7131B No brand0ac8:307b zc3xx ADCM2700 Regards, Hans On 01/29/2010 09:07 PM, Németh Márton wrote: Signed-off-by: Márton Némethnm...@freemail.hu --- diff -r 95d3956ea3e5 linux/drivers/media/video/gspca/zc3xx.c --- a/linux/drivers/media/video/gspca/zc3xx.cFri Jan 29 15:05:25 2010 +0100 +++ b/linux/drivers/media/video/gspca/zc3xx.cFri Jan 29 21:01:52 2010 +0100 @@ -7213,14 +7213,17 @@ u8 *data, /* interrupt packet data */ int len)/* interrput packet length */ { +int ret = -EINVAL; + if (len == 8 data[4] == 1) { input_report_key(gspca_dev-input_dev, KEY_CAMERA, 1); input_sync(gspca_dev-input_dev); input_report_key(gspca_dev-input_dev, KEY_CAMERA, 0); input_sync(gspca_dev-input_dev); +ret = 0; } -return 0; +return ret; } #endif -- 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
PAC7302 short datasheet from PixArt
Hi, if anyone interested there is a brief overview datasheet about PixArt PAC7301/PAC7302 at http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf Regards, Márton Németh -- 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] gspca pac7302: add support for camera button
From: Márton Németh nm...@freemail.hu Add support for snapshot button found on Labtec Webcam 2200. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 875c200a19dc linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 07:58:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 13:47:50 2010 +0100 @@ -5,6 +5,8 @@ * V4L2 by Jean-Francois Moine http://moinejf.free.fr * * Separated from Pixart PAC7311 library by M�rton N�meth nm...@freemail.hu + * Camera button input handling by Márton Németh nm...@freemail.hu + * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -68,6 +70,7 @@ #define MODULE_NAME pac7302 +#include linux/input.h #include media/v4l2-chip-ident.h #include gspca.h @@ -1164,6 +1167,37 @@ } #endif +#ifdef CONFIG_INPUT +static int sd_int_pkt_scan(struct gspca_dev *gspca_dev, + u8 *data, /* interrupt packet data */ + int len)/* interrput packet length */ +{ + int ret = -EINVAL; + u8 data0, data1; + + if (len == 2) { + data0 = data[0]; + data1 = data[1]; + if ((data0 == 0x00 data1 == 0x11) || + (data0 == 0x22 data1 == 0x33) || + (data0 == 0x44 data1 == 0x55) || + (data0 == 0x66 data1 == 0x77) || + (data0 == 0x88 data1 == 0x99) || + (data0 == 0xaa data1 == 0xbb) || + (data0 == 0xcc data1 == 0xdd) || + (data0 == 0xee data1 == 0xff)) { + input_report_key(gspca_dev-input_dev, KEY_CAMERA, 1); + input_sync(gspca_dev-input_dev); + input_report_key(gspca_dev-input_dev, KEY_CAMERA, 0); + input_sync(gspca_dev-input_dev); + ret = 0; + } + } + + return ret; +} +#endif + /* sub-driver description for pac7302 */ static const struct sd_desc sd_desc = { .name = MODULE_NAME, @@ -1180,6 +1214,9 @@ .set_register = sd_dbg_s_register, .get_chip_ident = sd_chip_ident, #endif +#ifdef CONFIG_INPUT + .int_pkt_scan = sd_int_pkt_scan, +#endif }; /* -- module initialisation -- */ -- 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] gspca pac7302: add support for camera button
Hello Jean-Francois, thank you for accepting this patch and for the previous suggestions which made it possible to reach the current state of this patchset. Also thanks for correcting the character encoding in my name. Regards, Márton Németh Németh Márton írta: From: Márton Németh nm...@freemail.hu Add support for snapshot button found on Labtec Webcam 2200. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 875c200a19dc linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 07:58:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 13:47:50 2010 +0100 @@ -5,6 +5,8 @@ * V4L2 by Jean-Francois Moine http://moinejf.free.fr * * Separated from Pixart PAC7311 library by M�rton N�meth nm...@freemail.hu + * Camera button input handling by Márton Németh nm...@freemail.hu + * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -68,6 +70,7 @@ #define MODULE_NAME pac7302 +#include linux/input.h #include media/v4l2-chip-ident.h #include gspca.h @@ -1164,6 +1167,37 @@ } #endif +#ifdef CONFIG_INPUT +static int sd_int_pkt_scan(struct gspca_dev *gspca_dev, + u8 *data, /* interrupt packet data */ + int len)/* interrput packet length */ +{ + int ret = -EINVAL; + u8 data0, data1; + + if (len == 2) { + data0 = data[0]; + data1 = data[1]; + if ((data0 == 0x00 data1 == 0x11) || + (data0 == 0x22 data1 == 0x33) || + (data0 == 0x44 data1 == 0x55) || + (data0 == 0x66 data1 == 0x77) || + (data0 == 0x88 data1 == 0x99) || + (data0 == 0xaa data1 == 0xbb) || + (data0 == 0xcc data1 == 0xdd) || + (data0 == 0xee data1 == 0xff)) { + input_report_key(gspca_dev-input_dev, KEY_CAMERA, 1); + input_sync(gspca_dev-input_dev); + input_report_key(gspca_dev-input_dev, KEY_CAMERA, 0); + input_sync(gspca_dev-input_dev); + ret = 0; + } + } + + return ret; +} +#endif + /* sub-driver description for pac7302 */ static const struct sd_desc sd_desc = { .name = MODULE_NAME, @@ -1180,6 +1214,9 @@ .set_register = sd_dbg_s_register, .get_chip_ident = sd_chip_ident, #endif +#ifdef CONFIG_INPUT + .int_pkt_scan = sd_int_pkt_scan, +#endif }; /* -- module initialisation -- */ -- 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: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
Guennadi Liakhovetski wrote: On Wed, 27 Jan 2010, Németh Márton wrote: Guennadi Liakhovetski wrote: You didn't reply to my most important objection: On Wed, 27 Jan 2010, Németh Márton wrote: diff -r 31eaa9423f98 linux/include/media/soc_camera.h --- a/linux/include/media/soc_camera.h Mon Jan 25 15:04:15 2010 -0200 +++ b/linux/include/media/soc_camera.h Wed Jan 27 20:49:57 2010 +0100 @@ -264,9 +264,8 @@ common_flags; } -static inline void soc_camera_limit_side(unsigned int *start, - unsigned int *length, unsigned int start_min, - unsigned int length_min, unsigned int length_max) +static inline void soc_camera_limit_side(int *start, int *length, + int start_min, int length_min, int length_max) { if (*length length_min) *length = length_min; I still do not believe this function will work equally well with signed parameters, as it works with unsigned ones. I implemented some test cases to find out whether the soc_camera_limit_side() works correctly or not. My biggest problem is that I'm not sure what is the expected working of the soc_camera_limit_side() function. Well, the expected behaviour is simple: the function treats all its parameters as unsigned, and puts the former two input/output parameters within the limits, provided by the latter three parameters. Well, taking For the length parameter it is clear to put them between length_min and length_max. But for start there is only one limit given: start_min. Does this mean that any *start value bigger than start_min is acceptable? (I would like to find out the meaning, not to read back what is written in the source code because it is no use to define test cases out of the source code.) into account, that when comparing a signed and an unsigned integers, the comparison is performed unsigned, I think, it should be ok to do what I suggested in the last email: change prototype to +static inline void soc_camera_limit_side(int *start, int *length, + unsigned int start_min, unsigned int length_min, + unsigned int length_max) Maybe also provide a comment above the function explaining, why the first two parameters are signed. And cast explicitly in sh_mobile_ceu_camera.c: soc_camera_limit_side(rect-left, rect-width, (unsigned int)cap.bounds.left, 2, (unsigned int)cap.bounds.width); soc_camera_limit_side(rect-top, rect-height, (unsigned int)cap.bounds.top, 4, (unsigned int)cap.bounds.height); I'm afraid that casting __s32 to unsigned int just cannot work. Let's take an example on a 32bit machine: -1 = 0x (unsigned int)-1 = 0x = 4294967295 and -2147483648 = 0x8000 (unsigned int)-2147483648 = 0x8000 = 2147483648 This means that any negative number will be mapped to a large positive number when casting to (unsigned int) and I think this is not the wanted behaviour. Could you check if this would make both sparse and the compiler happy? There is no compiler warning nor sparse warning when applying the following version of the patch. I'm not sure, however, that the simple cast will do the right thing here. Regards, Márton Németh --- From: Márton Németh nm...@freemail.hu The parameters of soc_camera_limit_side() are either a pointer to a structure element from v4l2_rect, or constants. The structure elements of the v4l2_rect are signed (see linux/videodev2.h) so do the computations also with signed values. The *s_crop() functions may receive negative numbers through the c field of struct v4l2_crop. These negative values then limited by the start_min and length_min parameters of soc_camera_limit_side(). This will remove the following sparse warning (see make C=1): * incorrect type in argument 1 (different signedness) expected unsigned int *start got signed int *noident Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 31eaa9423f98 linux/drivers/media/video/mt9v022.c --- a/linux/drivers/media/video/mt9v022.c Mon Jan 25 15:04:15 2010 -0200 +++ b/linux/drivers/media/video/mt9v022.c Thu Jan 28 22:24:35 2010 +0100 @@ -326,7 +326,7 @@ if (ret 0) return ret; - dev_dbg(client-dev, Frame %ux%u pixel\n, rect.width, rect.height); + dev_dbg(client-dev, Frame %dx%d pixel\n, rect.width, rect.height); mt9v022-rect = rect; diff -r 31eaa9423f98 linux/drivers/media/video/rj54n1cb0c.c --- a/linux/drivers/media/video/rj54n1cb0c.cMon Jan 25 15:04:15 2010 -0200 +++ b/linux/drivers/media/video/rj54n1cb0c.cThu Jan 28 22:24:35 2010 +0100 @@ -555,15 +555,15 @@ return ret; } -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h, - u32 *out_w, u32 *out_h); +static int rj54n1_sensor_scale(struct
Re: Make failed - standard ubuntu 9.10
David Henig wrote: Please can someone assist, not sure what the cause of the below is? This is my second attempt to get linux tv to work, I suspect it's a basic level error - sorry I'm fairly new to Linux... output below, I'm running a fairly standard ubuntu 9.10 setup. make[1]: Entering directory `/home/david/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.31 File not found: /lib/modules/2.6.31-17-generic/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. make[1]: *** No rule to make target `.myconfig', needed by `config-compat.h'. Stop. make[1]: Leaving directory `/home/david/v4l-dvb/v4l' make: *** [all] Error 2 I think you don't have the kernel development files installed. The recommended reading would be: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Regards, Márton Németh -- 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] soc_camera: match signedness of soc_camera_limit_side()
Guennadi Liakhovetski wrote: On Sat, 23 Jan 2010, Németh Márton wrote: From: Márton Németh nm...@freemail.hu The parameters of soc_camera_limit_side() are either a pointer to a structure element from v4l2_rect, or constants. The structure elements of the v4l2_rect are signed (see linux/videodev2.h) so do the computations also with signed values. This will remove the following sparse warning (see make C=1): * incorrect type in argument 1 (different signedness) expected unsigned int *start got signed int *noident Well, it is interesting, but insufficient. And, unfortunately, I don't have a good (and easy) recipe for how to fix this properly. The problem is, that in soc_camera_limit_side all tests and arithmetics are performed with unsigned in mind, now, if you change them to signed, think what happens, if some of them are negative. No, I don't know when negative members of struct v4l2_rect make sense, having them signed doesn't seem a very good idea to me. But they cannot be changed - that's a part of the user-space API... Casting all parameters inside that inline to unsigned would be way too ugly. Maybe we could at least keep start_min, length_min, and length_max unsigned, and only change start and length to signed, and only cast those two inside the function. Then, if you grep through all the drivers, there's only one location, where soc_camera_limit_side() is called with the latter 3 parameters not constant - two calls in sh_mobile_ceu_camera.c. So, to keep sparse happy, you'd have to cast there. Ideally, you would also add checks there for negative values... I'll have a look to see what can be done to handle the negative values properly. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 2a50a0a1c951 linux/include/media/soc_camera.h --- a/linux/include/media/soc_camera.h Sat Jan 23 00:14:32 2010 -0200 +++ b/linux/include/media/soc_camera.h Sat Jan 23 10:09:41 2010 +0100 @@ -264,9 +264,8 @@ common_flags; } -static inline void soc_camera_limit_side(unsigned int *start, -unsigned int *length, unsigned int start_min, -unsigned int length_min, unsigned int length_max) +static inline void soc_camera_limit_side(int *start, int *length, +int start_min, int length_min, int length_max) { if (*length length_min) *length = length_min; diff -r 2a50a0a1c951 linux/drivers/media/video/rj54n1cb0c.c --- a/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 00:14:32 2010 -0200 +++ b/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 10:09:41 2010 +0100 @@ -555,15 +555,15 @@ return ret; } -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h, - u32 *out_w, u32 *out_h); +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h, + s32 *out_w, s32 *out_h); static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) { struct i2c_client *client = sd-priv; struct rj54n1 *rj54n1 = to_rj54n1(client); struct v4l2_rect *rect = a-c; -unsigned int dummy = 0, output_w, output_h, +int dummy = 0, output_w, output_h, input_w = rect-width, input_h = rect-height; int ret; And these: if (output_w max(512U, input_w / 2)) { if (output_h max(384U, input_h / 2)) { would now produce compiler warnings... Have you actually tried to compile your patch? You'll also have to change formats in dev_dbg() calls here... Interesting to hear about compiler warnings. I don't get them if I apply the patch on top of version 14064:31eaa9423f98 of http://linuxtv.org/hg/v4l-dvb/ . What is your compiler version? I used the attached configuration. Maybe some other options has to be turned on? localhost:/usr/src/linuxtv.org/v4l-dvb$ patch -p1 ../soc_camera_signedness.patch patching file linux/include/media/soc_camera.h patching file linux/drivers/media/video/rj54n1cb0c.c localhost:/usr/src/linuxtv.org/v4l-dvb$ make C=1 21 |tee result1.txt make -C /usr/src/linuxtv.org/v4l-dvb/v4l make[1]: Entering directory `/usr/src/linuxtv.org/v4l-dvb/v4l' creating symbolic links... make -C firmware prep make[2]: Entering directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware' make[2]: Leaving directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware' make -C firmware make[2]: Entering directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware' make[2]: Nothing to be done for `default'. make[2]: Leaving directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware' Kernel build directory is /lib/modules/2.6.33-rc4/build make -C /lib/modules/2.6.33-rc4/build SUBDIRS=/usr/src/linuxtv.org/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linuxtv.org/pinchartl/uvcvideo/v4l-dvb' CHECK /usr/src/linuxtv.org/v4l-dvb/v4l/mt9m001.c CC [M] /usr/src/linuxtv.org/v4l-dvb/v4l/mt9m001.o CHECK /usr/src/linuxtv.org/v4l-dvb/v4l
Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
Guennadi Liakhovetski wrote: You didn't reply to my most important objection: On Wed, 27 Jan 2010, Németh Márton wrote: diff -r 31eaa9423f98 linux/include/media/soc_camera.h --- a/linux/include/media/soc_camera.h Mon Jan 25 15:04:15 2010 -0200 +++ b/linux/include/media/soc_camera.h Wed Jan 27 20:49:57 2010 +0100 @@ -264,9 +264,8 @@ common_flags; } -static inline void soc_camera_limit_side(unsigned int *start, -unsigned int *length, unsigned int start_min, -unsigned int length_min, unsigned int length_max) +static inline void soc_camera_limit_side(int *start, int *length, +int start_min, int length_min, int length_max) { if (*length length_min) *length = length_min; I still do not believe this function will work equally well with signed parameters, as it works with unsigned ones. I implemented some test cases to find out whether the soc_camera_limit_side() works correctly or not. My biggest problem is that I'm not sure what is the expected working of the soc_camera_limit_side() function. Nevertheless I tried expect some values, you can probably verify whether my expectations are correct or not (see the test attached). The signed and unsigned version of the function works differently because the unsigned version cannot accept negative values. These values will be implicitly casted to an unsigned value which means that they will be interpreted as a big positive value. Here are the test results: Test Case 1: PASSED Test Case 2: PASSED Test Case 3: FAILED: start=50, length=8, start_unsigned=0, length_unsigned=1600 Test Case 4: PASSED Test Case 5: PASSED Test Case 6: PASSED Test Case 7: PASSED Test Case 8: PASSED There is a difference in case 3, but which is the correct one? Regard, Márton Németh #include stdio.h static inline void soc_camera_limit_side_UNSIGNED(unsigned int *start, unsigned int *length, unsigned int start_min, unsigned int length_min, unsigned int length_max) { if (*length length_min) *length = length_min; else if (*length length_max) *length = length_max; if (*start start_min) *start = start_min; else if (*start start_min + length_max - *length) *start = start_min + length_max - *length; } static inline void soc_camera_limit_side(int *start, int *length, int start_min, int length_min, int length_max) { if (*length length_min) *length = length_min; else if (*length length_max) *length = length_max; if (*start start_min) *start = start_min; else if (*start start_min + length_max - *length) *start = start_min + length_max - *length; } int main() { int start, length; unsigned int start_unsigned, length_unsigned; printf(Test Case 1: ); start = 0; length = 8; start_unsigned = start; length_unsigned = length; soc_camera_limit_side(start, length, 0, 8, 1600); soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 0, 8, 1600); if (start == 0 length == 8 start_unsigned == start length_unsigned == length) { printf(PASSED\n); } else { printf(FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n, start, length, start_unsigned, length_unsigned); } printf(Test Case 2: ); start = -5; length = 1600; start_unsigned = start; length_unsigned = length; soc_camera_limit_side(start, length, 0, 8, 1600); soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 0, 8, 1600); if (start == 0 length == 1600 start_unsigned == start length_unsigned == length) { printf(PASSED\n); } else { printf(FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n, start, length, start_unsigned, length_unsigned); } printf(Test Case 3: ); start = 50; length = -15; start_unsigned = start; length_unsigned = length; soc_camera_limit_side(start, length, 0, 8, 1600); soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 0, 8, 1600); if (start == 50 length == 8 start_unsigned == start length_unsigned == length) { printf(PASSED\n); } else { printf(FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n, start, length, start_unsigned, length_unsigned); } printf(Test Case 4: ); start = 500; length = 2000; start_unsigned = start; length_unsigned = length; soc_camera_limit_side(start, length, 0, 8, 1600); soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 0, 8, 1600); if (start == 0 length == 1600 start_unsigned == start length_unsigned == length) { printf(PASSED\n); } else { printf(FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n, start, length, start_unsigned, length_unsigned); } printf(Test Case 5: ); start = -20; length = 1600; start_unsigned = start; length_unsigned = length; soc_camera_limit_side(start, length, 100, 8, 1600); soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 100, 8, 1600); if (start == 100 length == 1600 start_unsigned == start length_unsigned == length) { printf
Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hans Verkuil wrote: On Wednesday 27 January 2010 22:48:24 Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. It's up and running again. Note that I upgraded to the latest gcc 4.4.3. I also updated all the kernels to their latest dot release. I'm happy to hear that this regular check is running again. I think this is an important tool to increase quality of v4l subsystem. Regards, Márton Németh -- 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: git problem with uvcvideo
Laurent Pinchart wrote: Hi Márton, On Sunday 24 January 2010 22:31:29 Németh Márton wrote: Hi, I'm trying to fetch the uvcvideo from http://linuxtv.org/git/?p=pinchartl/uvcvideo.git;a=summary . I tryied to follow the instructions but at the third step I get fatal error messages: [snip] The http:// URL seems not to be available at the moment. I don't know if it's a transient error or a deliberate decision not to provide git access through http:// I also tried with the git:// link: v4l-dvb$ git remote rm uvcvideo v4l-dvb$ git remote add uvcvideo git://linuxtv.org//pinchartl/uvcvideo.git v4l-dvb$ git remote update Updating origin Updating uvcvideo fatal: The remote end hung up unexpectedly error: Could not fetch uvcvideo Am I doing something wrong? Please try git://linuxtv.org/pinchartl/uvcvideo.git. The URL on the webpage has two / instead of one for some reason. Mauro, could that be fixed ? It seems removing the extra '/' helps: v4l-dvb$ git remote rm uvcvideo v4l-dvb$ git remote add uvcvideo git://linuxtv.org/pinchartl/uvcvideo.git v4l-dvb$ git remote update Updating origin Updating uvcvideo remote: Counting objects: 1944, done. remote: Compressing objects: 100% (427/427), done. remote: Total 1733 (delta 1486), reused 1551 (delta 1306) Receiving objects: 100% (1733/1733), 312.47 KiB | 164 KiB/s, done. Resolving deltas: 100% (1486/1486), completed with 169 local objects. From git://linuxtv.org/pinchartl/uvcvideo * [new branch] master - uvcvideo/master * [new branch] uvcvideo - uvcvideo/uvcvideo v4l-dvb$ git branch -r origin/HEAD - origin/master origin/master uvcvideo/master uvcvideo/uvcvideo v4l-dvb$ git checkout -b test uvcvideo/uvcvideo Branch test set up to track remote branch uvcvideo from uvcvideo. Switched to a new branch 'test' Now I can start to build and test this branch. Regards, Márton Németh -- 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
[RFC, PATCH] gspca pac7302: propagate footer to userspace
Hi, I'm dealing with Labtec Webcam 2200 and I found that the pac7302 driver does not forward the image footer information to userspace. This footer contains some information which might be interesting to the userspace. What exactly this footer means is not clear as of this writing, but it is easier to analyze the data in userspace than in kernel space. I modified the sd_pkt_scan() in order the footer is transfered to the userspace together with the image. This, however, breaks the image decoding in libv4lconvert. This is can be easily solved by passing the image buffer to v4lconvert_convert() truncated by 0x4f bytes. What do you think the right way would be to transfer image footer to userspace? Is it necessary to add a new V4L2_PIX_FMT_* format in order not to brake userspace programs? PAC7302 footer structure I could figure out so far is: Offset | Length |Description ---++-- 0x0 | 1| Seen values: 0x10, 0x11, 0x12, 0x13, 0x15, 0x16 || Some kind of sequence number or timestamp? ---++-- 0x1 | 1| Seen values: 0x50 ---++-- 0x2 | 1| Seen values: 0x00 ---++-- 0x3 | 1| Seen values: 0x00 ---++-- 0x4 | 1| Seen values: 0x00 ---++-- 0x5 | 1| Seen values: 0x00 ---++-- 0x6 | 25 | Picutre lumination related bytes. || The gain setting has influcence on the values || In test modes: || test mode 1 (white): filled with 0xFE || test mode 2 (black): filled with 0x00 || test mode 3 (red): filled with 0x4C || test mode 4 (green): filled with 0x96 || test mode 5 (blue):filled with 0x1C || test mode 6 (cyan):filled with 0xB3 || test mode 7 (magenta): filled with 0x69 || test mode 8 (yellow): filled with 0xE1 || test mode 9 (color bars): || 9B 6A 7B B1 52 71 68 6B 76 62 9F 9F 9F 9F 9F 8D 61 70 A1 4B 99 6A 7A AF 52 || test mode 10 (high resolution color pattern): || A8 AC A5 A6 A6 A3 A3 A1 A2 A4 A2 9F 9F A0 A5 A5 9F 9F 9C A5 A9 A5 A2 A2 A7 || test mode 11 (black to white gradient from top to bottom): || 4B 6E 8A A4 BF 48 6A 85 9E B8 47 68 83 9C B5 47 69 84 9D B7 49 6C 88 A1 BC || test mode 12 (white to black gradient from left to right): || 5A 57 57 57 59 80 7D 7D 7D 80 A0 9D 9C 9C A0 BF BB BA BB BE DC D7 D6 D7 DB || test mode 13 (white to black gradient repeats from left to right): || A8 A5 A4 A5 A7 A4 A0 9F A0 A4 A4 A0 A2 A0 A3 A5 A2 A2 A1 A5 A5 A3 A2 A2 A5 || test mode 14 (dark gray): filled with 0x00 || test mode 15 (dark gray2): filled with 0x00 ---++-- 0x1f |1 | Seen: 0x00 ---++-- 0x20 |2 | Picture content related? ---++-- 0x22 |1 | Seen: 0x00 ---++-- 0x23 |2 | Compressed picture size related? ---++-- 0x25 |1 | Seen: 0x00 ---++-- 0x26 |1 | Seen: 0x00 ---++-- 0x27 |1 | Seen: 0x00 ---++-- 0x28 |4 | Picture content related? ---++-- 0x2c |4 | Picture content related? ---++-- 0x30 |4 | Picture content related? ---++-- 0x34 |4 | Picture content related? ---++-- 0x38 |1 | Seen: fixed 0x01 ---++-- 0x39 |1 | Seen: fixed 0xAE ---++-- 0x3a |1 | Seen: fixed 0x01 ---++-- 0x3b |1 | Seen: fixed 0x04 ---++-- 0x3c |1 | Seen: fixed 0x16 ---++-- 0x3d |1 | Seen: fixed 0x14
git problem with uvcvideo
Hi, I'm trying to fetch the uvcvideo from http://linuxtv.org/git/?p=pinchartl/uvcvideo.git;a=summary . I tryied to follow the instructions but at the third step I get fatal error messages: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb Initialized empty Git repository in /usr/src/linuxtv.org/pinchartl/uvcvideo/v4l-dvb/.git/ remote: Counting objects: 1455151, done. remote: Compressing objects: 100% (233826/233826), done. remote: Total 1455151 (delta 1210384), reused 1455044 (delta 1210312) Receiving objects: 100% (1455151/1455151), 317.25 MiB | 224 KiB/s, done. Resolving deltas: 100% (1210384/1210384), done. Checking out files: 100% (31566/31566), done. $ cd v4l-dvb/ v4l-dvb$ git remote add uvcvideo http://linuxtv.org/git//pinchartl/uvcvideo.git v4l-dvb$ git remote update Updating origin Updating uvcvideo fatal: http://linuxtv.org/git//pinchartl/uvcvideo.git/info/refs not found: did you run git update-server-info on the server? error: Could not fetch uvcvideo I also tried with the git:// link: v4l-dvb$ git remote rm uvcvideo v4l-dvb$ git remote add uvcvideo git://linuxtv.org//pinchartl/uvcvideo.git v4l-dvb$ git remote update Updating origin Updating uvcvideo fatal: The remote end hung up unexpectedly error: Could not fetch uvcvideo Am I doing something wrong? Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Jean-Francois Moine írta: On Fri, 22 Jan 2010 18:54:46 -0200 Mauro Carvalho Chehab mche...@infradead.org wrote: Huh? -static int reg_w_buf(struct gspca_dev *gspca_dev, +static void reg_w_buf(struct gspca_dev *gspca_dev, __u8 index, const char *buffer, int len) { int ret; + if (gspca_dev-usb_err 0) + return; This is an ugly and non-standard way to report errors in C. Just return the error code. Perhaps, but a code as: foo(x); bar(y); bla(z); ... is more readable, smaller and quicker (less MMU switches) than: What do you mean under MMU switches? rc = foo(x); if (rc 0) return rc; rc = bar(y); if (rc 0) return rc; rc = bla(z); if (rc 0) return rc; ... An other way to do it is to use longjump, but I don't think it works in the kernel... Best regards. -- 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] soc_camera: match signedness of soc_camera_limit_side()
From: Márton Németh nm...@freemail.hu The parameters of soc_camera_limit_side() are either a pointer to a structure element from v4l2_rect, or constants. The structure elements of the v4l2_rect are signed (see linux/videodev2.h) so do the computations also with signed values. This will remove the following sparse warning (see make C=1): * incorrect type in argument 1 (different signedness) expected unsigned int *start got signed int *noident Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 2a50a0a1c951 linux/include/media/soc_camera.h --- a/linux/include/media/soc_camera.h Sat Jan 23 00:14:32 2010 -0200 +++ b/linux/include/media/soc_camera.h Sat Jan 23 10:09:41 2010 +0100 @@ -264,9 +264,8 @@ common_flags; } -static inline void soc_camera_limit_side(unsigned int *start, - unsigned int *length, unsigned int start_min, - unsigned int length_min, unsigned int length_max) +static inline void soc_camera_limit_side(int *start, int *length, + int start_min, int length_min, int length_max) { if (*length length_min) *length = length_min; diff -r 2a50a0a1c951 linux/drivers/media/video/rj54n1cb0c.c --- a/linux/drivers/media/video/rj54n1cb0c.cSat Jan 23 00:14:32 2010 -0200 +++ b/linux/drivers/media/video/rj54n1cb0c.cSat Jan 23 10:09:41 2010 +0100 @@ -555,15 +555,15 @@ return ret; } -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h, - u32 *out_w, u32 *out_h); +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h, + s32 *out_w, s32 *out_h); static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) { struct i2c_client *client = sd-priv; struct rj54n1 *rj54n1 = to_rj54n1(client); struct v4l2_rect *rect = a-c; - unsigned int dummy = 0, output_w, output_h, + int dummy = 0, output_w, output_h, input_w = rect-width, input_h = rect-height; int ret; @@ -638,8 +638,8 @@ * the output one, updates the window sizes and returns an error or the resize * coefficient on success. Note: we only use the Fixed Scaling on this camera. */ -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h, - u32 *out_w, u32 *out_h) +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h, + s32 *out_w, s32 *out_h) { struct i2c_client *client = sd-priv; struct rj54n1 *rj54n1 = to_rj54n1(client); @@ -1017,7 +1017,7 @@ struct i2c_client *client = sd-priv; struct rj54n1 *rj54n1 = to_rj54n1(client); const struct rj54n1_datafmt *fmt; - unsigned int output_w, output_h, max_w, max_h, + int output_w, output_h, max_w, max_h, input_w = rj54n1-rect.width, input_h = rj54n1-rect.height; int ret; -- 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] zoran: remove variable shadowing
From: Márton Németh nm...@freemail.hu The loop counter j is declared twice in function error_handler(). Remove the redundant declaration. This will remove the following sparse warning (see make C=1): * symbol 'j' shadows an earlier one Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 2a50a0a1c951 linux/drivers/media/video/zoran/zoran_device.c --- a/linux/drivers/media/video/zoran/zoran_device.cSat Jan 23 00:14:32 2010 -0200 +++ b/linux/drivers/media/video/zoran/zoran_device.cSat Jan 23 10:47:27 2010 +0100 @@ -1229,7 +1230,7 @@ u32 astat, u32 stat) { - int i, j; + int i; /* This is JPEG error handling part */ if (zr-codec_mode != BUZ_MODE_MOTION_COMPRESS @@ -1280,6 +1281,7 @@ /* Report error */ if (zr36067_debug 1 zr-num_errors = 8) { long frame; + int j; frame = zr-jpg_pend[zr-jpg_dma_tail BUZ_MASK_FRAME]; printk(KERN_ERR -- 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] hdpvr-video: cleanup signedness
From: Márton Németh nm...@freemail.hu The fifth parameter of usb_bulk_msg() is a pointer to signed (see linux/usb.h) so also call this function with pointer to signed. This will remove the following sparse warning (see make C=1): * warning: incorrect type in argument 5 (different signedness) expected int *actual_length got unsigned int *noident Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 2a50a0a1c951 linux/drivers/media/video/hdpvr/hdpvr-video.c --- a/linux/drivers/media/video/hdpvr/hdpvr-video.c Sat Jan 23 00:14:32 2010 -0200 +++ b/linux/drivers/media/video/hdpvr/hdpvr-video.c Sat Jan 23 11:43:17 2010 +0100 @@ -302,7 +302,8 @@ /* function expects dev-io_mutex to be hold by caller */ static int hdpvr_stop_streaming(struct hdpvr_device *dev) { - uint actual_length, c = 0; + int actual_length; + uint c = 0; u8 *buf; if (dev-status == STATUS_IDLE) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Mauro Carvalho Chehab írta: Jean-Francois Moine wrote: On Sat, 23 Jan 2010 09:10:44 +0100 Németh Márton nm...@freemail.hu wrote: is more readable, smaller and quicker (less MMU switches) than: What do you mean under MMU switches? The MMU has an associative memory which is used in the first step to translate a logical address (page) to the physical RAM address. Every time an address is not in this memory, a MMU interrupt occurs. Then, the system scans the page tables of the process, and either reloads the associative memory or calls the swap system to bring the page into the physical memory. An associative memory is complex and its complexity grows exponentially with its size. So, usually, it is rather small. Then, the more the code is small and the less MMU interrupts occur... Linux doesn't use swap memory for the kernel. It will be using a physical RAM memory for the entire kernel. So, I don't think MMU applies here. As far as I can understand the description is about the cache. The cache is the storage area which is usually small and speeds up RAM access. Regards, Márton Németh -- 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] zoran: match parameter signedness of g_input_status
From: Márton Németh nm...@freemail.hu The second parameter of g_input_status operation in media/v4l2-subdev.h is unsigned so also call it with unsigned paramter. This will remove the following sparse warning (see make C=1): * incorrect type in argument 2 (different signedness) expected unsigned int [usertype] *status got int *noident Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 2a50a0a1c951 linux/drivers/media/video/zoran/zoran_device.c --- a/linux/drivers/media/video/zoran/zoran_device.cSat Jan 23 00:14:32 2010 -0200 +++ b/linux/drivers/media/video/zoran/zoran_device.cSat Jan 23 07:57:09 2010 +0100 @@ -1197,7 +1197,8 @@ static void zoran_restart(struct zoran *zr) { /* Now the stat_comm buffer is ready for restart */ - int status = 0, mode; + unsigned int status = 0; + int mode; if (zr-codec_mode == BUZ_MODE_MOTION_COMPRESS) { decoder_call(zr, video, g_input_status, status); diff -r 2a50a0a1c951 linux/drivers/media/video/zoran/zoran_driver.c --- a/linux/drivers/media/video/zoran/zoran_driver.cSat Jan 23 00:14:32 2010 -0200 +++ b/linux/drivers/media/video/zoran/zoran_driver.cSat Jan 23 07:57:09 2010 +0100 @@ -1452,7 +1452,7 @@ } if (norm == V4L2_STD_ALL) { - int status = 0; + unsigned int status = 0; v4l2_std_id std = 0; decoder_call(zr, video, querystd, std); -- 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/2, RFC] gspca: add input support for interrupt endpoints
Hans de Goede wrote: Hi, Thanks for your continued work on this. I'm afraid I found one thing which needs fixing (can be fixed with a separate patch after merging, but that is up to Jean-Francois). See my comments inline. Thanks for the feedback, I hope the quality of the software increases during this review phase. On 01/17/2010 02:08 PM, Németh Márton wrote: [snip] +#ifdef CONFIG_INPUT +#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19) +static void int_irq(struct urb *urb, struct pt_regs *regs) +#else +static void int_irq(struct urb *urb) +#endif +{ +struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context; +int ret; + +if (urb-status == 0) { +if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev, +urb-transfer_buffer, urb-actual_length) 0) { +PDEBUG(D_ERR, Unknown packet received); +} + +ret = usb_submit_urb(urb, GFP_ATOMIC); +if (ret 0) +PDEBUG(D_ERR, Resubmit URB failed with error %i, ret); +} +} + If the status is not 0 you should print an error message, and reset the status and still resubmit the urb, if you don't resubmit on error, after one single usb glitch, the button will stop working. I rewrote this function, see the following patch version. [snip] @@ -2137,6 +2308,11 @@ usb_set_intfdata(intf, gspca_dev); PDEBUG(D_PROBE, %s created, video_device_node_name(gspca_dev-vdev)); + +ret = gspca_input_connect(gspca_dev); +if (0= ret) +ret = gspca_input_create_urb(gspca_dev); + I don't like this reverse psychology if. Why not just write: if (ret == 0) ? I changed this line to if (ret == 0). When I use a not-equal relation I try to put the smaller value on the left hand side and the bigger one to the right hand side. In this case a range which is expressed in mathematical notation like 10 a = 16 can be written in C like (10 a) (a = 16). But it is a different question what people like and what not, so I've changed that line. Otherwise it looks good. Thanks. I'm looking forward to receive more comments on the new version of this patch. Regars, Márton Németh -- 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/2, RFC] gspca: add input support for interrupt endpoints
From: Márton Németh nm...@freemail.hu Add support functions for interrupt endpoint based input handling. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c --- a/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 07:58:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/gspca.c Mon Jan 18 20:43:55 2010 +0100 @@ -3,6 +3,9 @@ * * Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr) * + * Camera button input handling by Márton Németh + * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu + * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the * Free Software Foundation; either version 2 of the License, or (at your @@ -41,6 +44,9 @@ #include gspca.h +#include linux/input.h +#include linux/usb/input.h + /* global values */ #define DEF_NURBS 3/* default number of URBs */ #if DEF_NURBS MAX_NURBS @@ -112,6 +118,186 @@ .close = gspca_vm_close, }; +/* + * Input and interrupt endpoint handling functions + */ +#ifdef CONFIG_INPUT +#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19) +static void int_irq(struct urb *urb, struct pt_regs *regs) +#else +static void int_irq(struct urb *urb) +#endif +{ + struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context; + int ret; + + ret = urb-status; + switch (ret) { + case 0: + if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev, + urb-transfer_buffer, urb-actual_length) 0) { + PDEBUG(D_ERR, Unknown packet received); + } + break; + + case -ENOENT: + case -ECONNRESET: + case -ENODEV: + case -ESHUTDOWN: + /* Stop is requested either by software or hardware is gone, +* keep the ret value non-zero and don't resubmit later. +*/ + break; + + default: + PDEBUG(D_ERR, URB error %i, resubmitting, urb-status); + urb-status = 0; + ret = 0; + } + + if (ret == 0) { + ret = usb_submit_urb(urb, GFP_ATOMIC); + if (ret 0) + PDEBUG(D_ERR, Resubmit URB failed with error %i, ret); + } +} + +static int gspca_input_connect(struct gspca_dev *dev) +{ + struct input_dev *input_dev; + int err = 0; + + dev-input_dev = NULL; + if (dev-sd_desc-int_pkt_scan) { + input_dev = input_allocate_device(); + if (!input_dev) + return -ENOMEM; + + usb_make_path(dev-dev, dev-phys, sizeof(dev-phys)); + strlcat(dev-phys, /input0, sizeof(dev-phys)); + + input_dev-name = dev-sd_desc-name; + input_dev-phys = dev-phys; + + usb_to_input_id(dev-dev, input_dev-id); + + input_dev-evbit[0] = BIT_MASK(EV_KEY); + input_dev-keybit[BIT_WORD(KEY_CAMERA)] = BIT_MASK(KEY_CAMERA); + input_dev-dev.parent = dev-dev-dev; + + err = input_register_device(input_dev); + if (err) { + PDEBUG(D_ERR, Input device registration failed + with error %i, err); + input_dev-dev.parent = NULL; + input_free_device(input_dev); + } else { + dev-input_dev = input_dev; + } + } else + err = -EINVAL; + + return err; +} + +static int alloc_and_submit_int_urb(struct gspca_dev *gspca_dev, + struct usb_endpoint_descriptor *ep) +{ + unsigned int buffer_len; + int interval; + struct urb *urb; + struct usb_device *dev; + void *buffer = NULL; + int ret = -EINVAL; + + buffer_len = ep-wMaxPacketSize; + interval = ep-bInterval; + PDEBUG(D_PROBE, found int in endpoint: 0x%x, + buffer_len=%u, interval=%u, + ep-bEndpointAddress, buffer_len, interval); + + dev = gspca_dev-dev; + + urb = usb_alloc_urb(0, GFP_KERNEL); + if (!urb) { + ret = -ENOMEM; + goto error; + } + + buffer = usb_buffer_alloc(dev, ep-wMaxPacketSize, + GFP_KERNEL, urb-transfer_dma); + if (!buffer) { + ret = -ENOMEM; + goto error_buffer; + } + usb_fill_int_urb(urb, dev, + usb_rcvintpipe(dev, ep-bEndpointAddress), + buffer, buffer_len, + int_irq, (void *)gspca_dev, interval); + gspca_dev-int_urb = urb; + ret = usb_submit_urb(urb, GFP_KERNEL); + if (ret 0) { + PDEBUG(D_ERR, submit URB failed with error %i, ret); + goto error_submit; + } + return ret; + +error_submit:
[PATCH 1/2, RFC] gspca: add input support for interrupt endpoints
From: Márton Németh nm...@freemail.hu Add support functions for interrupt endpoint based input handling. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c --- a/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 07:58:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 13:47:44 2010 +0100 @@ -3,6 +3,9 @@ * * Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr) * + * Camera button input handling by Márton Németh + * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu + * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the * Free Software Foundation; either version 2 of the License, or (at your @@ -41,6 +44,9 @@ #include gspca.h +#include linux/input.h +#include linux/usb/input.h + /* global values */ #define DEF_NURBS 3/* default number of URBs */ #if DEF_NURBS MAX_NURBS @@ -112,6 +118,167 @@ .close = gspca_vm_close, }; +/* + * Input and interrupt endpoint handling functions + */ +#ifdef CONFIG_INPUT +#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19) +static void int_irq(struct urb *urb, struct pt_regs *regs) +#else +static void int_irq(struct urb *urb) +#endif +{ + struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context; + int ret; + + if (urb-status == 0) { + if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev, + urb-transfer_buffer, urb-actual_length) 0) { + PDEBUG(D_ERR, Unknown packet received); + } + + ret = usb_submit_urb(urb, GFP_ATOMIC); + if (ret 0) + PDEBUG(D_ERR, Resubmit URB failed with error %i, ret); + } +} + +static int gspca_input_connect(struct gspca_dev *dev) +{ + struct input_dev *input_dev; + int err = 0; + + dev-input_dev = NULL; + if (dev-sd_desc-int_pkt_scan) { + input_dev = input_allocate_device(); + if (!input_dev) + return -ENOMEM; + + usb_make_path(dev-dev, dev-phys, sizeof(dev-phys)); + strlcat(dev-phys, /input0, sizeof(dev-phys)); + + input_dev-name = dev-sd_desc-name; + input_dev-phys = dev-phys; + + usb_to_input_id(dev-dev, input_dev-id); + + input_dev-evbit[0] = BIT_MASK(EV_KEY); + input_dev-keybit[BIT_WORD(KEY_CAMERA)] = BIT_MASK(KEY_CAMERA); + input_dev-dev.parent = dev-dev-dev; + + err = input_register_device(input_dev); + if (err) { + PDEBUG(D_ERR, Input device registration failed + with error %i, err); + input_dev-dev.parent = NULL; + input_free_device(input_dev); + } else { + dev-input_dev = input_dev; + } + } else + err = -EINVAL; + + return err; +} + +static int alloc_and_submit_int_urb(struct gspca_dev *gspca_dev, + struct usb_endpoint_descriptor *ep) +{ + unsigned int buffer_len; + int interval; + struct urb *urb; + struct usb_device *dev; + void *buffer = NULL; + int ret = -EINVAL; + + buffer_len = ep-wMaxPacketSize; + interval = ep-bInterval; + PDEBUG(D_PROBE, found int in endpoint: 0x%x, + buffer_len=%u, interval=%u, + ep-bEndpointAddress, buffer_len, interval); + + dev = gspca_dev-dev; + + urb = usb_alloc_urb(0, GFP_KERNEL); + if (!urb) { + ret = -ENOMEM; + goto error; + } + + buffer = usb_buffer_alloc(dev, ep-wMaxPacketSize, + GFP_KERNEL, urb-transfer_dma); + if (!buffer) { + ret = -ENOMEM; + goto error_buffer; + } + usb_fill_int_urb(urb, dev, + usb_rcvintpipe(dev, ep-bEndpointAddress), + buffer, buffer_len, + int_irq, (void *)gspca_dev, interval); + gspca_dev-int_urb = urb; + ret = usb_submit_urb(urb, GFP_KERNEL); + if (ret 0) { + PDEBUG(D_ERR, submit URB failed with error %i, ret); + goto error_submit; + } + return ret; + +error_submit: + usb_buffer_free(dev, + urb-transfer_buffer_length, + urb-transfer_buffer, + urb-transfer_dma); +error_buffer: + usb_free_urb(urb); +error: + return ret; +} + +static int gspca_input_create_urb(struct gspca_dev *gspca_dev) +{ + int ret = -EINVAL; + struct usb_interface *intf; + struct usb_host_interface *intf_desc; + struct usb_endpoint_descriptor *ep; + int i; + + if (gspca_dev-sd_desc-int_pkt_scan) {
[PATCH 2/2, RFC] gspca pac7302: add support for camera button
From: Márton Németh nm...@freemail.hu Add support for snapshot button found on Labtec Webcam 2200. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 875c200a19dc linux/drivers/media/video/gspca/pac7302.c --- a/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 07:58:51 2010 +0100 +++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 13:47:50 2010 +0100 @@ -5,6 +5,8 @@ * V4L2 by Jean-Francois Moine http://moinejf.free.fr * * Separated from Pixart PAC7311 library by M�rton N�meth nm...@freemail.hu + * Camera button input handling by Márton Németh nm...@freemail.hu + * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -68,6 +70,7 @@ #define MODULE_NAME pac7302 +#include linux/input.h #include media/v4l2-chip-ident.h #include gspca.h @@ -1164,6 +1167,37 @@ } #endif +#ifdef CONFIG_INPUT +static int sd_int_pkt_scan(struct gspca_dev *gspca_dev, + u8 *data, /* interrupt packet data */ + int len)/* interrput packet length */ +{ + int ret = -EINVAL; + u8 data0, data1; + + if (len == 2) { + data0 = data[0]; + data1 = data[1]; + if ((data0 == 0x00 data1 == 0x11) || + (data0 == 0x22 data1 == 0x33) || + (data0 == 0x44 data1 == 0x55) || + (data0 == 0x66 data1 == 0x77) || + (data0 == 0x88 data1 == 0x99) || + (data0 == 0xaa data1 == 0xbb) || + (data0 == 0xcc data1 == 0xdd) || + (data0 == 0xee data1 == 0xff)) { + input_report_key(gspca_dev-input_dev, KEY_CAMERA, 1); + input_sync(gspca_dev-input_dev); + input_report_key(gspca_dev-input_dev, KEY_CAMERA, 0); + input_sync(gspca_dev-input_dev); + ret = 0; + } + } + + return ret; +} +#endif + /* sub-driver description for pac7302 */ static const struct sd_desc sd_desc = { .name = MODULE_NAME, @@ -1180,6 +1214,9 @@ .set_register = sd_dbg_s_register, .get_chip_ident = sd_chip_ident, #endif +#ifdef CONFIG_INPUT + .int_pkt_scan = sd_int_pkt_scan, +#endif }; /* -- module initialisation -- */ -- 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] zoran: cleanup pointer condition
From: Márton Németh nm...@freemail.hu Remove the following sparse warning (see make C=1): * warning: Using plain integer as NULL pointer Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 5bcdcc072b6d linux/drivers/media/video/zoran/zoran_driver.c --- a/linux/drivers/media/video/zoran/zoran_driver.cSat Jan 16 07:25:43 2010 +0100 +++ b/linux/drivers/media/video/zoran/zoran_driver.cSat Jan 16 09:03:31 2010 +0100 @@ -325,7 +325,7 @@ /* Allocate fragment table for this buffer */ mem = (void *)get_zeroed_page(GFP_KERNEL); - if (mem == 0) { + if (!mem) { dprintk(1, KERN_ERR %s: %s - get_zeroed_page (frag_tab) failed for buffer %d\n, -- 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] disable building cx23885 before 2.6.33
From: Márton Németh nm...@freemail.hu The cx23885 driver does not compile before Linux kernel 2.6.33 because of incompatible fifo API changes. Disable this driver being built before 2.6.33. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 5bcdcc072b6d v4l/versions.txt --- a/v4l/versions.txt Sat Jan 16 07:25:43 2010 +0100 +++ b/v4l/versions.txt Sat Jan 16 16:56:28 2010 +0100 @@ -1,6 +1,10 @@ # Use this for stuff for drivers that don't compile [2.6.99] +[2.6.33] +# Incompatible fifo API changes, see linux/kfifo.h +VIDEO_CX23885 + [2.6.32] # These rely on arch support that wasn't available until 2.6.32 VIDEO_SH_MOBILE_CEU -- 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] cx231xx: cleanup dvb_attach() return value handling
From: Márton Németh nm...@freemail.hu Remove the following sparse error (see make C=1): * error: incompatible types for operation () left side has type struct dvb_frontend * right side has type int Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 5bcdcc072b6d linux/drivers/media/video/cx231xx/cx231xx-dvb.c --- a/linux/drivers/media/video/cx231xx/cx231xx-dvb.c Sat Jan 16 07:25:43 2010 +0100 +++ b/linux/drivers/media/video/cx231xx/cx231xx-dvb.c Sat Jan 16 17:21:06 2010 +0100 @@ -465,9 +465,9 @@ /* define general-purpose callback pointer */ dvb-frontend-callback = cx231xx_tuner_callback; - if (dvb_attach(xc5000_attach, dev-dvb-frontend, + if (!dvb_attach(xc5000_attach, dev-dvb-frontend, dev-i2c_bus[1].i2c_adap, - cnxt_rde250_tunerconfig) 0) { + cnxt_rde250_tunerconfig)) { result = -EINVAL; goto out_free; } @@ -487,9 +487,9 @@ /* define general-purpose callback pointer */ dvb-frontend-callback = cx231xx_tuner_callback; - if (dvb_attach(xc5000_attach, dev-dvb-frontend, + if (!dvb_attach(xc5000_attach, dev-dvb-frontend, dev-i2c_bus[1].i2c_adap, - cnxt_rde250_tunerconfig) 0) { + cnxt_rde250_tunerconfig)) { result = -EINVAL; goto out_free; } -- 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] stv0900: make more local functions static
From: Márton Németh nm...@freemail.hu Some functions are only used locally so mark them static. This will remove the following sparse warnings (see make C=1): * symbol 'extract_mask_pos' was not declared. Should it be static? * symbol 'stv0900_initialize' was not declared. Should it be static? * symbol 'stv0900_get_mclk_freq' was not declared. Should it be static? * symbol 'stv0900_set_mclk' was not declared. Should it be static? * symbol 'stv0900_get_err_count' was not declared. Should it be static? Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 5bcdcc072b6d linux/drivers/media/dvb/frontends/stv0900_core.c --- a/linux/drivers/media/dvb/frontends/stv0900_core.c Sat Jan 16 07:25:43 2010 +0100 +++ b/linux/drivers/media/dvb/frontends/stv0900_core.c Sat Jan 16 17:37:59 2010 +0100 @@ -177,7 +177,7 @@ return buf; } -void extract_mask_pos(u32 label, u8 *mask, u8 *pos) +static void extract_mask_pos(u32 label, u8 *mask, u8 *pos) { u8 position = 0, i = 0; @@ -218,7 +218,7 @@ return val; } -enum fe_stv0900_error stv0900_initialize(struct stv0900_internal *intp) +static enum fe_stv0900_error stv0900_initialize(struct stv0900_internal *intp) { s32 i; @@ -282,7 +282,7 @@ return STV0900_NO_ERROR; } -u32 stv0900_get_mclk_freq(struct stv0900_internal *intp, u32 ext_clk) +static u32 stv0900_get_mclk_freq(struct stv0900_internal *intp, u32 ext_clk) { u32 mclk = 9000, div = 0, ad_div = 0; @@ -296,7 +296,7 @@ return mclk; } -enum fe_stv0900_error stv0900_set_mclk(struct stv0900_internal *intp, u32 mclk) +static enum fe_stv0900_error stv0900_set_mclk(struct stv0900_internal *intp, u32 mclk) { u32 m_div, clk_sel; @@ -334,7 +334,7 @@ return STV0900_NO_ERROR; } -u32 stv0900_get_err_count(struct stv0900_internal *intp, int cntr, +static u32 stv0900_get_err_count(struct stv0900_internal *intp, int cntr, enum fe_stv0900_demod_num demod) { u32 lsb, msb, hsb, err_val; -- 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] bt819: cleanup v4l2_subdev_notify() parameters
From: Márton Németh nm...@freemail.hu The 3rd parameter v4l2_subdev_notify() is passed to the notify() callback which is a pointer, see media/v4l2-subdev.h and media/v4l2-device.h. This will remove the following sparse warning (see make C=1): * Using plain integer as NULL pointer Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 5bcdcc072b6d linux/drivers/media/video/bt819.c --- a/linux/drivers/media/video/bt819.c Sat Jan 16 07:25:43 2010 +0100 +++ b/linux/drivers/media/video/bt819.c Sat Jan 16 18:04:27 2010 +0100 @@ -260,7 +260,7 @@ v4l2_err(sd, no notify found!\n); if (std V4L2_STD_NTSC) { - v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, 0); + v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, NULL); bt819_setbit(decoder, 0x01, 0, 1); bt819_setbit(decoder, 0x01, 1, 0); bt819_setbit(decoder, 0x01, 5, 0); @@ -269,7 +269,7 @@ /* bt819_setbit(decoder, 0x1a, 5, 1); */ timing = timing_data[1]; } else if (std V4L2_STD_PAL) { - v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, 0); + v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, NULL); bt819_setbit(decoder, 0x01, 0, 1); bt819_setbit(decoder, 0x01, 1, 1); bt819_setbit(decoder, 0x01, 5, 1); @@ -294,7 +294,7 @@ bt819_write(decoder, 0x08, (timing-hscale 8) 0xff); bt819_write(decoder, 0x09, timing-hscale 0xff); decoder-norm = std; - v4l2_subdev_notify(sd, BT819_FIFO_RESET_HIGH, 0); + v4l2_subdev_notify(sd, BT819_FIFO_RESET_HIGH, NULL); return 0; } @@ -312,7 +312,7 @@ v4l2_err(sd, no notify found!\n); if (decoder-input != input) { - v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, 0); + v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, NULL); decoder-input = input; /* select mode */ if (decoder-input == 0) { @@ -322,7 +322,7 @@ bt819_setbit(decoder, 0x0b, 6, 1); bt819_setbit(decoder, 0x1a, 1, 0); } - v4l2_subdev_notify(sd, BT819_FIFO_RESET_HIGH, 0); + v4l2_subdev_notify(sd, BT819_FIFO_RESET_HIGH, NULL); } return 0; } -- 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] dib0090: cleanup dib0090_dcc_freq()
From: Márton Németh nm...@freemail.hu 'extern' is not needed at function definition. This will remove the following sparse warning (see make C=1): * function 'dib0090_dcc_freq' with external linkage has definition Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 5bcdcc072b6d linux/drivers/media/dvb/frontends/dib0090.c --- a/linux/drivers/media/dvb/frontends/dib0090.c Sat Jan 16 07:25:43 2010 +0100 +++ b/linux/drivers/media/dvb/frontends/dib0090.c Sat Jan 16 18:33:43 2010 +0100 @@ -283,7 +283,7 @@ return 0; } -extern void dib0090_dcc_freq(struct dvb_frontend *fe, u8 fast) +void dib0090_dcc_freq(struct dvb_frontend *fe, u8 fast) { struct dib0090_state *state = fe-tuner_priv; if (fast) -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hans Verkuil wrote: Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log linux-2.6.32-i686: ERRORS /marune/build/v4l-dvb-master/v4l/cx23888-ir.c: In function 'cx23888_ir_irq_handler': CC [M] /marune/build/v4l-dvb-master/v4l/cx23885-f300.o /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:621: error: implicit declaration of function 'kfifo_in_locked' /marune/build/v4l-dvb-master/v4l/cx23888-ir.c: In function 'cx23888_ir_rx_read': /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:688: error: implicit declaration of function 'kfifo_out_locked' /marune/build/v4l-dvb-master/v4l/cx23888-ir.c: In function 'cx23888_ir_probe': /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:1243: warning: passing argument 1 of 'kfifo_alloc' makes integer from pointer without a cast include/linux/kfifo.h:37: note: expected 'unsigned int' but argument is of type 'struct kfifo *' /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:1243: warning: passing argument 3 of 'kfifo_alloc' makes pointer from integer without a cast include/linux/kfifo.h:37: note: expected 'struct spinlock_t *' but argument is of type 'unsigned int' make[3]: *** [/marune/build/v4l-dvb-master/v4l/cx23888-ir.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [_module_/marune/build/v4l-dvb-master/v4l] Error 2 make[2]: Leaving directory `/marune/build/trees/i686/linux-2.6.32' make[1]: *** [default] Error 2 make[1]: Leaving directory `/marune/build/v4l-dvb-master/v4l' make: *** [all] Error 2 As I can see in the include/linux/kfifo.h ( http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=include/linux/kfifo.h ) there is renaming of - kfifo_put into kfifo_in_locked - kfifo_get into kfifo_out_locked Possible solutions would be: a) disable the compiling of cx23888-ir.c before 2.6.33 b) adding something like this to v4l/compat.h: #if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33) #define kfifo_in_locked kfifo_put #define kfifo_out_locked kfifo_get #endif What do you think the best way would be? Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gspca_pac7302: sporatdic problem when plugging the device
Jean-Francois Moine írta: Sorry, I forgot to attach the patch. In some usbsnoop files I have, the index 0x48 is not loaded. May you try the attached patch (skip the index 0x48 and remove the delay). 100 plug-ins out of 100 OK, no errors: I say go for this patch. I applied the patch on top of rev 14000:bc5737e0e757 from http://linuxtv.org/hg/~jfrancois/gspca/ . I tested the driver on top of 2.6.32 with Labtec Webcam 2200 (0x093a:0x2626). Tested-by: Márton Németh nm...@freemail.hu Thanks for the fix. Regards, Márton Németh -- 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 2/2] gspca pac7302: add support for camera button
Mauro Carvalho Chehab worte: Németh Márton wrote: From: Márton Németh nm...@freemail.hu Add support for snapshot button found on Labtec Webcam 2200 (USB ID 093a:2626 This patch breaks compilation against current -tip: There was several versions of adding support to pac7302. The last version still have some problems which I haven't addressed, yet. So the camera button support for pac7302 is not yet ready for inclusion. Regards, Márton Németh -- 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 2/2] gspca pac7302: add support for camera button
Mauro Carvalho Chehab írta: Németh Márton wrote: Mauro Carvalho Chehab worte: Németh Márton wrote: From: Márton Németh nm...@freemail.hu Add support for snapshot button found on Labtec Webcam 2200 (USB ID 093a:2626 This patch breaks compilation against current -tip: There was several versions of adding support to pac7302. The last version still have some problems which I haven't addressed, yet. So the camera button support for pac7302 is not yet ready for inclusion. Ok. While you don't have a final version, please add an RFC at the patch, for me to know, when dealing with patchwork queue, that the patch is not ok yet. I thought every time it was the final version ;-), but I get some comments which may make the code quality and acceptance better. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gspca_sunplus problem: more than one device is created
Hi, I tried the gspca_sunplus driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. When I plug the Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031) then two devices are created: /dev/video0 and /dev/video1: [31636.528184] usb 3-2: new full speed USB device using uhci_hcd and address 5 [31636.740722] usb 3-2: New USB device found, idVendor=06d6, idProduct=0031 [31636.740744] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [31636.740760] usb 3-2: Product: Trust 610 LCD pow...@m ZOOM [31636.740772] usb 3-2: Manufacturer: Trust [31636.744229] usb 3-2: configuration #1 chosen from 1 choice [31636.747584] gspca: probing 06d6:0031 [31636.760176] gspca: video0 created [31636.760643] gspca: probing 06d6:0031 [31636.772063] gspca: video1 created The /dev/video0 is working correctly but the /dev/video1 just causes error: $ ./svv -d /dev/video1 raw pixfmt: JPEG 464x480 pixfmt: RGB3 464x480 mmap method VIDIOC_STREAMON error 5, Input/output error Here is the USB descriptor of the device: Trust 610 LCD pow...@m ZOOM Manufacturer: Trust Speed: 12Mb/s (full) USB Version: 1.00 Device Class: 00(ifc ) Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 8 Number of Configurations: 1 Vendor Id: 06d6 Product Id: 0031 Revision Number: 1.00 Config Number: 1 Number of Interfaces: 2 Attributes: 80 MaxPower Needed: 500mA Interface Number: 0 Name: sunplus Alternate Number: 0 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 0 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 1 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 128 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 2 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 384 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 3 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 512 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 4 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 640 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 5 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 768 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 6 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 896 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 7 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81
gspca_pac7302: sporatdic problem when plugging the device
Hi, I have sporadic problem with Labtec Webcam 2200 (0x093a:0x2626). I'm using gspca_pac7302 driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. I executed the following command in an xterm window: $ while true; do ./svv; done Then I plugged and unplugged the device 16 times. When I last plugged the device I get the following error in the dmesg: [32393.421313] gspca: probing 093a:2626 [32393.426193] gspca: video0 created [32393.426958] gspca: probing 093a:2626 [32393.426968] gspca: Interface class 1 not handled here [32394.005917] pac7302: reg_w_page(): Failed to write register to index 0x49, value 0x0, error -71 [32394.067799] gspca: set alt 8 err -71 [32394.090792] gspca: set alt 8 err -71 [32394.118159] gspca: set alt 8 err -71 The 17th plug was working correctly again. I executed this test on an EeePC 901. This driver version contains the msleep(4) in the reg_w_buf(). However, here the reg_w_page() fails, which does not have msleep() inside. I don't know what is the real problem, but I am afraid that slowing down reg_w_page() would make the time longer when the device can be used starting from the event when it is plugged. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gspca_sunplus problem: more than one device is created
][f80e22e7] v4l2_unlocked_ioctl+0x37/0x70 [videodev] [ 581.087111][c02bd6ed] vfs_ioctl+0x3d/0x130 [ 581.087111][c02bda60] do_vfs_ioctl+0x80/0xb10 [ 581.087111][c02be539] sys_ioctl+0x49/0xc0 [ 581.087111][c010484c] sysenter_do_call+0x12/0x32 [ 581.087111] [ 581.087111] other info that might help us debug this: [ 581.087111] [ 581.087111] 2 locks held by svv/3409: [ 581.087111] #0: (gspca_dev-queue_lock){+.+.+.}, at: [f80f78e7] vidioc_streamon+0x37/0x180 [gspca_main] [ 581.087111] #1: (gspca_dev-usb_lock){+.+...}, at: [f80f7019] gspca_init_transfer+0x29/0x840 [gspca_main] [ 581.087111] [ 581.087111] stack backtrace: [ 581.087111] Pid: 3409, comm: svv Not tainted 2.6.33-rc2 #1 [ 581.087111] Call Trace: [ 581.087111] [c06473f8] ? printk+0x34/0x54 [ 581.087111] [c01bb456] print_circular_bug+0x196/0x1b0 [ 581.087111] [c01bdb3a] validate_chain+0x1c4a/0x1e40 [ 581.087111] [c01b7638] ? save_trace+0x48/0x150 [ 581.087111] [c050eab0] ? device_pm_remove+0x20/0x60 [ 581.087111] [c01be064] __lock_acquire+0x334/0x15a0 [ 581.087111] [c01be064] ? __lock_acquire+0x334/0x15a0 [ 581.087111] [c01bf39a] lock_acquire+0xca/0x220 [ 581.087111] [c03338e3] ? sysfs_get_dirent+0x23/0xe0 [ 581.087111] [c03338e3] ? sysfs_get_dirent+0x23/0xe0 [ 581.087111] [c064b210] mutex_lock_nested+0xa0/0x820 [ 581.087111] [c03338e3] ? sysfs_get_dirent+0x23/0xe0 [ 581.087111] [c01b96fb] ? mark_held_locks+0x9b/0xe0 [ 581.087111] [c03338e3] sysfs_get_dirent+0x23/0xe0 [ 581.087111] [c0337220] sysfs_remove_group+0x30/0x220 [ 581.087111] [c01b9f37] ? trace_hardirqs_on+0x27/0x40 [ 581.087111] [c050e5be] dpm_sysfs_remove+0x1e/0x30 [ 581.087111] [c0501711] device_del+0x71/0x310 [ 581.087111] [c05019c9] device_unregister+0x19/0x40 [ 581.087111] [f899d1c1] usb_remove_ep_devs+0x31/0x50 [usbcore] [ 581.087111] [f898fa13] remove_intf_ep_devs+0x43/0xa0 [usbcore] [ 581.087111] [f8991c83] usb_set_interface+0x1e3/0x430 [usbcore] [ 581.087111] [f80f6f33] get_ep+0x293/0x350 [gspca_main] [ 581.087111] [c064a6be] ? mutex_lock_interruptible_nested+0x9ce/0xa20 [ 581.087111] [f80f7019] ? gspca_init_transfer+0x29/0x840 [gspca_main] [ 581.087111] [f80f70c8] gspca_init_transfer+0xd8/0x840 [gspca_main] [ 581.087111] [f80f78e7] ? vidioc_streamon+0x37/0x180 [gspca_main] [ 581.087111] [f80f78e7] ? vidioc_streamon+0x37/0x180 [gspca_main] [ 581.087111] [f80f79ad] vidioc_streamon+0xfd/0x180 [gspca_main] [ 581.087111] [f80e6abc] __video_do_ioctl+0x29ec/0x71c0 [videodev] [ 581.087111] [c064ee8f] ? _raw_spin_unlock_irq+0x8f/0x100 [ 581.087111] [c01be064] ? __lock_acquire+0x334/0x15a0 [ 581.087111] [c01bf7c0] ? lock_release_non_nested+0xc0/0x550 [ 581.087111] [c026ccb0] ? might_fault+0xa0/0x120 [ 581.087111] [c026ccb0] ? might_fault+0xa0/0x120 [ 581.087111] [c026ccb0] ? might_fault+0xa0/0x120 [ 581.087111] [c026cd12] ? might_fault+0x102/0x120 [ 581.087111] [c026ccb0] ? might_fault+0xa0/0x120 [ 581.087111] [c0427491] ? _copy_from_user+0x51/0x1d0 [ 581.087111] [f80eb36d] video_ioctl2+0xdd/0x980 [videodev] [ 581.087111] [c0149199] ? __wake_up+0x29/0x90 [ 581.087111] [c064f003] ? _raw_spin_unlock_irqrestore+0x103/0x150 [ 581.087111] [c01b9e12] ? trace_hardirqs_on_caller+0x312/0x410 [ 581.087111] [c01b9f37] ? trace_hardirqs_on+0x27/0x40 [ 581.087111] [f80eb290] ? video_ioctl2+0x0/0x980 [videodev] [ 581.087111] [f80e22e7] v4l2_unlocked_ioctl+0x37/0x70 [videodev] [ 581.087111] [f80e22b0] ? v4l2_unlocked_ioctl+0x0/0x70 [videodev] [ 581.087111] [c02bd6ed] vfs_ioctl+0x3d/0x130 [ 581.087111] [c01b9f37] ? trace_hardirqs_on+0x27/0x40 [ 581.087111] [c02bda60] do_vfs_ioctl+0x80/0xb10 [ 581.087111] [c04cde27] ? tty_write+0x2a7/0x490 [ 581.087111] [c02a22a7] ? vfs_write+0x177/0x260 [ 581.087111] [c010487b] ? sysenter_exit+0xf/0x16 [ 581.087111] [c02be539] sys_ioctl+0x49/0xc0 [ 581.087111] [c010484c] sysenter_do_call+0x12/0x32 Regards, Márton Németh 2010/1/10 Németh Márton nm...@freemail.hu: Hi, I tried the gspca_sunplus driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. When I plug the Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031) then two devices are created: /dev/video0 and /dev/video1: [31636.528184] usb 3-2: new full speed USB device using uhci_hcd and address 5 [31636.740722] usb 3-2: New USB device found, idVendor=06d6, idProduct=0031 [31636.740744] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [31636.740760] usb 3-2: Product: Trust 610 LCD pow...@m ZOOM [31636.740772] usb 3-2: Manufacturer: Trust [31636.744229] usb 3-2: configuration #1 chosen from 1 choice [31636.747584] gspca: probing 06d6:0031 [31636.760176] gspca: video0 created [31636.760643] gspca: probing 06d6:0031 [31636.772063] gspca: video1 created The /dev/video0 is working correctly but the /dev/video1 just causes error: $ ./svv -d /dev/video1 raw
Re: gspca_pac7302: sporatdic problem when plugging the device
Jean-Francois Moine wrote: On Sun, 10 Jan 2010 17:58:58 +0100 Németh Márton nm...@freemail.hu wrote: Then I plugged and unplugged the device 16 times. When I last plugged the device I get the following error in the dmesg: [32393.421313] gspca: probing 093a:2626 [32393.426193] gspca: video0 created [32393.426958] gspca: probing 093a:2626 [32393.426968] gspca: Interface class 1 not handled here [32394.005917] pac7302: reg_w_page(): Failed to write register to index 0x49, value 0x0, error -71 [32394.067799] gspca: set alt 8 err -71 [32394.090792] gspca: set alt 8 err -71 [32394.118159] gspca: set alt 8 err -71 The 17th plug was working correctly again. I executed this test on an EeePC 901. This driver version contains the msleep(4) in the reg_w_buf(). However, here the reg_w_page() fails, which does not have msleep() inside. I don't know what is the real problem, but I am afraid that slowing down reg_w_page() would make the time longer when the device can be used starting from the event when it is plugged. Hi again, I don't understand what you mean by: This driver version contains the msleep(4) in the reg_w_buf(). However, here the reg_w_page() fails, which does not have msleep() inside. I tought that the msleep(4) call introduced recently fixed the plug-in problem. It seems I misunderstood something. Indeed the delay will slow down the webcam start (256 * 4 ms = 1s). If having a delay fixes the problem, then, as the error always occurs at the same index 0x49 (3 reports), a single delay could be set before writing to this index. Do you want I code this for test? I tested the behaviour a little bit more. Out of 100 plug-ins: OK: 81 times pac7302: reg_w_page(): Failed to write register to index 0x49, value 0x0, error -71: 19 times Other error message I haven't got, so 19% of the time writing to register index 0x49 fails in reg_w_page(). So let's try doing fixing the way you described. If you send me a patch I can test it. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gspca_sunplus problem: more than one device is created
Jean-Francois Moine wrote: On Sun, 10 Jan 2010 17:38:00 +0100 Németh Márton nm...@freemail.hu wrote: I tried the gspca_sunplus driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. When I plug the Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031) then two devices are created: /dev/video0 and /dev/video1: [snip] OK, this is a bug. I did not imagine that some webcams had the same interface class for two different devices. I am fixing it. rev 13917 from http://linuxtv.org/hg/~jfrancois/gspca/ works correctly with Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031): only one device is created. Thanks for the fix. Regards, Márton Németh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gspca - pac7302: Add a delay on loading the bridge registers.
Hi, At http://linuxtv.org/hg/~jfrancois/gspca/rev/b0a374674388 : From: Jean-Francois Moine moin...@free.fr Without the delay, the usb_control_msg() may fail when loading the page 3 with error -71 or -62. Priority: normal Signed-off-by: Jean-Francois Moine moin...@free.fr include/asm-generic/errno.h: #define ETIME 62 /* Timer expired */ #define EPROTO 71 /* Protocol error */ I'm interested in which device have you used for testing this? Regards, Márton Németh -- 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] rj54n1cb0c: remove compiler warning
Guennadi Liakhovetski wrote: Hi Márton On Sun, 3 Jan 2010, Németh Márton wrote: From: Márton Németh nm...@freemail.hu Remove the following compiler warning: 'dummy' is used uninitialized in this function. Although the result in the dummy variable is not used the program flow in soc_camera_limit_side() depends on the value in dummy. The program flow is better to be deterministic. Signed-off-by: Márton Németh nm...@freemail.hu The patch is good, the only slight problem - you have non-ASCII characters in your name and you didn't use UTF-8 to send this mail, which, I think, is the accepted encoding in the Linux kernel. I converted your patch to utf8 and attached to this mail. Please verify that the result is correct. Your conversion is OK. Sorry about this issue. Regards, Márton Németh -- 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