Re: [PATCH] media: add support to gspca/pac7302.c for 093a:2627 (Genius FaceCam 300)

2012-05-15 Thread Németh Márton

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

2012-01-23 Thread Németh Márton
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

2011-12-22 Thread Németh Márton
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

2011-10-20 Thread Németh Márton
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

2011-10-18 Thread Németh Márton
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

2011-07-04 Thread Németh Márton
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

2010-10-18 Thread Németh Márton
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

2010-10-18 Thread Németh Márton
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

2010-10-17 Thread Németh Márton
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

2010-10-17 Thread Németh Márton
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

2010-10-17 Thread Németh Márton
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

2010-10-17 Thread Németh Márton
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

2010-10-17 Thread Németh Márton
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

2010-10-17 Thread Németh Márton
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

2010-06-21 Thread Németh Márton
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

2010-06-14 Thread Németh Márton
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

2010-06-14 Thread Németh Márton
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

2010-03-31 Thread Németh Márton
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

2010-03-30 Thread Németh Márton
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 

Sony DCR-HC23 + USB (0540:00c0) + Linux?

2010-03-17 Thread Németh Márton
Hi,

does anybody have experience connecting Sony DCR-HC23 Handycam to Linux through
USB? I send the USB descriptor below.

The device appears only after selecting the FN/MENU/SETUP MENU/USB STREAM
menu item of the handycam to ON. When I select OFF and press EXEC button
then the device disconnects from the USB bus, if I select ON and press EXEC
the device connects again to USB bus.

