The USB traces are better done by usbmon which is enabled in most Linux/GNU
distributions and which permits easier comparison with the USB exchanges of
other drivers.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
__devinit* must not be used in USB drivers.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use the expression "video stream" instead of "color camera" which is
more correct as the driver supports the RGB and IR image on the same
endpoint.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move large communications buffers out of stack and into device
structure. This prevents the frame size from being >1kB and fixes a
compiler warning when CONFIG_FRAME_WARN=1024:
drivers/media/video/gspca/kinect.c: In function ‘send_cmd.clone.0’:
drivers/media/video/gspca/kinect.c:202: warning: the frame size of 1548 bytes is larger than 1024 bytes
Reported-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Drew Fisher <drew.m.fisher@gmail.com>
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
usb_altnum_to_altsetting() may return NULL. If it does we'll dereference a
NULL pointer in
drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c::pb0100_start().
As far as I can tell there's not really anything more sensible than
-ENODEV that we can return in that situation, but I'm not at all intimate
with this code so I'd like a bit of review/comments on this before it's
applied.
Anyway, here's a proposed patch.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Cc: Jean-Francois Moine <moinejf@free.fr>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Erik Andren <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Kinect sensor is a device used by Microsoft for its Kinect project,
which is a system for controller-less Human-Computer interaction
targeted for Xbox 360.
In the Kinect device, RGBD data is captured from two distinct sensors: a
regular RGB sensor and a monochrome sensor which, with the aid of a IR
structured light, captures what is finally exposed as a depth map; so
what we have is basically a Structured-light 3D scanner.
The Kinect gspca subdriver just supports the video stream for now,
exposing the output from the RGB sensor or the unprocessed output from
the monochrome sensor; it does not deal with the processed depth stream
yet, but it allows using the sensor as a Webcam or as an IR camera (an
external source of IR light might be needed for this use).
The low level implementation is based on code from the OpenKinect
project (http://openkinect.org).
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes a bug in gspca, more precisely in alt_xfer().
This function looks for an input transfer endpoint in an alternate setting.
By default it returns the first endpoint corresponding to the transfer type
indicated in parameter.
But with some USB devices, the first endpoint corresponding to the transfer
type is not always an INPUT endpoint but an OUTPUT one.
This patch adds the endpoint direction test to be sure to return an INPUT endpoint
Signed-off-by: Patrice CHOTARD <patricechotard@free.fr>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
No 352x288 for Ds3303 and no 320x240 for Generic802.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This file contains functions for the auto gain.
It must be used with the new control mechanism.
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Not only the qx3 microscope has a button, but some cameras too. Tested
with the Trust sp@cecam 100 (and with a creative and ezcam without button).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Having a framerate divisor of 3 is not really necesarry and leads to
various troubles (frames going missing, compression issues) when allowed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a complete rewrite of the old v4l1 vicam subdriver, featuring
multiple resolutions, gain + exposure control and still has less code.
Oh and it is a v4l2 driver rather then v4l1 ofcourse :)
Many thanks to Devin Heitmueller <dheitmueller@kernellabs.com> for
donating his 3com homeconnect to me, which made this rewrite possible.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In good lighting conditions (lots of details visible) the current buffers
are sometimes too small.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This fixes the led not working on this camera
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Tested with a camera with usb-id: 0c45:62bb
Also enable dmi based flopped laptop detection for the 0c45:627b ov7660 model.
Some of the MSI laptops with upside down camera have this one instead of the
0c45:624f.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Tested with a camera with usb-id: 0c45:62bb
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
During image capture, the filling rate of the isoc packets is computed.
It is then used by a work queue to update the current JPEG quality.
Tested-by: Franck Bourdonnec <fbourdonnec@chez.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
A marker 'ff ff 00 c4 c4 96' indicates an end of frame.
It is 62 bytes long and may be splitted on 2 packets.
It contains a flag 'USB full' which indicates that the frame is truncated.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In some cases, some frames may not end with the JPEG end of frame.
Being not complete, they are now discarded.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The problem was introduced by the commit 2af0b4c60c.
Some registers were no more initialized.
Tested-by: <Giovanni Scafora giovanni@archlinux.org>
Tested-by: <Sergey Manucharian sm@ingeniware.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The infrared was set by sensor write instead of bridge GPIO.
It is now settable by the standard control ILLUMINATOR_1.
A module parameter permits to set the right GPIO bit according
to the StarCam model.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
__devinit* must not be used in USB drivers.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While going through windows inf file I found more usb-id, add a comment
with this id for future reference.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Looking at the windows inf file, for usb ids with a sensor type where probing
is needed to determine the type (for example ov7630 or soi768), this is
needed for all bridge variants with a usb id indicating this sensor type.
So do the probing to determine the actual sensor type for types where the
usb-id info is not 100% deterministic, independent of the bridge type.
If you look through the list of currently active usb ids in sonixj, this
effectively only changes the code path for 0c45:60fe (sn9c105 + ov7630) and
0c45:612e (sn9c110 + ov7630), which according to the inf file can have a
soi768 instead of a ov7630 just like the sn9c120 + ov7630 models where we
already probe for a soi7630.
The main reason for this code change is to keep the code paths as bridge
variant independent as possible, so that we don't need a lot of special
per bridge cases, as we enable more usb-ids in the future.
This change makes the 0c45:60fe code path identical to the successfully
tested 0c45:613e, so also make sonixj the default driver for 0c45:60fe.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Both we and the windows driver make no sensor specific differences
(with some exceptions) for different sonixj bridge types. Thus if a
sn9c105 bridge has been successfully tested with a sensor, the same
sensor can be successfully used with a sn9c120 bridge too.
Using this knowledge we can move over most usb-ids too the sonixj
driver when both are compiled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that our bridge code is unified for sn9c101/102 and sn9c103 models,
the sn9c103 models should simply work, given that the only difference
in the sn9c103 is audio support and a gamma correction table.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Also fix the issue of the image being mirrored.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Refactor the code to unify how the sn9c101/102 and the sn9c103 bridge
are handled. Also move code which is the same for all sensors from
the per sensor init register settings to a central place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We check for not streaming as a condition to abort waiting in dqbuf, so
when another thread does a streamoff we should wake the wq.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some applications (xawtv, qv4l2) mix read and mmap calls. Allow switching
from read mode back to mmap mode (by doing a reqbufs).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_dev->memory == GSPCA_MEMORY_NO implies gspca_dev->nframes == 0,
so there is no need to check for both in dev_poll. The check in
dev_read also is more complex then needed, as dqbuf which dev_read
calls already does all necessary checks. Moreover dqbuf is holding
the proper locks while checking where as dev_read itself is not.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Before this patch we were not setting the memory type to GSPCA_MEMORY_NO
when the buffers were released by the app doing a reqbufs 0. Nor would
the memory type be set to GSPCA_MEMORY_NO on device close, as capture_file
already is NULL on device close because of the reqbufs 0. This caused the
following problem:
-app1 does reqbufs USERPTR for 4 buffers
-app1 does reqbufs USERPTR for 0 buffers
-app2 tries to do reqbufs MMAP for 4 buffers
fails because gspca_dev->memory still is USERPTR
Fixing this also allows an app to switch memory type's by unrequesting
the buffers and re-requesting them of a different type.
This patch also moves the setting of gspca_dev->frsz and gscpa_dev->memory
to after alloc_frame succeeding, so that they are not changed when allocating
fails.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove the no longer used / useful users variable, and with that gone
there also is no longer a need to take queue_lock in dev_open.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Before this patch dqbuf errors out on a failing user_copy (with user pointers)
before updating the buffer flags, causing a successsfully dequeued buffer
to still have the DONE flag, which means that it could no longer be
re-queueud (assuming the app somehow survives the segfault).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Before this patch vidioc_dqbuf is using its own read_lock, where as
other queue related functions use queue_lock. This means that dqbuf is
accessing several variables in a racy manor. The most important one
being fr_o, which may be changed from underneath dqbuf by vidioc_reqbufs
or vidioc_streamoff. Other variables which it accesses unprotected
are gspca_dev->memory, gspca_dev->streaming and gspca_dev->capt_file.
This patch fixes this by changing vidioc_dqbuf to also use the queue_lock.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The gspca_dev->streaming boolean is protected against multiple access
through gspca_dev->queue_lock everywhere except for 2 places. This patch
fixes this by bringing it under the lock in vidioc_streamoff. And by
removing the check for gspca_dev->streaming in gspca_disconnect,
the destroy_urbs call may be called multiple times (and is protected
by the usb_lock) and calling wake_up_interruptible can also always be done
safely.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The check for status errors is now before the check for len. That's
ok. However, the error printk's for the status error prints the URB
length. This generates this error:
drivers/media/video/gspca/gspca.c: In function ‘fill_frame’:
drivers/media/video/gspca/gspca.c:305:9: warning: ‘len’ may be used uninitialized in this function
The fix is as simple as moving the len init to happen before the checks.
Cc: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When an error is set for an isochronous packet, the length of the packet
may be null. In this case, the error was not detected and the image
was not discarded as it should be.
Reported-by: Franck Bourdonnec <fbourdonnec@chez.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
These are OmniVision's OV7660 and OV9630.
Don't register the webcam when they are found.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds the Vendor:Product number of the Lego Bionicle camera to
the existing gspca/sq905c.c and also a line for the camera in gspca.txt.
The camera works "out of the box" with these small changes. So this is
just in time for Christmas. Think of the children.
Signed-off-by: Theodore Kilgore <kilgota@auburn.edu>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for cameras with the HV7131D sensor, such as the 0c45:602a
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Our old start of frame detection code wrongly assumes that the sof
marker always lives at the beginning of the frame. At least for the
0c45:602a camera this is not the case. This patch also improves
the framerate from 28 fps to 30 fps with the 0c45:6005 and 0c45:6007
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I've a 0c45:6007 camera and it works fine with the gspca_sonixb driver,
so make that handle it instead of the deprecated sn9c102 driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Support for mt9m001 (mi1300) is broken:
- Table is incomplete;
- Only one resolution is currently supported by the driver;
- Resolution is incomplete;
- it complains about broken JPEG headers.
Use the same init found on em28xx driver, and properly report the
output format as 8-bits GRAY.
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Changeset 35680ba broke several devices:
- Sony Playstation Eye (1415:2000);
- Gigaware model 25-234 (0c45:628f);
- Logitech Messenger Plus (046d:08f6).
Probably more devices were broken by this change.
What happens is that several devices don't need to save some bandwidth
for audio.
Also, as pointed by Hans de Goede <hdegoede@redhat.com>, the logic
that implements the bandwidth reservation for audio is broken, since
it will reduce the alt number twice, on devices with audio.
So, let's just revert the broken logic, and think on a better solution
for usb 1.1 devices with audio that can't use the maximum packetsize.
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use macros for the supported scales, instead of using magic numbers
from 0 to 3.
Code become cleaner by using macros for it.
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of just assuming a ov9650 sensor based on USB ID,
double-check it, by reading the sensor ID.
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- start and stop streaming are done via the FRAR
- streaming suspend (for control change) is done by video reset
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It looks to me like it was intended to check the return value
at this point.
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch also checks if the sensor is well detected at connection time.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
stv06xx devices have only one altsetting, but the actual used
bandwidth can be programmed through a register. We were already
setting this register lower then the max packetsize of the altsetting
indicates. This patch makes the gspca-stv06xx update the usb descriptor
for the alt setting to reflect the actual packetsize in use, so that
the usb subsystem uses the correct information for scheduling usb transfers.
This patch also tries to fallback to lower speeds in case a ENOSPC error
is received when submitting urbs, but currently this is only supported
with stv06xx cams with the pb0100 sensor, as this is the only one for
which we know how to change the framerate.
This patch is based on an initial incomplete patch by
Lee Jones <lee.jones@canonical.com>
Signed-off-by: Lee Jones <lee.jones@canonical.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bad value prevented the autogain to work correctly
and some images were truncated.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Generate a release button event when the button is still pressed when the
stream stops.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_xirlink_cit: Add support camera button
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
At least on the ibm netcam pro frames have a 4 byte footer, take this
into account when calculating sizeimage.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following usb bandwidth allocation changes were made to the ibm netcam
pro code:
- Don't restart negotiation at max packet size on stop0, as that gets called
by gspca_main during negotiation. Move this to sd_isoc_init.
- Don't ask for full bandwidth when running at 160x120, that does not need
full bandwidth
- Make minimum acceptable bandwidth depend upon resolution
[mchehab@redhat.com: Fix CodingStyle problems at switch statements]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently alloc_and_submit_int_urb() is setting gspca->int_urb
as soon as the allocation has succeeded, but if the subsequent
submit fails, the urb gets destroyed. And then later will
get destroyed again in gspca_input_destroy_urb() because
gspca->int_urb is set, leading to a double free.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently gspca supported usb-1.1 webcams for which we support the input
button through an interrupt endpoint won't stream (not enough bandwidth
error) when used through an USB-2.0 hub.
After much debugging I've found out that the cause for this is that the
ehci-sched.c schedeling code does not like it when there are already urb's
scheduled when (large) isoc urbs are queued. By moving the submission
of the interrupt urbs to after submitting the isoc urbs the camera
starts working again through usb-2.0 hubs.
Note that this does not fix isoc. streaming through a usb-hub while another
1.1 usb device (like the microphone of the same cam) is also active
at the same time :(
I've spend a long time analyzing the linux kernel ehci scheduler code,
resulting in this (long) mail:
http://www.spinics.net/lists/linux-usb/msg37982.html
The conclusion of the following mail thread is that yes there are several
issues when using usb-1.1 devices through a usb-2.0 hub, but these are not
easily fixable in the current code. Fixing this in ehci-sched.c requires
an almost full rewrite, which is not bound to happen anytime soon.
So with this patch gspca driven usb-1.1 webcams will atleast work when
connected through an usb-2.0 hub when the microphone is not used.
As an added bonus this patch avoids extra destroy/create input urb cycles
when we end up falling back to a lower speed alt setting because of bandwidth
limitations.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The initial values of the registers 0x01 and 0x17 are taken from the sensor
table at capture start and updated according to the flag PDN_INV.
Their values are updated at each step of the capture initialization and
memorized for reuse in capture stop.
This patch also fixed automatically some bad hardcoded values of these
registers.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
value as other webcams with the same sensor. For now, only two webcams have
been so detected: the Microsoft's VX1000 and VX3000.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The errors were found by checkpatch.pl. Most fixes are:
- remove spaces followed by TAB(s),
- split lines greater than 80 characters,
- move most '{'s from start of line to end of previous line.
(Some '{'s at start of line remain when the '}'s are on the same line)
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The PO2030N sensor chip found in hama AC-150 webcam supports horizontal
and vertical flipping the image by hardware.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The number 0xdd is used for marking delay init sequence steps.
Replace 0xdd values only if the meaning is delay.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bug was introduced by commit d5aa3856fd
removing the probe sequence of hv7131r with bridge sn9c120 and so, letting
the sensor inactive.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bug was introduced by commit 23a98274cc
applying values of sensor sp80708 to sensors hv7131r and mi0360.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When audio is present, some alternate settings were skipped.
This prevented some webcams to work, especially when bulk transfer was used.
This patch permits to use the last or only alternate setting.
Reported-by: Antonio Ospite <ospite@studenti.unina.it>
Tested-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch also sets to 0 the sequence of the first frame.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The new control mechanism uses dynamic control values in the subdriver
descriptor. It simplifies standard control handling.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver sn9c102 does not know about the sensor mi0360b.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The 'end of image' block may be splitted between two ISOC packets.
This case was not tested, so, some images could be lost and concatenated
to previous one(s), raising 'frame overflow' errors.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With a null request byte, these commands prevented the next commands
to be executed.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The illuminator controls should only be available to the user for the Intel
Play QX3 microscope. The implementation to inhibit the controls is intended to
be consistent with the other gspca driver implementations.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Turn the lights of the QX3 on (or off) as needed when resuming and at module load.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds basic V4L2 controls for the illuminators on the Intel
Play QX3 microscope.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When compressed, the images take less than one byte per pixel.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/video/gspca/konica.c: In function ‘sd_start’:
drivers/media/video/gspca/konica.c:322: error: implicit declaration of function ‘usb_buffer_alloc’
drivers/media/video/gspca/konica.c:325: warning: assignment makes pointer from integer without a cast
make[3]: ** [drivers/media/video/gspca/konica.o] Erro 1
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_xirlink_cit: adjust ibm netcam pro framerate for available bandwidth
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This new driver replaces the (known to not work / crash) usbvideo konicawc
driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_*: correct typo in my email address in various subdrivers
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some xirlink_cit models have only 1 alt setting, but the actual used
bandwidth can be programmed through a register use this to allow streaming
while other isoc streams (for example sound) are active at the same time.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_xirlink_cit: Use alt setting -> fps formula for model 1 cams too
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for camera with a bcd version of 0.01, I've dupped these
Model0 cams.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Note this is untested as I don't have hardware to test, but all
initsequences were taken over 1 on 1 from the old ibmcam driver so things
should work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The old usbvideo ibmcam driver needs to be replaced with a v4l2 driver
preferably using the gspca webcam framework rather then the old usbvideo
framework.
This new gspca sub driver sets a first step in that direction. The ibmcam
driver supports 4 different model webcams. This new driver (for now) only
supports Model 3 cameras, as my test cam is a Model 3 cam, or so I thought.
Upon reading:
http://www.linux-usb.org/ibmcam/
I learned that the IBM Netcamera Pro I have even though having the same
usb id and the same bcd version is different from the Model 3 cameras
supported by the ibmcam driver. So this new gscpa subdriver supports Model 3
cameras (untested), and the IBM Netcamera Pro. Currently use with the
IBM Netcamera Pro requires a module parameter. I hope to be able to
autodetect which is which in the future.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As the end of frame marker does not contain any pixel, it must not be
transferred.
Reported-by: Ivo Jager <ivo.jager@siliconfields.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When plugging some webcams on ARM, the system crashes.
This is because we alloc buffer for an urb through usb_buffer_alloc,
the alloced buffer is already in DMA coherent region, so we should
set the flag of this urb to URB_NO_TRANSFER_DMA_MAP, otherwise when
we submit this urb, the hcd core will handle this address as an
non-DMA address and call dma_map_single/sg to map it. On arm
architecture, dma_map_single a DMA coherent address will be catched
by a BUG_ON().
Signed-off-by: Jason Wang <jason77.wang@gmail.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The exchanges for sensor mt9v111 are different with bridges zc301 and zc303.
The exchanges for the bridge zc303 were those of the bad named tas5130ck.
These mt9v111 exchanges have been adjusted from the ms-Windows public files
vm30x.inf (for 0ac8:301b) and usbvm303.inf (for 0ac8:303b).
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The new exchanges are extracted from the public file lPEPI264v.inf of the
ms-Windows driver. In this file, the sensor is named hv7131b but the exchanges
are those of the hv7131r.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- use an enum to define the sensor numbers
- use the sensor numbers to index the associated tables
- rename TAS5130CXX to TAS5130C
- rename HV7131C to HV7131R
- change some comments
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some webcams as ov511 may find many times an end of image.
In this case, with the last patch in image concatenation
(commit 799b1bd41f398054d46fd35f73abd01c4009f6ca),
the image pointer was NULL and the system crashed in memcpy().
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On laptops, the webcam sometimes disconnects when writing the first main
register (b300). This patch prevents the creation of a new /dev/video<n>
on streaming start.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The added controls are exposure, gain, autogain and backlight compensation.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The JPEG format did not work fine. The Bayer format offers correct VGA (640x480)
resolution, but bad QQVGA (160x120). This last resolution is removed.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bit 7 of the sensor gain register multiplies the 7bits value by two.
It is now always set with half the user gain value.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The start_1 exchange must be done by (reg, val) * 5 and not 8.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The sensor enum definition was not at the right place.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The first VC0321 settings were done at webcam connection only. They must also
be done on resume after suspend.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bit 0x04 of the bridge register 02 (GPIO) is used for audio connection
in webcams containing the bridge SN9C105. This patch sets it correctly,
according to the presence of an audio device.
Tested-by: Kyle Baker <kyleabaker@gmail.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When there is an audio device, use a lower alternate setting.
This patch does not fix correctly all audio and bandwidth problems.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes possible race conditions in queue management with SMP:
when a frame was completed, the irq function tried to use the next frame
buffer. At this time, it was possible that the application on an other
processor updated the frame pointer, making the image to point to a bad
buffer.
The patch contains two main changes:
- the image transfer uses the queue indexes which are protected against
simultaneous memory access,
- the image pointer which is used for image concatenation is only set at
interrupt level.
Some subdrivers which used the image pointer have been updated.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The problem may occur with SMP:
- a frame is completed at interrupt level (in gspca_frame_add with
packet_type == LAST_PACKET,
- just after clearing the bit V4L2_BUF_FLAG_QUEUED and before setting
the bit V4L2_BUF_FLAG_DONE, on the other processor, the application
tries to requeue the same frame buffer,
- then, the qbuf function succeeds because ALL_FLAGS are not set.
The fix sets and resets the two flags in one instruction.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The image pointer and its length are now in the main structure instead
of in the frame buffer. They are updated on application vidioc_qbuf and
in the URB interrupt function when ending an image.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On 05/29/10 01:30, Jean-Francois Moine wrote:
> On Fri, 28 May 2010 13:03:28 -0400
> Amerigo Wang<amwang@redhat.com> wrote:
>
>> Subject: [PATCH 6/6] Remove obsolete zc0301 v4l driver
>>
>> Duplicate functionality with the gspca_zc3xx driver, zc0301 only
>> supports 2 USB-ID's (because it only supports a limited set of
>> sensors) wich are also supported by the gspca_zc3xx driver
>> (which supports 53 USB-ID's in total).
>
> You forgot to remove the conditionnal compilation in the gspca_zc3xx
> driver (USB_DEVICE(0x046d, 0x08ae) in gspca/zc3xx.c)
>
Right, thanks for pointing this out!
Attached is the updated patch, please use this one instead.
Thanks!
Duplicate functionality with the gspca_zc3xx driver, zc0301 only
supports 2 USB-ID's (because it only supports a limited set of
sensors) wich are also supported by the gspca_zc3xx driver
(which supports 53 USB-ID's in total).
Signed-off-by: Amerigo Wang <amwang@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use kmemdup when some other buffer is immediately copied into the
allocated region.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression from,to,size,flag;
statement S;
@@
- to = \(kmalloc\|kzalloc\)(size,flag);
+ to = kmemdup(from,size,flag);
if (to==NULL || ...) S
- memcpy(to, from, size);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
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 <nm127@freemail.hu>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Extra spaces to align some variable names and a defined value
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Change of rounded image resolutions to the real ones for MI2020 sensor
in order to discard 2 random lines in the bottom of images
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Setting changes applied after an end of image marker reception
This is the way MI2020 sensor works.
It seems to be logical to wait for a complete image before
to change a setting.
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- 1 ms "msleep" applied to each sensor after USB control data exchange
This was done for two sensors because these exchanges were known to
be too quick depending on laptop model.
It is fairly logical to apply this delay to each sensor
in order to prevent from having errors with untested hardwares.
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- new MI2020 driver version made from a webcam gift
- all previous flavors of this driver removed
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This function is used when the USB video interface is checked by
the subdriver.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- variable / function rename
- set the gains in one exchange
- don't alter the register 80 which contains the AWB flag
and other sensor specific values
- the global gain is now the average of the R, G and B gains.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch also renames the last polling message from the closer one
of the ms-windows driver.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The new table is sorted and extracted from a clear part of the MS-Windows
driver.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
