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

[Németh Márton]

Acked-by: Márton Németh 

Jozsef Marton wrote:
> From: Jozsef Marton 
> 
> 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 
> ---
> 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

[Németh Márton]

Mauro Carvalho Chehab írta:
> Em 22-12-2011 07:42, Németh Márton escreveu:
>> From: Márton Németh 
>>
>> 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 
>> ---
>>
>> 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 
> 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 
> Signed-off-by: Dan Carpenter 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> 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;
> + }
>   

[PATCH] v4l2: handle multiplication overflow

[Németh Márton]

From: Márton Németh 

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

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

[Németh Márton]

Lars Noschinski wrote:
> * Németh Márton  [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 unplug&replug: 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

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

[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 1/2] gspca_sonixj: add hardware vertical flip support for hama AC-150

[Németh Márton]

Hi Jean-Francois,

Jean-Francois Moine wrote:
> On Sun, 17 Oct 2010 13:08:01 +0200
> Németh Márton  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

Re: [PATCH RFC] gspca_sonixj: handle return values from USB subsystem

[Németh Márton]

Hi,
Jean-Francois Moine írta:
> On Sun, 17 Oct 2010 16:45:03 +0200
> Németh Márton  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: Old patches sent via the Mailing list

[Németh Márton]

Mauro Carvalho Chehab wrote:
>   == Gspca patches - Waiting Hans de Goede  
> review == 
> 
> Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown packet received 
>   http://patchwork.kernel.org/patch/75837   Németh Márton 
> 

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

[PATCH RFC] gspca_sonixj: handle return values from USB subsystem

[Németh Márton]

From: Márton Németh 

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

Re: em28xx in v4l-dvb destroyed my USB TV card

[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] gspca_sonixj: remove magic numbers for delay

[Németh Márton]

From: Márton Németh 

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 
---
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 po1030_sensor_init[][8] = {
 /* the sensor registers are

[PATCH 1/2] gspca_sonixj: add hardware vertical flip support for hama AC-150

[Németh Márton]

From: Márton Németh 

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 
---
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 2/2] gspca_sonixj: add hardware horizontal flip support for hama AC-150

[Németh Márton]

From: Márton Németh 

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

mem2mem_testdev: BUG: unable to handle kernel NULL pointer dereference

[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 
 * 20 Jun 2010
 * Released under GPL.
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

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 totalpages: 245518
[0.00] free_area_init_node: node 0, pgdat c04afb00, node_mem_map 
c1001020

[PATCH] gspca_pac7302: add Genius iSlim 310

[Németh Márton]

From: Márton Németh 

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

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

Re: genius islim 310 webcam test

[Németh Márton]

Jean-Francois Moine írta:
> On Wed, 31 Mar 2010 07:56:59 +0200
> Németh Márton  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

[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 

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

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

[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 

Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK

[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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK

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

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.

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: problem compiling modoule mt9t031 in current v4l-dvb-hg

[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

[PATCH] gspca cpia1: make local functions static

[Németh Márton]

From: Márton Németh 

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 
---
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 command_setecptiming(struc

Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK

[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,  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,  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,  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,  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] bttv: fix compiler warning before kernel 2.6.30

[Németh Márton]

From: Márton Németh 

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 
---
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: [PATCH 1/2] bttv: Move I2C IR initialization

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

[RFC, PATCH 3/3] gspca pac7302: remove LED blinking when switching stream on and off

[Németh Márton]

From: Márton Németh 

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

[RFC, PATCH 2/3] gspca pac7302: separate LED handling

[Németh Márton]

From: Márton Németh 

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 
---
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 
+ * LED control by Márton Németh 
  * Copyright (C) 2009-2010 Márton Németh 
  *
  * 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 
 #include 
+#include 
+#include 
 #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 streaming)
+{
+   struct sd *sd = (struct sd *) gspca_dev;
+   u8 data = 0;
+
+   if (sd->led)

[RFC, PATCH 1/3] gspca: add LEDs subsystem connection

[Németh Márton]

From: Márton Németh 

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 
---
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 
 #include 
 #include 
+#include 
+#include 
 #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 
  *
  * 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,
+ sizeof(gspca_dev->cam.leds[i].name),
+ gspca_dev->vdev.num);
+
+   gspca_dev->cam.leds[i].led_cdev.n

[PATCH] az6027: remove redundant condition check

[Németh Márton]

From: Márton Németh 

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

az6027: variables may be used uninitialized in az6027_i2c_xfer()

[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

Re: [PATCH] tlg2300: cleanups when power management is not configured

[Németh Márton]

Hi,
Huang Shijie wrote:
> hi Marton, thanks a lot.
> 
>> From: Márton Németh
>>
>> 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
>> ---
>> diff -r 37581bb7e6f1 linux/drivers/media/video/tlg2300/pd-dvb.c
>> --- a/linux/drivers/media/video/tlg2300/pd-dvb.c Wed Feb 24 22:48:50 
>> 2010 -0300
>> +++ b/linux/drivers/media/video/tlg2300/pd-dvb.c Sun 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
>> -}
>>
>>
> I think the change here is a little more complicated.I prefer to change 
> it like this :
> 
> static void poseidon_fe_release(struct dvb_frontend *fe)
> {
> #ifdef CONFIG_PM
>  struct poseidon *pd = fe->demodulator_priv;
>  pd->pm_suspend = NULL;
>  pd->pm_resume  = NULL;
> #endif
> }
> 
> Could you change the patch, and resend it to me ?
> thanks.

I'm afraid in this case we'll get a warning saying that the parameter fe is 
unused.
Here is an example:

$ gcc -Wall -O2 -Wextra test.c
test.c: In function ‘foo’:
test.c:2: warning: unused parameter ‘x’
$ cat test.c

static void foo(int x)
{

}

int main()
{
foo(0);
return 0;
}

The second reason I modified the code like this is that the the .release
opreation is used with the following sequence:

if (dvb->frontend->ops.release)
dvb->frontend->ops.release(dvb->frontend);

If power management is not configured then the symbol poseidon_fe_release will 
be
NULL and the condition dvb->frontend->ops.release will be false. So the 
otherwise
empty function will not be called at all.

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] tlg2300: make local variables and functions static

[Németh Márton]

From: Márton Németh 

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 
---
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-03-01 
07:26:41.0 +0100
@@ -161,7 +161,8 @@ 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 +204,8 @@ 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 +248,8 @@ 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 +261,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_con

Re: [PATCH 1/3] add feedback LED control

[Németh Márton]

Jean-Francois Moine wrote:
> On Sun, 28 Feb 2010 08:55:04 +0100
> Németh Márton  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

[PATCH] tlg2300: make local variables and functions static

[Németh Márton]

From: Márton Németh 

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 
---
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 = file->private_data;
@@ -285,7 

[PATCH] nGene: use NULL when pointer is needed

[Németh Márton]

From: Márton Németh 

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 
---
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: cleanups when power management is not configured

[Németh Márton]

From: Márton Németh 

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

Re: [PATCH] Input: scancode in get/set_keycodes should be unsigned

[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 
--
To unsubscribe from this list: send the line "unsubscribe 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 3/3] gspca pac7302: remove LED blinking when switching stream on and off

[Németh Márton]

From: Márton Németh 

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 
---
--- 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 2/3] gspca pac7302: add LED control

[Németh Márton]

From: Márton Németh 

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 
---
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 
+ * LED control by Márton Németh 
  * Copyright (C) 2009-2010 Márton Németh 
  *
  * 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;
+
+   *val = sd->led;
+   return 0;
+}
+
+static int sd_querymen

[PATCH 1/3] add feedback LED control

[Németh Márton]

From: Márton Németh 

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 
---
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 .
  
+ 
+   V4L2_CID_LED
+   enum
+   Controls 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 enum v4l2_led are:
+V4L2_CID_LED_AUTO (0),
+V4L2_CID_LED_ON (1) and
+V4L2_CID_LED_OFF (2).
+ 

   
 
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

Re: [PATCH] Input: scancode in get/set_keycodes should be unsigned

[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

Re: [PATCH 1/2] gspca pac7302: allow controlling LED separately

[Németh Márton]

Hi,
Jean-Francois Moine wrote:
> On Sat, 27 Feb 2010 08:53:16 +0100
> Hans de Goede  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 1/2] gspca pac7302: allow controlling LED separately

[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émeth
>>
>> 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

[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 

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 
---
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 
+ * LED control by Márton Németh 
  * Copyright (C) 2009-2010 Márton Németh 
  *
  * 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 
 #include 
+#include 
+#include 
 #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))
+   sd->led_cdev.brightness_set(&sd->led_cdev,
+   sd->led_cdev.brightness);
+#else
+   sd-

[PATCH 2/2] gspca pac7302: remove LED blinking when switching stream on and off

[Németh Márton]

From: Márton Németh 

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

[PATCH 1/2] gspca pac7302: allow controlling LED separately

[Németh Márton]

From: Márton Németh 

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 
---
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 
+ * LED control by Márton Németh 
  * Copyright (C) 2009-2010 Márton Németh 
  *
  * 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 
 #include 
+#include 
+#include 
 #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, gspca_dev);

+#ifndef CONFIG_LEDS_CLASS
+   sd->led = 0;
+#endif
/* stop stream */
-   reg_w

Linux testers wanted for Genius iSlim 310

[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 

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 
---
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] gspca pac7302: add USB PID range based on heuristics

[Németh Márton]

Hi,
Jean-Francois Moine wrote:
> On Wed, 24 Feb 2010 08:09:41 +0100
> Németh Márton  wrote:
> 
>> 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.
> 
> Hello,
> 
> I got such information from ms-win drivers. I appeared that most of the
> unknown/new webcams were never manufactured. Now, I wait for user
> requests before adding such webcams.

What about Genius iSlim 310? Based on the Windows driver this device is
a potential candidate for pac7302 driver, see
http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302#Identification

I don't have access to Genius iSlim 310 so I cannot tell it for sure.

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 USB PID range based on heuristics

[Németh Márton]

From: Márton Németh 

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

[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 
>>
>> 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 *
>>
>> as well as a couple more signedness mismatches.
>>
>> Signed-off-by: Márton Németh 
>> Signed-off-by: Guennadi Liakhovetski 
> 
> 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 commen

[PATCH 2/2] gspca pac7302: remove LED blinking when switching stream on and off

[Németh Márton]

From: Márton Németh 

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 
---
--- a/linux/drivers/media/video/gspca/pac7302.c 2010-02-08 20:46:47.0 
+0100
+++ b/linux/drivers/media/video/gspca/pac7302.c 2010-02-08 20:48:04.0 
+0100
@@ -331,13 +331,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 */
@@ -373,7 +366,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,
@@ -397,8 +391,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 */
 };

@@ -496,15 +488,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)
@@ -774,7 +757,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

[PATCH 1/2] gspca pac7302: add LED control

[Németh Márton]

From: Márton Németh 

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 
---
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 Mon Feb 08 20:46:53 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 
+ * LED control by Márton Németh 
  * Copyright (C) 2009-2010 Márton Németh 
  *
  * 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()
@@ -78,6 +80,11 @@
 MODULE_DESCRIPTION("Pixart PAC7302");
 MODULE_LICENSE("GPL");

+#define PAC7302_CID_LED (V4L2_CID_PRIVATE_BASE + 0)
+#define LED_AUTO   0
+#define LED_ON 1
+#define LED_OFF2
+
 /* specific webcam descriptor for pac7302 */
 struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
@@ -91,6 +98,7 @@
unsigned char gain;
unsigned char exposure;
unsigned char autogain;
+   unsigned char led;
__u8 hflip;
__u8 vflip;
u8 flags;
@@ -126,6 +134,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 +303,20 @@
.set = sd_setvflip,
.get = sd_getvflip,
},
+   {
+   {
+   .id  = PAC7302_CID_LED,
+   .type= V4L2_CTRL_TYPE_MENU,
+   .name= "LED",
+   .minimum = 0,
+   .maximum = 2,   /* 0: Auto, 1: On, 2: Off */
+   .step= 1,
+#define LED_DEF 0
+   .default_value = LED_DEF,
+   },
+   .set = sd_setled,
+   .get = sd_getled,
+   },
 };

 static const struct v4l2_pix_format vga_mode[] = {
@@ -572,6 +596,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 +741,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 LED_AUTO:
+   if (streaming)
+   data = 0x01;
+   else
+   data = 0x40;
+   break;
+   case LED_ON:
+   if (streaming)
+   data = 0x01;
+   else
+   data = 0x00;
+   break;
+   case 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 +802,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 +818,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 +1172,44 @@
return 0;
 }

