- 21 Sep, 2011 35 commits
-
-
Michael Grzeschik authored
Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Sylwester Nawrocki authored
s_stream does nothing in current form so remove it. Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Kyungmin Park <kyungin.park@samsung.com> Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
Now that the auto cluster core changed to a different scheme of how to handle volatile controls (including how to switch from auto to manual mode) the pwc code can be simplified to use that new core support. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
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:
-
Steven Toth authored
Thanks to Greg Tangey for prompting me to merge this. Signed-off-by: -
Antti Palosaari authored
it9135 was the only one intended with spaces as others are tabs. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Antti Palosaari authored
msleep() => usleep_range() Signed-off-by:
-
Antti Palosaari authored
Signed-off-by:
-
Chris Rankin authored
Signed-off-by:
Chris Rankin <rankincj@yahoo.com> Signed-off-by:
-
Antti Palosaari authored
Signed-off-by:
-
Antti Palosaari authored
TDA10071 firmware version 1.21.31.2 Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
Michael Krufky <mkrufky@kernellabs.com> Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
-
Antti Palosaari authored
It is based of... * Empia EM28174 * NXP TDA10071 & Conexant CX24118A combo * Allegro A8293 Signed-off-by:
-
Antti Palosaari authored
NXP TDA10071 DVB-S/S2 demodulator & Conexant CX24118A tuner combo driver Signed-off-by:
-
Antti Palosaari authored
Signed-off-by:
-
Hans Verkuil authored
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 authored
Add a new VOLATILE control flag that is set for volatile controls. That way applications know whether the value of the control is volatile (i.e. can change continuously) or not. Until now this was an internal property, but it is useful to know in userspace as well. A typical use case is the gain value when autogain is on. In that case the hardware will continuously adjust the gain based various environmental factors. This patch just adds and documents the flag, it's not yet used. Signed-off-by:
-
- 18 Sep, 2011 5 commits
-
-
Arvydas Sidorenko authored
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:
-
Arvydas Sidorenko authored
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:
-
Daniel Drake authored
This enables module autoloading. Signed-off-by:
Daniel Drake <dsd@laptop.org> Acked-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Simon Farnsworth authored
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:
-
Chris Rankin authored
Release the dev->alt_max_pkt_size buffer in all cases. Signed-off-by:
-
