Also merge the "COLORS" control into it as it was V4L2_CID_SATURATION
anyway.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Before this patch sometimes the camera would run out of bandwidth when
running at 640x480@30.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We can only control the clockdivider to control exposure on the pac7311,
making our expo control coarse, switch to an autogain algorithm optimized for
this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that the pac7302 and pac7311 drivers are split, they no longer
share there control settings, so there is no need to scale the controls
to register values, instead make them reflect the registers directly.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It turns out that the flush to sensor command needs to be done per register
bank. We were missing one such flush in set_exposure, causing exposure changes
to only show up when another setting in the same bank also got changed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The pac7302 and pac7311 driver still contains some comments from before
they were separated, such as marking certain functions 7302 or 7311 only,
with the new split drivers these make no sense, remove them.
Also removed the empty/unused sd_stop0 function from pac7311.c
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Allow users of gspca/autogain_functions.h to declare which of the autogain
algoritms they are going to use. This allows us to remove the hacks from
drivers which don't use coarse_grained_expo_autogain.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The exposure of Omnivision sensors is defined by the registers 07, 10 and 04.
This patch updates the registers 10 and 04 before using the registers 2d
and 2e (dummy lines).
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Telling the bridge to update the sensor when setting the exposure or the gain
is not needed when the image transfer is not started.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The i2c interface speed was set to 400 Kb/s while it is 100 Kb/s
for most sensors.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The table did not contain the sensor mt9vprb.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>