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: NJozsef Marton <jmarton@users.sourceforge.net>
Acked-by: NMárton Németh <nm127@freemail.hu>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The gspca_dev field 'frozen' is added only if CONFIG_PM is set. So add the
relevant #ifdef's to various subdrivers that use it.

The m32r daily build caught this mistake.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This looks like a cut an paste error.  This is a two byte array but we
use 8 as a length parameter.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Rename the function v4l2_dont_use_lock to v4l2_disable_ioctl_locking,
and rename v4l2_dont_use_cmd to v4l2_disable_ioctl.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Also merge the "COLORS" control into it as it was V4L2_CID_SATURATION
anyway.
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Enabling vflip leads to a much better image, with vflip disabled the
image looks washed out as if there is a too high brightness setting.

Since we don't know how to lower the brightness setting when not
vflipping, simply always vflip and tell userspace to flip the image back,
resulting in a much better (less washed out) image.

Since the image is now no longer too bright, also modify the luminance
level the auto-gain algorithm aims for.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Our init sequence was not setting the register page to point to bank 1
before setting what should be the control reg. This causes the camera to
sometimes have its LED on after init. First selecting register bank 1,
rather then assuming the current register bank is bank 1, fixes this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now that the pac207 driver has been converted to the control framework, there
are no remaining users.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The pac207's exposure control is a clock-divider, so it goes with quite
big steps. So lets use an autogain algorithm optimised for that.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We intend to eventually port all sub-drivers to the control-framework. At
which point it will make more sense to have the ctrl_handler in gspca_dev
then to have it in the subdrivers. Lets move it there now, to avoid a lot
of work to move it later.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now that stv06xx is using the control framework it is no longer necessary
to have a (non const) copy of sd_desc inside the sd specific data struct.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

HdG:
1) Let the gspca-core cleanup the controls on control-init error, like
with the other converted sub drivers
2) Note this also fixes a bug in the hdcs1020 support which was wrongly
reporting an exposure range of 0-65535, even though the effective range was
only 0-255
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

HdG: Small fix: don't register some controls for sensors which don't
have an implementation for them.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The initial version was done by HV, corrections were made by HdG, and some
final small changes again by HV.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Even with BRC the highest quality setting is not usable, BRC strips so
much data from each MCU that the quality becomes worse then using a lower
quality setting to begin with.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Always automatically adjust the Bit Rate Control setting as needed, independent
of the sensor type. BRC is needed to not run out of bandwidth with higher
quality settings independent of the sensor.

Also only automatically adjust BRC, and don't adjust the JPEG quality control
automatically, as that is not needed and leads to ugly flashes when it is
changed. Note that before this patch-set the quality was never changed
either due to the bugs in the quality handling fixed in previous patches in
this set.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The current code is using bits 0-1 of register 8 of the zc3xx controller
to set the JPEG quality, but the correct bits are bits 1-2. Bit 0 selects
between truncation or rounding in the quantization phase of the compression,
since rounding generally gives better results it should thus always be 1.

This patch also corrects the quality percentages which belong to the 4
different settings.

Last this patch removes the different reg 8 defaults depending on the sensor
type. Some of them where going for a default quality setting of 50%, which
generally is not necessary in any way and results in poor image quality.
75% is a good default to use for all scenarios.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When the user changes the JPEG quality while the camera is streaming, the
driver should not only change the JPEG headers send to userspace, but also
actually tell the camera to use a different quantization table.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The sensor specific dev_post_unset_alt functions all try to write to the
bridge, and none free any memory, so they should be skipped if stop0
is called on disconnection.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Just a small cleanup.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is necessary to ensure that worker-threads accessing the device
are stopped before our disconnect handler returns.

This causes a problem with stream_off calling sd_stop0 a second time
when the device handle is closed. This is fixed by setting
gscpa_dev->streaming to 0 on disconnect.

Note that now stream_off will never be called on a disconnected device,
and the present check can thus be removed from stream_off.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

So that we don't start a read stream when an app is only polling for control
events.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Due to latency concerns the VIDIOC_QBUF, DQBUF and QUERYBUF do not use the
core lock, instead they rely only on queue_lock.

Changes by HdG:
1) Change release from the video_device to the v4l2_device, to avoid a
race on disconnect.
2) Adjust for the V4L2 core changes which cause non ioctl fops to no longer
take the V4L2 core lock.

[mchehab@redhat.com: fix a merge conflict]
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are two bugs here: first the calls to stop0 (in gspca_suspend) and
gspca_init_transfer (in gspca_resume) need to be called with the usb_lock held.
That's true for the other places they are called and it is what subdrivers
expect. Quite a few will unlock the usb_lock in stop0 while waiting for a
worker thread to finish, and if usb_lock isn't held then that can cause a
kernel oops.

The other problem is that a worker thread needs to detect that it has to
halt due to a suspend. Otherwise it will just go on looping. So add tests
against gspca_dev->frozen in the worker threads that need it.

Hdg, 2 minor changes:
1) The finepix device is ok with stopping reading a frame halfway through,
   so add frozen checks in all places where we also check if we're still
   streaming
2) Use gspca_dev->dev instead of gspca_dev->present to check for disconnect
   in all touched drivers. I plan to do this everywhere in the future, and
   most relevant lines in the touched drivers are already modified by this
   patch.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add V4L2_CAP_DEVICE_CAPS support to querycap and replace -EINVAL by
-ENOTTY whenever an ioctl is not supported.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In order to support control event gspca has to use struct v4l2_fh.
As a bonus feature this also gives priority handling for free.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Prepare for control events: free up file->private_data by using
video_drvdata(file) to get to the gspca_dev struct.

[mchehab@redhat.com: fix a compile error: ‘file’ undeclared]
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Make the necessary changes to allow subdrivers to use the control framework.
This does not add control event support, that comes later.

It add a init_control cam_op that is called after init in probe that allows
the subdriver to set up the controls.

HdG: Call v4l2_ctrl_handler_setup from resume instead of
gspca_set_default_mode, as we just want to resend the current ctrl values to
the device.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In case of short marker, the number of received packets was not
incremented doing a zero divide when computing the filling rate.
Reported-by: NHans Petter Selasky <hans.petter.selasky@bitfrost.no>
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Note like all info on the pac73xx chips, this info was found by trial and
error, so it is not necessarily 100% correct.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>