- 21 Oct, 2010 40 commits
-
-
Paul Walmsley authored
When digitizing composite video from a analog videotape source using the TVP5150's first composite input channel, the captured stream exhibits tearing and synchronization problems[1]. It turns out that commit c0477ad9 caused "TV mode" (as opposed to "VCR mode" or "auto-detect") to be forcibly enabled for both composite inputs. According to the chip documentation[2], "TV mode" disables a "chrominance trap" input filter, which appears to be necessary for high-quality video capture from an analog videotape source. [ Commit c7c0b34c subsequently restricted the problem to the first composite input, apparently inadvertently. ] Since any type of composite signal source can be connected to the TVP5150's first composite input, unconditionally forcing "TV mode" isn't correct. There doesn't appear to be a good way for applications to tell the driver what is connected. Fortunately, the TVP5150 has an operating mode auto-detection feature, which, when enabled, should cause the TVP5150 to auto-detect whether it should use "VCR mode" or "TV mode". Enabling operating mode auto-detection improved video capture quality significantly[3]. Therefore, fix this bug by using operating mode auto-detection. (Also, while here, fix a CodingStyle issue.) For those users who may find this patch via a mailing list archive but who are not able to upgrade to a kernel with a fixed driver: the TVP5150's S-Video and second composite input sources have auto-detection enabled, so you may wish to try using those -- if available on your device -- until this fix makes it a downstream distribution near you. 1. Pre-patch tvtime snapshot using a Pinnacle PCTV HD Pro as the capture device and a Sony EV-S2000 as a video source: http://www.booyaka.com/~paul/tvp5150/1a.png 2. Section 3.21.3, "Operation Mode Control Register", _TVP5150AM1 Ultralow-Power NTSC/PAL/SECAM Video Decoder (Rev. D)_ [SLES209D], downloaded 8 October 2010, available via http://focus.ti.com/lit/ds/symlink/tvp5150am1.pdf 3. Post-patch tvtime snapshot (same signal chain as #1, above): http://www.booyaka.com/~paul/tvp5150/1b.pngSigned-off-by:
Paul Walmsley <paul@booyaka.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Maxim Levitsky authored
This is a result of last round of debug with Sami R <maesesami@gmail.com>. Thank you Sami very much! The biggest bug I fixed is that, I was clobbering the CIRCFG register after it is setup That wasn't a good idea really And some small refactoring, etc. Tested-by:
Sami R <maesesami@gmail.com> Signed-off-by:
Maxim Levitsky <maximlevitsky@gmail.com> Acked-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Maxim Levitsky authored
Add new keys, found on: Toshiba Qosmio F50-10q. Toshiba Qosmio X300 Toshiba A500-141 Also sort the keytable by scancode number as that makes sense and alows easily to add new keycodes. Thanks to: Sami R <maesesami@gmail.com> Alexander Skiba <ghostlyrics@gmail.com> Jordi Pelegrin <pelegrin.jordi@gmail.com> For reports and testing. Signed-off-by:
-
Jarod Wilson authored
The driver was missing KERN_ facilities on a number of printks. The register dump functions have been updated to use KERN_INFO, so that the register dump gets logged in syslog (they only run on driver load, and only when debug is enabled). The buffer dump routine now uses KERN_DEBUG, as that spew will happen quite frequently (several times every IR signal), and shouldn't need to be logged. Also split up the small handful of lines that were just over 80 characaters, and fixed the ioctl.h include. Signed-off-by:
-
Dan Carpenter authored
Add a check after the for loops to see if we found what we were looking for or if we reached the end of the list. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Ben Hutchings authored
CONFIG_FONTS has nothing to do with whether find_font() is defined. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Acked-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Andrew Morton authored
It was missing the `break'. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=18672Reported-by:
Igor <i2g2r2@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: stable@kernel.org Signed-off-by:
-
Maxim Levitsky authored
* Add support for newer firmware version that uses different buffer format. Makes hardware work for many users. * Register name updates * Lot of refactoring * Lots of fixes as a result of full testing * Idle mode is done now by resetting the device, and this eliminates the ugly sample_period = 75 hack. Every feature of the driver is now well tested. Signed-off-by:
-
Mauro Carvalho Chehab authored
Be sure to rollback all init if input register fails. Cc: Maxim Levitsky <maximlevitsky@gmail.com> Acked-by:
-
Maxim Levitsky authored
As soon as input device is registered, it might be accessed (and it is) This can trigger a hardware interrupt that can access not yet initialized ir->raw, (by sending a sample) This can be reproduced by holding down a remote button and reloading the module. And this always crashes the systems where hardware decides to send an interrupt right at the moment it is enabled. Signed-off-by:
-
Maxim Levitsky authored
Unfortunelly (my fault) the kernel thread that now handles IR processing has classical races in regard to wakeup and stop. This patch hopefully closes them all. Tested with module reload running in a loop, while receiver is blasted with IR data for 10 minutes. Signed-off-by:
-
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
The rc map table were corrected thanks to Giorgio input and tests. Reported-by:
Giorgio Vazzana <mywing81@gmail.com> Tested-by:
-
Tommy Jonsson authored
Add support for tuning with PSK8 modulation, pilot and rolloff with the S2 versions of firedtv. Signed-off-by:
Tommy Jonsson <quazzie2@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (trivial simplification) Signed-off-by:
-
Mauro Carvalho Chehab authored
It is possible that, while ir_unregister_class() is handling, some application could try to access the sysfs nodes, causing an OOPS. Reviewed-by:
-
Dan Carpenter authored
There is an integer overflow here because 0x03000000 * 1000 is too large for 31 bits. rawir.duration should be in terms of nsecs. IR_MAX_DURATION and 0x03000000 are already in terms of nsecs. STREAMZAP_TIMEOUT and STREAMZAP_RESOLUTION are 255 and 256 respectively and are in terms of usecs. The original code had a deadline of 1.005 seconds and the new code has a deadline of .065 seconds. Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
As pointed out (and tested) by Joris van Rantwijk, we do actually need to wire up .compat_ioctl for 32-bit lirc userspace to work with 64-bit lirc kernelspace. Do it. And add a check to make sure we get a valid irctl in the ioctl handler. Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
>From Joris van Rantwijk <jorispubl@xs4all.nl>: I tested lirc_serial and found that it works fine. Except the LIRC ioctls do not work in my 64-bit-kernel/32-bit-user setup. I added compat_ioctl entries in the drivers to fix this. While doing so, I noticed inconsistencies in the argument type of the LIRC ioctls. All ioctls are declared in lirc.h as having argument type __u32, however there are a few places where the driver calls get_user/put_user with an unsigned long argument. The patch below changes lirc_dev and lirc_serial to use __u32 for all ioctl arguments, and adds compat_ioctl entries. It should probably also be done in the other low-level drivers, but I don't have hardware to test those. I've dropped the .compat_ioctl addition from Joris' original patch, as I swear the non-compat definition should now work for both 32-bit and 64-bit userspace. Technically, I think we still need/want a in getting a reply to you). Reported-by:
Joris van Rantwijk <jorispubl@xs4all.nl> Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
Per discussion with Andy Walls on irc, rx fifo overruns are not all that uncommon on a busy system, and the initial posting of the nuvoton-cir driver doesn't handle them well enough. With this addition, we'll drain the hw fifo, attempt to process any ir pulse trains completed with that flush, then we'll issue a hw rx fifo clear and reset the raw ir sample kfifo and start over collecting raw ir data. Also slightly refactors the cir interrupt enabling so that we always get consistent flags set and only have to modify them in one place, should they need to be altered. Signed-off-by:
-
Jarod Wilson authored
This is a new ir-core pnp driver for the Nuvoton w836x7hg integrated CIR function. The chip is found on at least the ASRock ION 330HT boxes and apparently, on a number of Intel DP55-series motherboards: http://www.asrock.com/nettop/overview.asp?Model=ION%20330HT http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17685&lang=eng This driver was made possible by a hardware donation from Nuvoton, along with sample code (in the form of an lirc driver) and datasheet, so huge thanks to them for supporting this effort. Note that this driver constitutes a massive rewrite, porting from the lirc interfaces to the ir-core interfaces, and restructuring the driver to look more like Maxim Levitsky's ene_ir driver (as well as generally making it look more like kernel code). There's some work left to be done on this driver, to fully support the range of functionality possible, but receive and IR power-on/wake are both functional (may require setting wake key under another OS atm). The hardware I've got (one of the ASRock boxes) only supports RX, so TX is completely untested as of yet. Certain RX parameters, like sample resolution and RX IRQ sample length trigger level could possibly stand to be made tweakable via modparams or sysfs nodes, but the current values work well enough for me w/an MCE RC6A remote. The original lirc driver carried support for the Windows MCE IR keyboard/mouse device, which I plan to add back generically, in a way that should be usable by any raw IR receiver (or at least by this driver and the mceusb driver). Suspend and resume have also been tested, the power button on my remote can be used to wake the machine, and CIR functionality resumes just fine. Module unload/reload has also been tested, though not extensively or repetitively. Also tested to work with the lirc bridge plugin for userspace decoding. 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
Signed-off-by:
-
Jean-François Moine authored
The new control mechanism uses dynamic control values in the subdriver descriptor. It simplifies standard control handling. Signed-off-by:
-
Laurent Pinchart authored
Take the ctrl_mutex mutex before touching control information in those functions. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
XU control information is supposed to be entirely discoverable using standard UVC queries. As some devices report bogus information (such as reporting a read-only control as being read-write), add a fixup table for XU controls. This table can also be used to selectively disable requests supposed to be supported by all XU controls (GET_MIN, GET_MAX, GET_DEF, GET_RES) but not correctly (or at all) supported by the device. The table currently disables GET_CUR on the Logitech motor control XU pan/tilt controls. Signed-off-by:
-
Laurent Pinchart authored
XU controls initialization requires querying the device for control information. As some buggy UVC devices will crash when queried repeatedly in a tight loop, delay XU controls initialization until first use. Signed-off-by:
-
Laurent Pinchart authored
Now that control information structures are not shared between control instances, embed a uvc_control_info instance inside the uvc_control structure instead of storing a pointer. Signed-off-by:
-
Martin Rubli authored
This patch removes the sysadmin requirements for UVCIOC_CTRL_MAP (and the stub implementation of UVCIOC_CTRL_ADD). This requirement no longer makes sense with the new XU control access mechanisms since XU controls can be accessed without adding control mappings first. A maximum number (currently 1024) of control mappings per device is enforced to avoid excess memory consumption caused by careless user space applications. Signed-off-by:
Martin Rubli <martin_rubli@logitech.com> Signed-off-by:
-
Laurent Pinchart authored
Devices advertise XU controls using a bitmask, in which each bit corresponds to a control. The control selector, used to query the control, isn't available in the USB descriptors. All known UVC devices use control selectors equal to the control bit index plus one. Hardcode that relationship in the driver, making the UVCIOC_CTRL_ADD ioctl obsolete. All necessary information about XU controls can be obtained by the driver at enumeration time. The UVCIOC_CTRL_ADD ioctl is still supported for compatibility reasons, but now always returns -EEXIST. Finally, control mappings are now on a per-device basis and no longer global. As this changes the userspace interface, bump the driver version number to 1.0.0 (it was about time). Signed-off-by:
-
Laurent Pinchart authored
Increase the sequence number of the v4l2_buffer structure regardless of any buffer states, so that discontinuous sequence numbers allow applications to detect lost video frames. Signed-off-by:
-
Laurent Pinchart authored
The bandwidth estimate computed with the FIX_BANDIWDTH quirk is too low for many cameras. Don't use maximum packet sizes lower than 1024 bytes to try and work around the problem. According to measurements done on two different camera models, the value is high enough to get most resolutions working while not preventing two simultaneous VGA streams at 15 fps. Signed-off-by:
-
Laurent Pinchart authored
Signed-off-by:
-
Laurent Pinchart authored
Instead of printing the query hex value in error messages, print its name to make the messages more readable. Signed-off-by:
-
Laurent Pinchart authored
They're not modified by the function, make them const. Signed-off-by:
-
Laurent Pinchart authored
The Hercules Dualpix Exchange (06f8:3005) camera expose an absolute zoom that is not implemented. Blacklist it. Signed-off-by:
-
