- 29 Dec, 2010 40 commits
-
-
David Härdeman authored
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>
-
David Härdeman authored
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:
-
Jarkko Nikula authored
Convert the driver to use regulator framework instead of set_power callback. This with gpio_reset platform data provide cleaner way to manage chip VIO, VDD and reset signal inside the driver. Signed-off-by:
Jarkko Nikula <jhnikula@gmail.com> Cc: Eduardo Valentin <eduardo.valentin@nokia.com> Signed-off-by:
-
Devin Heitmueller authored
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:
-
Devin Heitmueller authored
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 authored
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 authored
Tweak the comb filter config when in s-video mode to match the Hauppauge Windows driver values (based on register dumps). This work was sponsored by GetWellNetwork Inc. Signed-off-by:
-
Devin Heitmueller authored
Straighten out the clamp control configurations for the various video modes, based off of register diffs done against the Hauppauge Windows driver. This work was sponsored by GetWellNetwork Inc. Signed-off-by:
-
Devin Heitmueller authored
Cleanup the routine which disables the audio decoder. In particular, the i2s output was being shut off but the audio processor itself was not, resulting in more power being consumed than needed. Signed-off-by:
-
Devin Heitmueller authored
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 authored
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 authored
The chip's default value for the brightness didn't match what we were sending back in the queryctrl ioctl(), so if the application actually set the brightness to the "default", it would actually end up being way too bright. This work was sponsored by GetWellNetwork Inc. Signed-off-by:
-
Jean-François Moine authored
Signed-off-by:
Jean-François Moine <moinejf@free.fr> Signed-off-by:
-
Jean-François Moine authored
Signed-off-by:
-
Jean-François Moine authored
The bad value prevented the autogain to work correctly and some images were truncated. Signed-off-by:
-
Jean-François Moine authored
Signed-off-by:
-
Jean-François Moine authored
Signed-off-by:
-
Hans de Goede authored
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:
-
Hans de Goede authored
gspca_xirlink_cit: Add support camera button Signed-off-by:
-
Hans de Goede authored
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 authored
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 authored
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 authored
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:
-
Malcolm Priestley authored
DM04/QQBOX USB Timing change. Improved timing to avoid USB corruptions on some systems. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Malcolm Priestley authored
Corrected Firmware Information for LG on LME2510. Signed-off-by:
-
Malcolm Priestley authored
Improved frontend handling. Frontend now remains open at all times, with signal lock, snr & signal level polled from Interupt. Updated driver for DM04/QQBOX USB DVB-S BOXES to version 1.70. Signed-off-by:
-
Daniel Drake authored
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/10190Signed-off-by:
Daniel Drake <dsd@laptop.org> Acked-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Joe Perches authored
Converted if (debug >= 2) printk(KERN_DEBUG... to if debug >= 2) dprintk(...) Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
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 authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
By comparing the traffic between Pixelview (cx23102-based and Kworld (saa7134-based), the only difference is at register 0xd5. After some tests, It seems that it is used to change mode between serial and parallel. Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
This adds the trivial bits to mb86a20s. As the driver won't touch at the channel/layer parameters, this may not be enough for receiving all channels, especially ISDB-Tsb, but the driver worked properly for receiving video channels on my tests. Signed-off-by: -
Mauro Carvalho Chehab authored
This device uses an em2874B + Sharp 921 One Seg frontend. Signed-off-by:
Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
On our tests with Leadership ISDBT, the s921 frontend were not work. As its design contained some weird things, it ended to be easier to just re-write it, getting another frontend as an example (cx24123). As the old s921 driver weren't used, there's no regression. Some info from the old frontend were used as a way to double check the behavior that were noticed on the USB dumps retrieved from Leadership driver. Signed-off-by:
-
Linus Torvalds authored
-
