When adding support for both video and VBI, I missed the mmap ioctl.  Add
the missing call.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add support for raw VBI capture for the em28xx bridge, currently only for
NTSC.  Support for PAL capture to follow shortly (including the removal of
numerous hard-coded NTSC-specific sizes for capture buffers, etc).

Note that the code currently changes the default current norm from PAL to
NTSC (so that zvbi-ntsc-cc works properly).  The default norm really should
be moved into a board-level parameter.

This work was sponsored by EyeMagnet Limited.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add code enabling the VBI registers for variants of the em28xx chip that
support VBI, and make sure the isoc streaming code continues to work for
the video component of the stream (note the video and vbi data arrive
intermixed on the same isoc pipe).

Note that this version just drops the actual VBI data onto the floor as
opposed to processing it.  The "#ifdef 0" tags are for the videobuf code that
appears in the next patch in this series.

We created a separate version of the isoc_copy version for parsing the version
of the stream that includes VBI data.  In theory, they might be able to be
merged at some point in the future, but the initial goal is to ensure that we
do not cause any regressions with devices that do not have VBI support.

This work was sponsored by EyeMagnet Limited.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Properly document the video input control register, in preparation for the
addition of VBI support.  Note this patch makes no functional changes.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Added Kworld DVD Maker 2
Thanks to C Western <l@c-m-w.me.uk> for reporting this board.
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are some extra parenthesis at the clauses, and some switch() tests
for boards that don't have i2c ir. Remove those extra code.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently, the logic to load ir i2c ancillary module is broken. It is
associated to Hauppauge devices with IR flag on their eeprom, no matter
if the device uses i2c or em28xx direct IR support. That's wrong.

Instead, add a flag to the boards that use i2c IR chips and load the
module only for those devices and if ir is not disabled.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ir-kbd-i2c's ir_probe() function can be called much later (i.e. at
ir-kbd-i2c module load), than the lifetime of a struct IR_i2c_init_data
allocated off of the stack in cx18_i2c_new_ir() at registration time.
Make sure we pass a pointer to a persistent IR_i2c_init_data object at
i2c registration time.

Thanks to Brian Rogers, Dustin Mitchell, Andy Walls and Jean Delvare to
rise this question.

Before this patch, if ir-kbd-i2c were probed after SAA7134, trash data
were used.

Compile tested only, but the patch is identical to em28xx one. So, it
should work properly.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ir-kbd-i2c's ir_probe() function can be called much later (i.e. at ir-kbd-i2c
module load), than the lifetime of a struct IR_i2c_init_data allocated off of
the stack in cx18_i2c_new_ir() at registration time.  Make sure we pass
a pointer to a persistent IR_i2c_init_data object at i2c registration time.

Thanks to Brian Rogers for pointing out a solution, and Dustin Mitchell for
testing against a 2.6.30 kernel.
Reported-by: NDustin Mitchell <soxslayer@gmail.com>
Reported-by: NBrian Rogers <brian@xyzw.org>
Tested-by: NDustin Mitchell <soxslayer@gmail.com>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ir-kbd-i2c's ir_probe() function can be called much later (i.e. at
ir-kbd-i2c module load), than the lifetime of a struct IR_i2c_init_data
allocated off of the stack in cx18_i2c_new_ir() at registration time.
Make sure we pass a pointer to a persistent IR_i2c_init_data object at
i2c registration time.

Thanks to Brian Rogers, Dustin Mitchell, Andy Walls and Jean Delvare to
rise this question.

Before this patch, if ir-kbd-i2c were probed after em28xx, trash data
were used. After the patch, no matter what order, it is properly
reported as tested by me:

input: i2c IR (i2c IR (EM2840 Hauppaug as /class/input/input10
ir-kbd-i2c: i2c IR (i2c IR (EM2840 Hauppaug detected at i2c-4/4-0030/ir0 [em28xx #0]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Using the MT9M111's IFP to handle exposure/gain gives better results.
Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Use s16 instead of int where possible.
Use struct instead of arrays
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixes broken exposure on SOI968 webcams that was causing
the camera to display a black screen
Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Let 0c45:60fc in sn9c102 and 0c45:613e in gspca-sonixj (sensor not supported).
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The new exchanges are taken from the information file of the ms-win driver
(usbvm326.inf - webcam 15b8:6002).
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NStephane Marguet (Stemp) <smarguet@gmail.com>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Check the modulation in dvb_frontend_check_parameters against
frontend's capabilties for FE_QAM devices.
Signed-off-by: NJanne Grunau <j@jannau.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NJanne Grunau <j@jannau.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NJanne Grunau <j@jannau.net>
Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_mr97310a: Add one more vivitar mini cam to the list of CIF cams
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_mr97310a: Allow overriding of detected sensor type
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_mr97310a: Use correct register for CIF type 1 sensor gain settings
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_mr97310a: Add controls for CIF type 0 sensor cams
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_mr97310a: make the probing a bit less chatty
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_mr97310a: cleanup/fixup control handling
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca: mr97310a fix detection of sensortype for vivicam with id byte of 0x53
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NTheodore Kilgore <kilgota@auburn.edu>
Signed-off-by: NThomas Kaiser <thomas@kaiser-linux.li>
Signed-off-by: NHans de Goede <hdgoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

gspca_pac207: remove a number of unneeded (repeated) register writes
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The compiler warned about an uninitialized stereo variable. By simplifying
the code it 1) improved readability and 2) fixed the compiler warning.
Acked-by: NEduardo Valentin <eduardo.valentin@nokia.com>
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>