- 12 Sep, 2009 40 commits
-
-
Brian Johnson authored
Signed-off-by:
Brian Johnson <brijohn@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Brian Johnson authored
Using the MT9M111's IFP to handle exposure/gain gives better results. Signed-off-by:
-
Brian Johnson authored
Signed-off-by:
-
Joe Perches authored
Use s16 instead of int where possible. Use struct instead of arrays Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Brian Johnson authored
Fixes broken exposure on SOI968 webcams that was causing the camera to display a black screen Signed-off-by:
-
Jean-Francois Moine authored
Let 0c45:60fc in sn9c102 and 0c45:613e in gspca-sonixj (sensor not supported). Signed-off-by:
Jean-Francois Moine <moinejf@free.fr> Signed-off-by:
-
Jean-Francois Moine authored
Signed-off-by:
-
Jean-Francois Moine authored
The new exchanges are taken from the information file of the ms-win driver (usbvm326.inf - webcam 15b8:6002). Signed-off-by:
-
Jean-Francois Moine authored
Signed-off-by:
-
Jean-Francois Moine authored
Signed-off-by:
-
Jean-Francois Moine authored
Signed-off-by:
-
Stephane Marguet (Stemp) authored
Signed-off-by:
Stephane Marguet (Stemp) <smarguet@gmail.com> Signed-off-by:
-
Janne Grunau authored
Check the modulation in dvb_frontend_check_parameters against frontend's capabilties for FE_QAM devices. Signed-off-by:
Janne Grunau <j@jannau.net> Signed-off-by:
-
Janne Grunau authored
Various frontend driver have parameter checks in their set_frontend functions and return an error if the parameters are not supported, tda10021 and cx24116 to name two. The tuning ioctls FE_SET_FRONTEND/FE_SET_PROPERTY only change values in the property cache and return before set_frontend is called. If a set_frontend call in software zigzag algorithm fails and the card was previously locked it will report a lock and the new parameters but is still tuned to the old transport. This is not detectable from userspace. This change checks the return values of fe->ops.set_frontend and changes the state to the added FESTATE_ERROR for software zigzag. No lock will be reported to userspace if the State is FESTATE_ERROR. Signed-off-by:
-
Janne Grunau authored
Support for more than 8 DVB devices is requested regularly so make it a kconfig variable instead of a header define. Values in the range 4-32 are tested. Signed-off-by:
Michael Krufky <mkrufky@kernellabs.com> Signed-off-by:
-
Hans de Goede authored
gspca_mr97310a: Add one more vivitar mini cam to the list of CIF cams Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
gspca_mr97310a: Allow overriding of detected sensor type Signed-off-by:
-
Hans de Goede authored
V4L2_FMT_FLAG_EMULATED 0x0002 This format is not native to the device but emulated through software (usually libv4l2), where possible try to use a native format instead for better performance. Signed-off-by:
-
Hans de Goede authored
gspca_mr97310a: Use correct register for CIF type 1 sensor gain settings Signed-off-by:
-
Hans de Goede authored
gspca_mr97310a: Add controls for CIF type 0 sensor cams Signed-off-by:
-
Hans de Goede authored
gspca_mr97310a: make the probing a bit less chatty Signed-off-by:
-
Hans de Goede authored
gspca_mr97310a: Move detection of CIF sensor type to probe() function, so that the right controls are set to disabled from the start, rather then having them disappear all of a sudden when the stream is started. Signed-off-by:
-
Hans de Goede authored
gspca_mr97310a: cleanup/fixup control handling Signed-off-by:
-
Hans de Goede authored
gspca: mr97310a fix detection of sensortype for vivicam with id byte of 0x53 Signed-off-by:
-
Theodore Kilgore authored
This patch adds supports for mr97310a camera's with CIF sensors (2 different types) and for VGA mr97310a camera with a different sensor then supported until now. This patch also add support for controls for one of the 2 CIF sensors, this was written by Thomas Kaiser <thomas@kaiser-linux.li> Signed-off-by:
Theodore Kilgore <kilgota@auburn.edu> Signed-off-by:
Thomas Kaiser <thomas@kaiser-linux.li> Signed-off-by:
Hans de Goede <hdgoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
Now that we've figured out the higher compression settings (supported in libv4l-0.6.0 and later, so after this patch the driver should be used with libv4l-0.6.0 or higher only!), we can enable higher framerates. Which means lower exposure times, which is important for the use of the pac207 in full daylight. This patch also tweakes the brightness default and the per color gain balances to use the values which are adviced by Pixart in the pac207 application note. Signed-off-by:
-
Hans de Goede authored
gspca_pac207: remove a number of unneeded (repeated) register writes Signed-off-by:
-
Hans Verkuil authored
Depending on the model there are three different firmwares to choose from. Unfortunately if a cx23885 is loaded first, then the global firmware name is overwritten with that firmware and if ivtv is loaded next, then it tries to load the wrong firmware. In addition, the original approach would also overwrite any firmware that the user specified explicitly. Cc: Jarod Wilson <jarod@wilsonet.com> Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Hans Verkuil authored
The compiler warned about an uninitialized stereo variable. By simplifying the code it 1) improved readability and 2) fixed the compiler warning. Acked-by:
Eduardo Valentin <eduardo.valentin@nokia.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
The input subsystem checks if get_keycode works for a scan code. Due to that, we need to return a valid value when there's some space at the table that can be used by a scancode. Signed-off-by: -
Mauro Carvalho Chehab authored
Implements handler for EVIOCGKEYCODE/EVIOCSKEYCODE via adding two new callbacks to the input device. Since on dvb-usb a scan code has 16 bits, to fulfill rc5 standard codes, the default getkeycode/setkeycode input methods would require the driver to spend up to 64 Kb of a sparse table. Instead, add two new callbacks to the event device. With this, it is now possible to replace the keycode tables. There are, however, a few implementation details at the current patch: 1) It will replace the existing device keytable, instead of creating an instance of the data. This works. However, if two devices pointing to the same table were connected, changing the IR table of one will also change the IR table for the other (the solution for this one is simple: just kmalloc some memory); 2) In order to change the scan code, you need first to change the key to KEY_RESERVED or KEY_UNKNOWN to free some space at the table (solution: allocate some additional space for newer scan codes or allow dynamic table grow); 3) The table size cannot be extended. It would be easy to allow the table to grow dynamically: just calling kmalloc(size+1); kfree(old). Yet, maybe we can just create a bigger table with a fixed size, like for example a table with 128 entries. This should be enough even for a very big IR. The current issues should be addressed on a later patch. Signed-off-by: -
Mauro Carvalho Chehab authored
In order to be closer to V4L IR implementation, it is needed to replace u8 custom, data to: u16 scan This allows using non-rc5 mappings, like the 8 bit keycodes used on older protocols. It will also allow future implementations of rc6 keystrokes when needed. Signed-off-by: -
Mauro Carvalho Chehab authored
Currently, V4L uses a scancode table whose index is the scancode and the value is the keycode. While this works, it has some drawbacks: 1) It requires that the scancode to be at the range 00-7f; 2) keycodes should be masked on 7 bits in order for it to work; 3) due to the 7 bits approach, sometimes it is not possible to replace the default keyboard to another one with a different encoding rule; 4) it is different than what is done with dvb-usb approach; 5) it requires a typedef for it to work. This is not a recommended Linux CodingStyle. This patch is part of a larger series of IR changes. It basically replaces the IR_KEYTAB_TYPE tables by a structured table: struct ir_scancode { u16 scancode; u32 keycode; }; This is very close to what dvb does. So, a further integration with DVB code will be easy. While we've changed the tables, for now, the IR keycode handling is still based on the old approach. The only notable effect is the redution of about 35% of the ir-common module size: text data bss dec hex filename 6721 29208 4 35933 8c5d old/ir-common.ko 5756 18040 4 23800 5cf8 new/ir-common.ko In thesis, we could be using above u8 for scancode, reducing even more the size of the module, but defining it as u16 is more convenient, since, on dvb, each scancode has up to 16 bits, and we currently have a few troubles with rc5, as their scancodes are defined with more than 8 bits. This patch itself shouldn't be doing any functional changes. Signed-off-by: -
Jean-Francois Moine authored
- bad sensor power - bad edge gain/threshold - set back the auto gain - light frequency filter inverted Signed-off-by:
-
Mauro Carvalho Chehab authored
It were using 7 spaces instead of tab for indent. Signed-off-by: -
Mauro Carvalho Chehab authored
[mchehab@redhat.com: Fix a few wrong IR keymaps] Signed-off-by:
Shine Liu <shinel@foxmail.com> Signed-off-by:
-
Eugene Yudin authored
This patch add support for RoverMedia TV Link Pro FM (LR138 REV:I) card based on saa7134. Signed-off-by:
Eugene Yudin <Eugene.Yudin@gmail.com> Signed-off-by:
-
Dmitri Belimov authored
Add support our new TV card based on xc5000 and saa7134. Analog TV works well. Signed-off-by:
Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com> Signed-off-by:
-
Oldřich Jedlička authored
The patch introduces new snd_saa7134_capsrc_set (code taken from snd_saa7134_capsrc_put) that updates also the ALSA capture controls during snd_card_saa7134_capture_prepare and snd_saa7134_capsrc_put. There can be much more work done in order to unify the control of the card (now the card's capture source is tuned/switched in saa7134-video.c too), but I don't have enough time. This work could be a starting point, but it can be applied as-is too (it doesn't need any further work to make it working). Signed-off-by:
Oldřich Jedlička <oldium.pro@seznam.cz> Signed-off-by:
-
Mauro Carvalho Chehab authored
Hello kernel developers. I found a bug report from an user in launchpad. I just copy it here. It includes patch. I don't own the necessary hardware to test it but the patch looks trivial. I'm not subscribed to this list, so please CC me. Thanks! Here is the text: """ remote control for my tv card doesnt work I have Askey CPH03x TV Capturer. When I load bttv module with "card=59" option which is proper for this tv card, I can watch tv with sound but my remote control doesnt work. There is no ir event in /proc/bus/input/device . When bttv module is loaded with "card=137" option remote control works very well. $ cat /proc/bus/input/devices ....... ........ : Bus=0001 Vendor=109e Product=0350 Version=0001 N: Name="bttv IR (card=137)" P: Phys=pci-0000:00:0d.0/ir0 S: Sysfs=/devices/pci0000:00/0000:00:0d.0/input/input144 U: Uniq= H: Handlers=kbd event6 B: EV=100003 B: KEY=2c0814 100004 0 0 0 4 2008000 2090 2001 1e0000 4400 0 ffc Unfortunately there is no sound. """ https://bugs.launchpad.net/ubuntu/+bug/239733 http://bugzilla.kernel.org/show_bug.cgi?id=11995 -- Signed-off-by:
-