(The device also have a Firewire port, unfortunately my PC doesn't have one.)

Regards,

Márton Németh

snd-usb-audio
Speed: 12Mb/s (full)
USB Version:  1.10
Device Class: 00(ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 64
Number of Configurations: 1
Vendor Id: 054c
Product Id: 00c0
Revision Number:  1.00

Config Number: 1
Number of Interfaces: 3
Attributes: c0
MaxPower Needed:   2mA

Interface Number: 0
Name: (none)
Alternate Number: 0
Class: 00(ifc )
Sub Class: 00
Protocol: 00
Number of Endpoints: 2

Endpoint Address: 81
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 0
Interval: 1ms

Endpoint Address: 82
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 0
Interval: 1ms

Interface Number: 0
Name: (none)
Alternate Number: 1
Class: 00(ifc )
Sub Class: 00
Protocol: 00
Number of Endpoints: 2

Endpoint Address: 81
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 8
Interval: 1ms

Endpoint Address: 82
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 256
Interval: 1ms

Interface Number: 0
Name: (none)
Alternate Number: 2
Class: 00(ifc )
Sub Class: 00
Protocol: 00
Number of Endpoints: 2

Endpoint Address: 81
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 8
Interval: 1ms

Endpoint Address: 82
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 384
Interval: 1ms

Interface Number: 0
Name: (none)
Alternate Number: 3
Class: 00(ifc )
Sub Class: 00
Protocol: 00
Number of Endpoints: 2

Endpoint Address: 81
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 8
Interval: 1ms

Endpoint Address: 82
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 512
Interval: 1ms

Interface Number: 0
Name: (none)
Alternate Number: 4
Class: 00(ifc )
Sub Class: 00
Protocol: 00
Number of Endpoints: 2

Endpoint Address: 81
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 8
Interval: 1ms

Endpoint Address: 82
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 640
Interval: 1ms

Interface Number: 0
Name: (none)
Alternate Number: 5
Class: 00(ifc )
Sub Class: 00
Protocol: 00
Number of Endpoints: 2

Endpoint Address: 81
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 8
Interval: 1ms

Endpoint Address: 82
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 768
  

Re: problem compiling modoule mt9t031 in current v4l-dvb-hg

2010-03-07 Thread Németh Márton
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

2010-03-07 Thread Németh Márton
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

2010-03-06 Thread Németh Márton
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

2010-03-06 Thread Németh Márton
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

2010-03-06 Thread Németh Márton
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

2010-03-06 Thread Németh Márton
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

2010-03-02 Thread Németh Márton
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

2010-03-02 Thread Németh Márton
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

2010-03-02 Thread Németh Márton
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

2010-02-28 Thread Németh Márton
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

2010-02-28 Thread Németh Márton
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

2010-02-28 Thread Németh Márton
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

2010-02-28 Thread Németh Márton
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

2010-02-28 Thread Németh Márton
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()

2010-02-28 Thread Németh Márton
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

2010-02-28 Thread Németh Márton
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

2010-02-27 Thread Németh Márton
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

2010-02-27 Thread Németh Márton
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

2010-02-27 Thread Németh Márton
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

2010-02-27 Thread Németh Márton
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

2010-02-27 Thread Németh Márton
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

2010-02-27 Thread Németh Márton
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

2010-02-27 Thread Németh Márton
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

2010-02-26 Thread Németh Márton
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

2010-02-26 Thread Németh Márton
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

2010-02-24 Thread Németh Márton
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()

2010-02-23 Thread Németh Márton
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

2010-02-23 Thread Németh Márton
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

2010-02-04 Thread Németh Márton
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

2010-02-02 Thread Németh Márton
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

2010-02-02 Thread Németh Márton
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

2010-02-02 Thread Németh Márton
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

2010-02-01 Thread Németh Márton
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

2010-02-01 Thread Németh Márton
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

2010-01-31 Thread Németh Márton
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


[PATCH, RFC] gspca pac7302: add USB PID range based on heuristics

2010-01-31 Thread Németh Márton
Hi,

as I was reading the PixArt PAC7301/PAC7302 datasheet
( 
http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf )
I recognised a little description on the schematics. This is about how to
set up the USB Product ID from range 0x2620..0x262f via hardware wires.

I had the idea that the list of supported devices could be extended with the 
full
range because the System on a Chip internals will not change just because it is
configured to a different USB Product ID.

I don't know much about the maintenance implications that's why I'm very
much listening to the comments of this idea.

So, what do you think?

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


pac7302 sporadic plug-in problem fix for 2.6.33?

2010-01-30 Thread Németh Márton
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

2010-01-29 Thread Németh Márton
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

2010-01-29 Thread Németh Márton
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

2010-01-29 Thread Németh Márton
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

2010-01-29 Thread Németh Márton

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

2010-01-29 Thread Németh Márton
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

2010-01-29 Thread Németh Márton
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

2010-01-29 Thread Németh Márton
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

2010-01-29 Thread Németh Márton
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

2010-01-28 Thread Németh Márton
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

2010-01-28 Thread Németh Márton
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()

2010-01-28 Thread Németh Márton
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

2010-01-28 Thread Németh Márton
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()

2010-01-27 Thread Németh Márton
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()

2010-01-27 Thread Németh Márton
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

2010-01-27 Thread Németh Márton
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

2010-01-25 Thread Németh Márton
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

2010-01-24 Thread Németh Márton
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

2010-01-24 Thread Németh Márton
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/

2010-01-23 Thread Németh Márton
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()

2010-01-23 Thread Németh Márton
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

2010-01-23 Thread Németh Márton
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

2010-01-23 Thread Németh Márton
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/

2010-01-23 Thread Németh Márton
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

2010-01-22 Thread Németh Márton
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

2010-01-18 Thread Németh Márton
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

2010-01-18 Thread Németh Márton
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

2010-01-17 Thread Németh Márton
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

2010-01-17 Thread Németh Márton
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

2010-01-16 Thread Németh Márton
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

2010-01-16 Thread Németh Márton
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

2010-01-16 Thread Németh Márton
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 local functions static

2010-01-16 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

The functions stv0900_sw_algo() and stv0900_set_dvbs1_track_car_loop() are only 
used
locally so mark them static.

This will remove the following sparse warnings (see make C=1):
 * symbol 'stv0900_sw_algo' was not declared. Should it be static?
 * symbol 'stv0900_set_dvbs1_track_car_loop' 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_sw.c
--- a/linux/drivers/media/dvb/frontends/stv0900_sw.cSat Jan 16 07:25:43 
2010 +0100
+++ b/linux/drivers/media/dvb/frontends/stv0900_sw.cSat Jan 16 17:34:44 
2010 +0100
@@ -193,7 +193,7 @@
return lock;
 }

-int stv0900_sw_algo(struct stv0900_internal *intp,
+static int stv0900_sw_algo(struct stv0900_internal *intp,
enum fe_stv0900_demod_num demod)
 {
int lock = FALSE,
@@ -795,7 +795,7 @@
return prate;
 }

-void stv0900_set_dvbs1_track_car_loop(struct stv0900_internal *intp,
+static void stv0900_set_dvbs1_track_car_loop(struct stv0900_internal *intp,
enum fe_stv0900_demod_num demod,
u32 srate)
 {

--
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

2010-01-16 Thread Németh Márton
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

2010-01-16 Thread Németh Márton
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()

2010-01-16 Thread Németh Márton
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

2010-01-14 Thread Németh Márton
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

2010-01-11 Thread Németh Márton
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

2010-01-10 Thread Németh Márton
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

2010-01-10 Thread Németh Márton
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

2010-01-10 Thread Németh Márton
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

2010-01-10 Thread Németh Márton
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

2010-01-10 Thread Németh Márton
][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

2010-01-10 Thread Németh Márton
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


  1   2   3   >