The problem tackled in this patch is how to handle volatile autoclusters
correctly. A volatile autocluster is a cluster of related controls where one
control is the control that toggles between manual and auto mode and the other
controls are the values for the manual mode. For example autogain and gain,
autoexposure and exposure, etc.
If the hardware lets you read out the automatically calculated manual values
while in automode, then those manual controls should be marked volatile.
gain value as calculated by the autogain circuitry, then you would mark the
gain control as volatile (i.e. continuously changing).
The question in such use cases is what to do when switching from the auto
mode to the manual mode. Should we switch to the last set manual values or
should the volatile values be copied and used as the initial manual values.
For example: suppose the mode is manual gain and gain is set to 5. Then
autogain is turned on and the gain is set by the hardware to 2. Finally
the user switches back to manual gain. What should the gain be? 2 or 5?
After a long discussion the decisions was made to keep the last value as
calculated by the auto mode (so 2 in the example above).
The reason is that webcams that do such things will adapt themselves to
the current light conditions and when you switch back to manual mode you
expect that you keep the same picture. If you would switch back to old
manual values, then that would give you a suddenly different picture,
which is jarring for the user.
Additionally, this would be difficult to implement in applications that
store and restore the control values at application exit and start.
If you want to keep the old manual values when you switch from auto to
manual, then there would have to be a way for applications to get hold
of those old values while in auto mode, but there isn't.
So this patch will do all the heavy lifting in v4l2-ctrls.c: if you go
from auto mode to manual mode and the manual controls are volatile, then
g_volatile_ctrl will be called to get the current values for the manual
controls before switching to manual mode.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the new flag there is no need anymore to have a separate is_volatile
field. Modify all users to use the new flag.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
checkpatch.pl gave some coding style errors, so on the way to the first
patch I added the fix to them.
Signed-off-by: Arvydas Sidorenko <asido4@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The probem was on my DC-1125 webcam chip from Syntek. Whenever the webcam turns
on, the LED light on it is turn on also and never turns off again unless system
is shut downed or restarted.
This patch will fix this issue - the LED will be turned off whenever the device
is released.
Signed-off-by: Arvydas Sidorenko <asido4@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When we moved to 3.0, we found that the cx18 driver was oopsing on close with:
NULL pointer deref at:
[ 2290.461009] Call Trace:
[ 2290.461009] [<c046007b>] ? pm_qos_add_request+0xc/0x6e
[ 2290.461009] [<c082631c>] __mutex_lock_common+0x87/0x125
[ 2290.461009] [<f8970e92>] ? cx18_queue_flush+0x31/0x87 [cx18]
[ 2290.461009] [<c0436b85>] ? __might_sleep+0x29/0xe4
[ 2290.461009] [<c0826515>] __mutex_lock_slowpath+0x25/0x27
[ 2290.461009] [<c08264b2>] ? mutex_lock+0x2e/0x3b
[ 2290.461009] [<c08264b2>] mutex_lock+0x2e/0x3b
[ 2290.461009] [<f88d3137>] videobuf_queue_lock+0x13/0x15 [videobuf_core]
[ 2290.461009] [<f88d3f86>] __videobuf_free+0xfc/0x112 [videobuf_core]
[ 2290.461009] [<f89741e6>] cx18_v4l2_close+0x158/0x172 [cx18]
[ 2290.461009] [<c0507522>] ? cpumask_next+0x1a/0x1d
[ 2290.461009] [<f88a319d>] v4l2_release+0x35/0x52 [videodev]
[ 2290.461009] [<c04f5717>] fput+0x100/0x1a5
[ 2290.461009] [<c04f2e09>] filp_close+0x5c/0x64
[ 2290.461009] [<c04f2e70>] sys_close+0x5f/0x93
[ 2290.461009] [<c082cd5f>] sysenter_do_call+0x12/0x28
Some digging showed that a merge at some previous point partially
added broken mmap() support, causing this trace. Remove the broken
code completely.
On top of that, the calculation in place for "buffer full" depended on
UYUV instead of HM12, while our GStreamer code was picking HM12 in
some circumstances.
Finally, the V4L2_CAP_STREAMING capability was never exposed. Patch it
into the YUV encoder node only.
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Release the dev->alt_max_pkt_size buffer in all cases.
Signed-off-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* tag 'v3.1-rc6': (1902 commits)
Linux 3.1-rc6
ioctl: register LTTng ioctl
fuse: fix memory leak
fuse: fix flock breakage
Btrfs: add dummy extent if dst offset excceeds file end in
Btrfs: calc file extent num_bytes correctly in file clone
btrfs: xattr: fix attribute removal
Btrfs: fix wrong nbytes information of the inode
Btrfs: fix the file extent gap when doing direct IO
Btrfs: fix unclosed transaction handle in btrfs_cont_expand
Btrfs: fix misuse of trans block rsv
Btrfs: reset to appropriate block rsv after orphan operations
Btrfs: skip locking if searching the commit root in csum lookup
btrfs: fix warning in iput for bad-inode
Btrfs: fix an oops when deleting snapshots
[media] vp7045: fix buffer setup
[media] nuvoton-cir: simplify raw IR sample handling
[media] [Resend] viacam: Don't explode if pci_find_bus() returns NULL
[media] v4l2: Fix documentation of the codec device controls
[media] gspca - sonixj: Fix the darkness of sensor om6802 in 320x240
...
The MT9P031 is a parallel 12-bit 5MP sensor from Aptina (formerly
Micron) controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports skipping,
cropping, automatic binning, and gain, exposure, h/v flip and test
pattern controls.
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/video/omap3isp/isp.h is not a proper location for a header
that needs to be included from board code. Move the platform data
definitions to media/omap3isp.h.
Board code still needs to include isp.h to get the struct isp_device
definition and access OMAP3 ISP platform callbacks. Those callbacks will
be replaced by more generic code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Make sure the pipeline has a valid video source (either a subdev with no
sink pad, or a non-subdev entity) at stream-on time and return -EPIPE if
no video source can be found.
Reported-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
dvb_usb_device_init calls the frontend_attach method of this driver which
uses vp7045_usb_ob. In order to have a buffer ready in vp7045_usb_op, it has to
be allocated before that happens.
Luckily we can use the whole private data as the buffer as it gets separately
allocated on the heap via kzalloc in dvb_usb_device_init and is thus apt for
use via usb_control_msg.
This fixes a
BUG: unable to handle kernel paging request at 0000000000001e78
reported by Tino Keitel and diagnosed by Dan Carpenter.
Cc: stable@kernel.org # For v3.0 and upper
Tested-by: Tino Keitel <tino.keitel@tikei.de>
Signed-off-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The nuvoton-cir driver was storing up consecutive pulse-pulse and
space-space samples internally, for no good reason, since
ir_raw_event_store_with_filter() already merges back to back like
samples types for us. This should also fix a regression introduced late
in 3.0 that related to a timeout change, which actually becomes correct
when coupled with this change. Tested with RC6 and RC5 on my own
nuvoton-cir hardware atop vanilla 3.0.0, after verifying quirky
behavior in 3.0 due to the timeout change.
Reported-by: Stephan Raue <sraue@openelec.tv>
CC: Stephan Raue <sraue@openelec.tv>
CC: stable@vger.kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the unlikely case that pci_find_bus() should return NULL
viacam_serial_is_enabled() is going to dereference a NULL pointer and
blow up. Better safe than sorry, so be defensive and check the
pointer.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The images are clearer with a lower bridge clock.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bug was introduced by git commit 0e4d413af1, giving very dark images.
Signed-off-by: Luiz Carlos Ramos <lramos.prof@yahoo.com.br>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The list of the webcams which have LED inversion was rebuild scanning
ms-win .inf files.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
'!' has higher precedence than '&' so we need parenthesis here.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In vidioc_enum_fmt_vid_cap, the 'compressed' flag was set from the
pixelformat, and all pixelformats were not treated.
Now, images are told as compressed when the image size is smaller than
its number of pixels.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
For USB speeds different of 'low', the bInterval value is logarithmic.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The webcam is build from an Omnivision test kit which contains a OV538 bridge
and a OV9712 sensor.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The variable gspca_debug is defined and settable in gspca main.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The contrast was too low. Higher values are better.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