+static int sd_setled(struct gspca_dev *gspca_dev, __s32 val)
+{
+   struct sd *sd 

Re: [PATCH libv4l tree, RFC] libv4l: skip false Pixart markers with buffer copy

[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 

Before trying to decode the image data filter the PixArt markers out.

Signed-off-by: Márton Németh 
---
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_reservoir= 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 &= ((1U<>(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, 
priv->stream_filtered,
+   priv->stream_end_filtered, HUFFMAN_HASH_NBITS, hcode);
   value = huffman_table->lookup[hcode];
   if (value >= 0)
   {
@@ -457,7 +466,8 @@
{
  nbits = HUFFMAN_HASH_NBITS + 1 + extra_nbits;

- pixart_look_nbits(priv->reservoir, priv->nbits_in_reservoir, 
priv->stream, nbits, hcode);
+ pixart_look_nbits(priv->reservoir, priv->nbits_in_reservoir, 
priv->stream_filtered,
+   priv->stream_end_filtered, nbits, hcode);
  slowtable = huffman_table->slowtable[extra_nbits];
  /* Search if the code is 

Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

[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

Re: libv4l: possible problem found in PAC7302 JPEG decoding

[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: [PATCH ] libv4l: skip false Pixart markers

[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émeth
>>
>> 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émeth
>> ---
>> 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

[PATCH ] libv4l: skip false Pixart markers

[Németh Márton]

From: Márton Németh 

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

libv4l: possible problem found in PAC7302 JPEG decoding

[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, RFC] gspca pac7302: add USB PID range based on heuristics

[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 

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 
---
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: PAC7302 short datasheet from PixArt

[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

Re: PAC7302 short datasheet from PixArt

[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
> 
> First, I am glad that mouse-copying reproduces the accent in your name. If 
> you can help explain how to reproduce such things by typing while using 
> apine over an ssh connection, using a standard US keyboard, I would be 
> glad of the explanation. My wife is Hungarian, and I am thus very 
> sensitized to the importance of the question, how to do the accents 
> required for writing Hungarian properly.

I just set up the Hungarian layout keyboard ( 
http://en.wikipedia.org/wiki/Keyboard_layout#Hungary )
in KDE and use it with UTF-8 encoding.

Regards,

Márton Németh
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pac7302 sporadic plug-in problem fix for 2.6.33?

[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

PAC7302 short datasheet from PixArt

[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

Re: [PATCH gspca_jf tree] gspca zc3xx: signal when unknown packet received

[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émeth
>> ---
>> 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

[PATCH] smsir: make local variables static

[Németh Márton]

From: Márton Németh 

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

[PATCH] hdpvr-core: make module parameters local

[Németh Márton]

From: Márton Németh 

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 
---
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 gspca_jf tree] gspca zc3xx: signal when unknown packet received

[Németh Márton]

Signed-off-by: Márton Németh 
---
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

Re: Make failed - standard ubuntu 9.10

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

Re: [PATCH] uvcvideo: check minimum border of control

[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: [PATCH] uvcvideo: check minimum border of control

[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 
>> ---
>>  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: Make failed - standard ubuntu 9.10

[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,  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()

[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 

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

Signed-off-by: Márton Németh 
---
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(&cl

Re: [PATCH] gspca pac7302: add support for camera button

[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 
> 
> Add support for snapshot button found on Labtec Webcam 2200.
> 
> Signed-off-by: Márton Németh 
> ---
> 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 
> + * Camera button input handling by Márton Németh 
> + * Copyright (C) 2009-2010 Márton Németh 
>   *
>   * 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 
>  #include 
>  #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

[PATCH] gspca pac7302: add support for camera button

[Németh Márton]

From: Márton Németh 

Add support for snapshot button found on Labtec Webcam 2200.

Signed-off-by: Márton Németh 
---
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 
  *
  * Separated from Pixart PAC7311 library by M�rton N�meth 
+ * Camera button input handling by Márton Németh 
+ * Copyright (C) 2009-2010 Márton Németh 
  *
  * 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 
 #include 
 #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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

[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: [PATCH] soc_camera: match signedness of soc_camera_limit_side()

[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 

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

Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS

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

The last cron message I saw was on 23rd January, 2010. All warnings and errors
were fixed since then ;-) or is there some problem with the cron job?

Regarsd,

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

[Németh Márton]

From: Márton Németh 

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

Signed-off-by: Márton Németh 
---
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   Wed Jan 27 20:49:57 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.cWed Jan 27 20:49:57 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;

@@ -577,7 +577,7 @@
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 : %d = %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,12 +638,12 @@
  * 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);
-   unsigned int skip, resize, input_w = *in_w, input_h = *in_h,
+   int skip, resize, input_w = *in_w, input_h = *in_h,
output_w = *out_w, output_h = *out_h;
u16 inc_sel, wb_bit8, wb_left, wb_right, wb_top, wb_bottom;
unsigned int peak, peak_50, peak_60;
@@ -655,7 +655,7 @@
 * case we have to either reduce the input window to equal or below
 * 512x384 or the output window to equal or below 1/2 of the input.
 */
-   if (output_w > max(512U, input_w / 2)) {
+   if (output_w > max(512, input_w / 2)) {
if (2 * output_w > RJ54N1_MAX_WIDTH) {
input_w = RJ54N1_MAX_WIDTH;
output_w = RJ54N1_MAX_WIDTH / 2;
@@ -663,11 +663,11 @@
input_w = output_w * 2;
}

-   dev_dbg(&client->dev, "Adjusted output width: in %u, out %u\n",
+   dev_dbg(&client->dev, "Adjusted output width: in %d, out %d\n",
input_w, output_w);
}

-   if (output_h > max(384U, input_h / 2)) {
+   if (output_h > max(384, input_h / 2)) {
if (2 * output_h > RJ54N1_MAX_HEIGHT) {
input_h = RJ54N1_MAX_HEIGHT;
output_h = RJ54N1_MAX_HEIGHT / 2;
@@ -675,7 +675,7 @@
input_h = output_h * 2;
}

-   dev_dbg(&client->dev, "Adjusted output height: in %u, out %u\n",
+   dev_dbg(&client->dev, "Adjusted output height: in %d, out %d\n",
input_h, output_h);
}

@@ -749,7 +749,7 @@
 * 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, 15);

inc_sel = 1 << skip;

@@ -819,7 +819,7 @@
*out_w

Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()

[Németh Márton]

Guennadi Liakhovetski wrote:
> On Sat, 23 Jan 2010, Németh Márton wrote:
> 
>> From: Márton Németh 
>>
>> 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 ) 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 *
> 
> 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 
>> ---
>> 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 2>&1 |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 fir

Re: [PATCH 1/2, RFC] gspca: add input support for interrupt endpoints

[Németh Márton]

Hello Jean-Francois,

do you have any comments or suggestions about this patch?

Regards,

Márton Németh

Hans de Goede wrote:
> Hi,
> 
> Looks good to me now.
> 
> Regards,
> 
> Hans
> 
> On 01/18/2010 09:01 PM, Németh Márton wrote:
>> From: Márton Németh
>>
>> Add support functions for interrupt endpoint based input handling.
>>
>> Signed-off-by: Márton Németh
>> ---
>> diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c
>> --- a/linux/drivers/media/video/gspca/gspca.cSun Jan 17 07:58:51 
>> 2010 +0100
>> +++ b/linux/drivers/media/video/gspca/gspca.cMon 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
>> + *
>>* 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
>> +#include
>> +
>>   /* 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 a

[PATCH] uvcvideo: check minimum border of control

[Németh Márton]

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 .

Signed-off-by: Márton Németh 
---
 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: git problem with uvcvideo

[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

git problem with uvcvideo

[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

[RFC, PATCH] gspca pac7302: propagate footer to userspace

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

Re: [PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

[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  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] hdpvr-video: cleanup signedness

[Németh Márton]

From: Márton Németh 

The fifth parameter of usb_bulk_msg() is a pointer to signed
(see ) 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 *

Signed-off-by: Márton Németh 
---
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

[PATCH] zoran: remove variable shadowing

[Németh Márton]

From: Márton Németh 

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 
---
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] soc_camera: match signedness of soc_camera_limit_side()

[Németh Márton]

From: Márton Németh 

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

Signed-off-by: Márton Németh 
---
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

Re: [PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

[Németh Márton]

Jean-Francois Moine írta:
> On Fri, 22 Jan 2010 18:54:46 -0200
> Mauro Carvalho Chehab  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] zoran: match parameter signedness of g_input_status

[Németh Márton]

From: Márton Németh 

The second parameter of g_input_status operation in 
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 *

Signed-off-by: Márton Németh 
---
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

[Németh Márton]

From: Márton Németh 

Add support functions for interrupt endpoint based input handling.

Signed-off-by: Márton Németh 
---
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 
+ *
  * 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 
+#include 
+
 /* 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:
+   usb_buff

Re: [PATCH 1/2, RFC] gspca: add input support for interrupt endpoints

[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

[PATCH 2/2, RFC] gspca pac7302: add support for camera button

[Németh Márton]

From: Márton Németh 

Add support for snapshot button found on Labtec Webcam 2200.

Signed-off-by: Márton Németh 
---
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 
  *
  * Separated from Pixart PAC7311 library by M�rton N�meth 
+ * Camera button input handling by Márton Németh 
+ * Copyright (C) 2009-2010 Márton Németh 
  *
  * 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 
 #include 
 #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 1/2, RFC] gspca: add input support for interrupt endpoints

[Németh Márton]

From: Márton Németh 

Add support functions for interrupt endpoint based input handling.

Signed-off-by: Márton Németh 
---
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 
+ *
  * 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 
+#include 
+
 /* 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] dib0090: cleanup dib0090_dcc_freq()

[Németh Márton]

From: Márton Németh 

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

[PATCH] bt819: cleanup v4l2_subdev_notify() parameters

[Németh Márton]

From: Márton Németh 

The 3rd parameter v4l2_subdev_notify() is passed to the notify() callback
which is a pointer, see  and .

This will remove the following sparse warning (see "make C=1"):
 * Using plain integer as NULL pointer

Signed-off-by: Márton Németh 
---
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] stv0900: make more local functions static

[Németh Márton]

From: Márton Németh 

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 
---
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] stv0900: make local functions static

[Németh Márton]

From: Márton Németh 

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