- 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>
Checkpatch compliance cleanup across files in the saa7164 driver.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This isn't a runtime bug, it's just to make static checkers happy.
In vidioc_querycap() we copy a saa7164_dev ->name driver array into a
v4l2_capability -> driver array. The ->driver array is only 16 chars
long so ->name also can't be more than 16 characters.
The ->name gets set in v4l2_capability() and it always is less than 16
characters so we can easily make the buffer smaller.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If the adapter does not support I2C_FUNC_SMBUS_WRITE_BYTE,
return -EIO instead of 0.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There was a bug at cx231xx-input, where it were registering the remote
controls twice, one via ir-kbd-i2c and another directly.
Also, the patch that added rc_register_device() broke compilation for it.
This patch fixes cx231xx-input by fixing the depends on, to point to the
new symbol, and initializing the scanmask via platform_data.
While here, also fix Kconfig symbol change for IR core dependencies.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are several fields on rc_dev that drivers can benefit. Allow drivers
to pass it as a parameter to the driver.
For now, the rc_dev parameter is optional. If drivers don't pass it, create
them internally. However, the best is to create rc_dev inside the drivers,
in order to fill other fields, like open(), close(), driver_name, etc.
So, a latter patch making it mandatory and changing the caller drivers is
welcome.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch merges the ir_input_dev and ir_dev_props structs into a single
struct called rc_dev. The drivers and various functions in rc-core used
by the drivers are also changed to use rc_dev as the primary interface
when dealing with rc-core.
This means that the input_dev is abstracted away from the drivers which
is necessary if we ever want to support multiple input devs per rc device.
The new API is similar to what the input subsystem uses, i.e:
rc_device_alloc()
rc_device_free()
rc_device_register()
rc_device_unregister()
[mchehab@redhat.com: Fix compilation on mceusb and cx231xx, due to merge conflicts]
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
cx88 only depends on VIDEO_IR because it needs ir_extract_bits().
Move that function to ir-core.h and make it inline.
Lots of drivers had dependencies on VIDEO_IR when they really
wanted IR_CORE.
The only remaining drivers to depend on VIDEO_IR are bt8xx and
saa7134 (ir_rc5_timer_end is the only function exported by
ir-functions).
Rename VIDEO_IR -> IR_LEGACY to give a hint to anyone writing or
converting drivers to IR_CORE that they do not want a dependency
on IR_LEGACY.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch removes the remaining usages of the ir_input_nokey() and
ir_input_keydown() functions provided by drivers/media/IR/ir-functions.c
by using the corresponding functionality in ir-core instead.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch converts the cx88 driver (for sampling hw) to use the
decoders provided by ir-core instead of the separate ones provided
by ir-functions (and gets rid of those).
The value for MO_DDS_IO had a comment saying it corresponded to
a 4kHz samplerate. That comment was unfortunately misleading. The
actual samplerate was something like 3250Hz.
The current value has been derived by analyzing the elapsed time
between interrupts for different values (knowing that each interrupt
corresponds to 32 samples).
Thanks to Mariusz Bialonczyk <manio@skyboo.net> for testing my patches
(about one a day for two weeks!) on actual hardware.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Because some clients (e.g. tvtime) will just open the filehandle and call
read() instead of explicitly calling streamon first, we need to make sure the
VBI timeout routine gets enabled in this case.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The first pass of fixes to cause the driver to continue streaming even when
there is no video arriving over the ITU656 bus were not adequate. Continue
the work from the previous patch.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We need the au0828 to continue delivering frames even when the device is not
delivering video, or else applications such as tvtime will block indefinitely.
Unfortunately, the au8522 doesn't have any sort of free-running mode or "blue
screen on no video" like some other decoders.
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix the alignment of fields being delivered by the driver, which was
resulting in jerky video when there was horizontal motion (since the bottom
field of the frame was being sent with the top field of the previous frame)
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We had the max packets per URB set to an incredibly low "10" as opposed to
the Windows driver which has it as 128. Set the value to match the
Windows driver, which will reduce interrupts considerably.
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.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>
If you suspend and resume during video capture, the video colours
are corrupted on resume. This is because the sensor is being unconditionally
powered off during the resume path.
Only power down during resume if the camera is not in use, and correctly
reconfigure the sensor during resume.
Fixes http://dev.laptop.org/ticket/10190
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Although cx231xx has a very good IR support, already supported by
mceusb driver, some designs decided to add a separate I2C
microcontroller chip in order to handle IR.
Due to that, add a glue to ir-kbd-i2c is needed, in order to support
those devices.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
