All PAC7311 specific functions remain in pac7311.c. All PAC7302 specific
functions are moved to pac7302.c. The USB device table is also divided into
two parts. This makes it possible to remove the sensor specific decisions
from different functions and also remove sensor infromation from the USB
device table.
The common functions are just copied to both subdrivers. These common
functions can be separated later to a common file or helper module.
Signed-off-by: Marton Nemeth <nm127@freemail.hu>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Creating the start of the frame is done in the same way for pac7302
and for pac7311. Extract this common part to the pac_start_frame()
function.
Signed-off-by: Marton Nemeth <nm127@freemail.hu>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove struct sd dependency from pac_find_sof() function implementation.
This step prepares separation of pac7302 and pac7311 specific parts of
struct sd.
Signed-off-by: Marton Nemeth <nm127@freemail.hu>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
i2c_smbus_read_byte_data() returns a negative value on error. It is very
likely to be != -1 (-EPERM).
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert printks to em28xx_err and em28xx_info
Signed-off-by: Filipe Rosset <rosset.filipe@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Trivial patch which adds the __init/__exit macros to the module_init/
module_exit functions of the following drivers in media video:
drivers/media/video/ivtv/ivtv-driver.c
drivers/media/video/cx18/cx18-driver.c
drivers/media/video/davinci/dm355_ccdc.c
drivers/media/video/davinci/dm644x_ccdc.c
drivers/media/video/saa7164/saa7164-core.c
drivers/media/video/saa7134/saa7134-core.c
drivers/media/video/cx23885/cx23885-core.c
Cc: Hermann Pitton <hermann-pitton@arcor.de>
Acked-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Acked-by: Andy Walls <awalls@radix.net>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If vpfe_dev->std_index equals ARRAY_SIZE(vpfe_standards), that is
one too large.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_mr97310a: Partly back off red gain change for Sakar Digital VGA camera
Signed-off-by: Theodore Kilgore <kilgota@banach.math.auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As pointed out by Hermann Pitton, it turns out that the DTV1000S card's
analog entry made it into the #if 0 flyvideo tweaks in saa7134-cards.c
and is not valid there.
This patch fixes the problem.
Cc: hermann pitton <hermann-pitton@arcor.de>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Setting the tuner frequency at the same time as initializing the other devices
on the i2c bus can cause problems on devices that require firmware download or
extensive calibration proceduces during initialization.
This change allows us to prevent the tune at startup for devices that perform
better without it.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_mr97310a: Change blue gain setting for Sakar Digital VGA camera
Signed-off-by: Theodore Kilgore <kilgota@banach.math.auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When "shooting" certain (quite rare) scenes, the mr97310's compression is not
effective and it cannot keep up with the data stream. This patch adds a
minimum clock divider control, which influences the maximum framerate,
libv4l will automatically increase this minimum clockdiv control when it
detect the cam cannot keep up.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The variables are unsigned so the test `>= 0' is always true,
the `< 0' test always fails. In these cases the other part of
the test catches wrapped values.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Upcoming I2C v4l2_subdev drivers need a way to control the subdevice
power state from the core. This use case is already partially covered by
the tuner s_standby operation, but no way to explicitly come back from
the standby state is available.
Rename the tuner s_standby operation to core s_power, and fix tuner
drivers accordingly. The tuner core will call s_power(0) instead of
s_standby(). No explicit call to s_power(1) is required for tuners as
they are supposed to wake up from standby automatically.
[mchehab@redhat.com: CodingStyle fix]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I do not think it makes sense any longer for ir-kbd-i2c to reject
devices at unknown I2C addresses. The caller can provide all the
details about how the device should be handled. Having to add new
addresses to ir-kbd-i2c so that they aren't rejected is a pain we
don't need. Unsupported devices will be spotted a few lines later
anyway.
This already lets us unlist 2 addresses (0x7a and 0x2d) for which
handling details are always provided by the caller (saa7134-input).
Hopefully we can remove more in the future.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Google is pretty clear that the HVR 1110 IR chip is always at address
0x71 and the BeholdTV IR chip is always at address 0x2d. This
completes the list of IR device addresses for the SAA7134-based
adapters, and we no longer need to probe any of them.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The i2c core prevents us from probing I2C address 0x7a because it's
not a valid 7-bit address (reserved for 10-bit addressing.) So we must
stop probing this address, and explicitly list all adapters which use
it. Under the assumption that only the Upmost Purple TV adapter uses
this invalid address, this fix should do the trick.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: hermann pitton <hermann-pitton@arcor.de>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Recent fixes to the em28xx and saa7134 drivers have been overzealous.
While the ir-kbd-i2c platform data indeed needs to be persistent, the
struct i2c_board_info doesn't, as it is only used by i2c_new_device().
So revert a part of the original fixes, to save some memory.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
cx25840:
Disable 6.5MHz carrier autodetection for PAL, always assume its DK.
Only try to autodetect 6.5MHz carrier for SECAM if user accepts both
system DK and L.
Signed-off-by: Aleksandr V. Piskunov <alexandr.v.piskunov@gmail.com>
Reviewed-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change own implementation of pwc_atoi() by simple_strtol(x, NULL, 10).
Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After detecting failure due to module initialization error, get out.
Don't report jammed hardware. Problem due to a missing break statement.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver also contains a piece of configuration data that produces a
one line description of the specific hardware being driver
(e.g. "Hauppauge 24xxx", "OnAir", etc). This change generates an
informational message to the kernel log reporting the hardware type
being driven. This is a very useful thing to know when diagnosing
problems.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It used to be that the only real detectable reason for the driver to
fail during initialization would be that if the hardware is simply
jammed. However with the advent of the sub-device mechanism in V4L it
is possible now to detect if a sub-device module fails to load
successfully. The pvrusb2 driver does in fact react to this by also
(correctly) failing, however the original diagnostic message "hardware
is jammed" was still being reported. This misleads the user because
in fact it might not actually be a hardware failure. This change adds
logic to tell the difference and then report a more appropriate
message to the kernel log.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
pvrusb2: Encoder failures are mostly recoverable by the driver. While
it would sure be nice not to have the failure happen in the first
place, this has been going on for years and I doubt that a real
solution will ever present itself. I think that part's firmware is
just slightly flakey and we have to deal with it. The driver does
deal with it just fine, but the warning message going into the kernel
log is probably a little more alarming than it should be. So try to
soften up the warning somewhat.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
pvrusb2: Associate V4L device node in sysfs with the underlying USB
device. This opens the door to device information tracking in udev
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to Terry Wu for finding the GPIOs required for svideo / composite input
Cc: Terry Wu <terrywu2009@gmail.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Enable the standby mode optimization to disable the tda18271
slave tuner output / loop thru options when in low power mode
on the slave tuner, only. The master tuner must always leave
slave tuner output / loop thru enabled.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- add flip/mirror support for OV2640
- fix for backlight value range
- fix for red-blue inversion hue mode with V4L1 applications
Signed-off-by: Olivier Lorin <o.lorin@laposte.net>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The original implementation of pac_find_sof() does not always find
the Start Of Frame (SOF) marker. Replace it with a state machine
based design.
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marton Nemeth <nm127@freemail.hu>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca: Don't resubmit error status URB's when suspending
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The gscpa core was not resubmitting URB's when the URB status was an error,
this means we will loose URB's (potentially all stopping the stream) in
case of sporadic USB issues. I've seen this with an Aiptek stv0680 based
PenCam connected through an USB 2.0 hub.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds a new subdriver to gspca supporting cams with the stv0680
bridge (replacing the old in kernel v4l1 driver).
Many thanks to Hans Verkuil for providing me with one of the 2 cams used in
testing this new sub driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca w9968cf: slight tweak to vstart and hstart to get rid of black borders
in 640x480 mode.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca w9968cf: Add support for JPEG compression, this enables much higher
framerates at 320x240 / 352x288 and also allows for 640x480 mode for
cams which can do this. The w9968cf uses planar JPEG, which libv4l until
now did not support, so this requires atleast version 0.6.3 of libv4l.
And something important I forgot to mention in my earlier w9968cf commits:
Many thanks to Hans Verkuil for giving me a w9968cf based cam, which has
allowed me to develop the gspca w9968cf support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca-w9968cf: Don't add an extra packet to the buffer after the EOF,
this makes the frame data size bigger then it should be which makes
gstreamer discard it.
This patch also fixes an unrelated compiler warning.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cache sensor regs to avoid unnecessary slow i2c reads / writes, this speeds
up sd_start a bit with most bridges and a lot (from 5 seconds down to 0.3
seconds) with W996xCF cams, as this avoids very slow bit bang IO over
USB i2c reads.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support to gspca for the Winbond W9967CF and W9968CF
camera's. This is mostly a port of the existing v4l1 driver to gspca
(making it v4l2). But this also features fixes to the bitbanging i2c code
(send a nack not an ack after reading the last byte of a transfer), which
gets rid of the weird errors which were being seen there, and of
the smbus_refresh() hack to get around these errors.
Also the vstart settings have been tweaked to work with different
frequency filter settings.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If the I2C device provides an interrupt it is registered and the
standard
is updated via interrupts rather than polling.
Since I2C communication is needed, the interrupt handler fires off a
work which will check the new standard, and store it in the internal
structure.
To handle mutual exclusion a mutex is introduced.
Signed-off-by: Richard Röjfors <richard.rojfors@mocean-labs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch defines the probe and remove function as __devinit and __devexit.
Signed-off-by: Richard Röjfors <richard.rojfors@mocean-labs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Support for settings the input standard of the ADV7180.
When the input standard is set there is no use to ask the
chip for standard, therefore it is cached in the driver.
Signed-off-by: Richard Röjfors <richard.rojfors@mocean-labs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support to the ADV7180 driver to check the input
status.
Since the status is held in the same register as the input standard
a small restructuring of the code is done to reuse the code for
reading the register
Signed-off-by: Richard Röjfors <richard.rojfors@mocean-labs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds the device IDs and driver linking to allow the Asus Europa DVB-T
card to operate with these drivers.
The device has a SAA7134 chipset with a TD1316 Hybrid Tuner.
All inputs work on the card including switching between DVB-T and
Analogue TV, there is also no IR with this card.
[mchehab@redhat.com: CodingStyle fixes]
Signed-off-by: Danny Wood <danwood76@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The definition of tvaudio_tuner_ops initializes the s_tuner field twice.
It appears that the second case should initialize the g_tuner field.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r@
identifier I, s, fld;
position p0,p;
expression E;
@@
struct I s =@p0 { ... .fld@p = E, ...};
@s@
identifier I, s, r.fld;
position r.p0,p;
expression E;
@@
struct I s =@p0 { ... .fld@p = E, ...};
@script:python@
p0 << r.p0;
fld << r.fld;
ps << s.p;
pr << r.p;
@@
if int(ps[0].line)!=int(pr[0].line) or int(ps[0].column)!=int(pr[0].column):
cocci.print_main(fld,p0)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When the image size (bytesperline*height) is not multiple
of PAGE_SIZE, v4l2 rounded the required buffer size to
be multiple of PAGE_SIZE. This prevented user space
to store images directly into userptr buffers which were
not multiple of PAGE_SIZE. This constraint is removed.
The start address is still assumed to be required
page-aligned, ie., when v4l2 allocates mmap buffers,
the offset between different buffers is page-aligned.
Signed-off-by: Tuukka Toivonen <tuukka.o.toivonen@nokia.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The default streaming control timeout was found by Ondrej Zary to be too low
for some Logitech webcams. With kernel 2.6.22 and newer they would timeout
during initialization unles the audio function was initialized before the
video function.
Add a module parameter to set the streaming control timeout and increase the
default value from 1000ms to 3000ms to fix the above problem.
Thanks to Ondrej Zary for investigating the issue and providing an initial
patch.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
At least one 5986:0241 webcam model includes vendor-specific descriptors
at the end of its streaming interface descriptors. Print an information
UVC_TRACE_DESCR message and try to continue parsing the descriptors
rather than bailing out with an error.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch sets stream->urb_size as psize*npackets
before calling uvc_alloc_urb_buffers, which may fix
a possible failure of usb_buffer_free in case usb_buffer_alloc
returns NULL. The patch is based on the ideas below:
1,If usb_buffer_alloc can't allocate a buffer sucessfully,
uvc_free_urb_buffers will be called to free the allocated
buffers, and stream->urb_size is required to be passed to
usb_buffer_free;
2,uvc_free_urb_buffers can reset stream->urb_size.
This patch is against linux-v2.6.31-next-20090926.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The uvcvideo driver has a driver-wide lock and a reference count to protect
against a disconnect/open race. Now that videodev handles the race itself,
reference-counting in the driver can be removed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Dismiss privileges on the file handle when calling VIDIOC_REQBUFS with a
buffer count of 0. This allows applications to release the streaming
permissions on the file handle without closing it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The VIDIOC_TRY_FMT ioctl doesn't interfere with video streaming and thus
should succeed on an unprivileged file handle.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use the trace level for messages related to video URB buffers allocation and
alternate setting selection.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Return minimum, maximum and step set to 0 without querying the hardware.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There were various "if (sensor == foo)" pieces of code inside ov519.c,
move these bits to the sensor specific init functions, where they
belong.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gscpa_ov519: add support for the ovfx2 bridge
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support for the OV2610 and OV3610 sensors to the gspca
ov519 subdriver. This is a preparation patch for adding ovfx2 bridge
support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The CIF sensor type 1 exposure setting got clamped at 300, as settings below
300 do not work well (and do work for the other sensors). This patch
scales the 0-4095 range to 300-4095 instead of ignoring changes between
300, avoiding have a part of the control range where nothing happens.
This is esp. important for software autogain as done by libv4l.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While checking all gspca sub drivers pkt_scan functions for a bug I found in
1 of them (and after checking also in another), I noticed a bug in the
gspca_sq905c work queue function, once it has decided to start discarding a
frame because the application is not reading fast enough (and thus returning
buffers to fill fast enough), it never stops discarding.
This patch fixes this by simply completely removing the "discarding"
variable, if we need to discard the current frame because there is no buffer
to store it, the "frame" pointer will be NULL, so that is all we need to
check.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While checking all gspca sub drivers pkt_scan functions for a bug I found in
1 of them (and after checking also in another), I noticed a bug in the
gspca_jeilinj work queue function, once it has decided to start discard a
frame because the application is not reading fast enough (and thus returning
buffers to fill fast enough), it never stops discarding.
This patch fixes this by simply completely removing the "discarding"
variable, if we need to discard the current frame because there is no buffer
to store it, the "frame" pointer will be NULL, so that is all we need to
check.
I've also moved the gspca_get_i_frame() call and the writing of the jpg
header to the buffer to after the first usb_bulk_msg() call, as we don't
need it before that, and that will give the app slightly more time to
queue a buffer for us to fill.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Improve (and also simplify :) gspca_mr97310a: VGA sensor type detection.
As it was still failing on some machines (not with some cams, but on
some machines interesting enough).
Signed-off-by: Theodore Kilgore <kilgota@banach.math.auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-Remove use of unneeded discarding variable
-Cleanup locking to only take usb_lock around access to the control
endpoint, by no longer taking the lock around the bulk transfer
(which takes most of the time) we can remove the msleep(1) which was
needed to give the gspca core a chance to grab the usb_lock to signal
us to stop.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds controls for vga cams with sensor type 0, in order to
correctly report the present controls, the probing of the sensor type
has been moved from sd_start to sd_config, since this made the sensor
type probing unreliable the detection method was changed.
Note this requires the camera to enter streaming mode, so sd_config now
briefly makes the camera stream.
Signed-off-by: Theodore Kilgore <kilgota@banach.math.auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patch brings infrared remote support for some cx88 based cards.
Such as TeVii S460,S420.
Signed-off-by: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patch brings infrared remote support for some cx88 based cards.
Such as:
TeVii S460,S420; Omicom SS4; SatTrade ST4200;
TBS 8920,8910; Prof 7300,6200.
Signed-off-by: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds an soc-camera / v4l2-subdev driver for the RJ54N1CB0C CMOS camera
sensor from Sharp. The sensor is very picky about initialisation and
configuration sequences. The driver limits artificially maximum window size by
800x600, although the sensor supports 1600x1200. Sizes above 800x600 don't seem
to work correctly, besides, examples from the system integrator use sizes above
640x480 only for still photography. Unfortunately, I had to use "magic"
register-value pairs for undocumented and "reserved" registers. This version of
the driver also omits some functionality, like cropping, which hasn't been
sufficiently tested yet and will be added later.
create mode 100644 drivers/media/video/rj54n1cb0c.c
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If CEU driver can not receive data from camera,
CETCR has VBP error state.
Then, CEU is stopped and cure operation is needed.
This patch add VBP error cure operation.
Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add comment about the meaning of the fixed JPEG header bytes used to
create each image.
Signed-off-by: Marton Nemeth <nm127@freemail.hu>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The length check in reg_w_var() function is because the buffer contents
is copied to gspca_dev->usb_buf which has the size of USB_BUF_SZ bytes as
defined in drivers/media/video/gspca/gspca.h. Replace the number with
symbol for better readability and maintainability.
Signed-off-by: Marton Nemeth <nm127@freemail.hu>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
override set_frontend to allow rf input path switching on the HVR1275
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This changes adds IR Rx keypress input event handling to the CX23885 module.
This change specifically only adds input handling for IR devices implemented as
v4l2_subdevices, using only the pulse width mode (for now), and only with
RC-5 remotes. The V4L-DVB infrastructure is missing too much to support RC-6
mode 6A as used in many media center remotes. The grey Hauppauge RC-5 remote
and HVR-1850 IR receiver work now.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add integrated IR subdevice interrupt and notification handling. This is in
preparation of input keypress handling changes for the cx23885 module.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change completes the v4l2_subdev implementation for IR receive for the
IR controller built into the CX23888.
This changes almost completes the IR transmit side also, but doesn't. Instead
notes in the comments describe what needs to be done for IR Tx to work in the
subdevice implementation.
The current Tx behavior is skeletal and benign. If left alone, it does nothing.
It will only ever generate a Tx interrupt on Tx init by a caller or when the
tx_write() method is called. The ISR, when called, will then disable the Tx
FIFO service interrupt.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The prior mechanism wasn't reliable with the cx23887. This new mechanism
tests correctly against cx23885, 7 and 8 based products.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
For the IR controller on the CX23888 to work for the HVR-1850 and in
general, the A/V core must be initialized to get the VID_CLK going.
The VID_CLK is the timing reference for the CX23888's integrated
IR controller.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The SYS and AUX PLLs need to be initialized to different values based on
the chip: CX23885, CX23887, CX23888, as each uses a different crystal
frequency: 28.6363 MHz, 25.0 MHz, 50.0 MHz.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Separate out the set_audclk_freq() function into separate functions for the
four families of cores. These cores all use slightly different sample clock
schemes and may be assuming slightly (+/- 3 Hz) different reference frequencies.
The code resuse was not worth the maintenance and testing headache of have all
chips use the same function peppered with conditional logic.
Added comments on how PLL and SRC parameters values are computed. Fixed a few
bugs related to the shared code having a large number of conditional statements.
Noted inconsistencies with FIXME in the comments.
This is done in preparation for getting the CX2388[578] PLL/clock setting logic
cleaned up for CX23888 analog video and IR (which need the VID PLL set right).
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change logic to check for various chip or core families to inline functions.
Checks for specific chips should be made against the state->id field now. This
is in preparation for chip/core specific code for setting up PLLs for the
CX2388[578] family of cores, that all run with different crystal frequencies.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add improved logic to detect the exact CX2388[578] A/V core that is being
probed. Also cleaned up detection and logging for CX2310[12], CX2583[67],
and CX2584[0123] cores and chips.
Also added code to identify a CX2388[578] A/V decoder core that is not
responding properly. Typical symptoms include registers 0x00-0xff
responding properly but all other registers returning the same value
(0x13 and 0x5 have been observed). This state will cause proper detection of
'885 vs. '887 vs. '888 to fail and the chip won't respond to get configured
properly anyway. I have no method of reseting the core to a working state at
this time; but I didn't try too hard to work one out either. The problem
likely only occurs in development. I suspect configuring the SYS PLL VCO to
oscillate too slowly (286.3 MHz?) before post divide may be the root cause,
when encountered.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change adds a skeletal implementation of a v4l2_subdevice to provide
encapsulation and abstraction of the CX23888's integrated consumer infrared
controller. This change also instantiates the cx23888_ir subdev for the
HVR-1850 which has IR hardware physically wired up to a CX23888.
The cx23888_ir subdev code is being written with long-term objectives to:
1. port it to the cx25840 module for the CX2584x, CX2583x, CX23885, & CX231xx
IR controllers
2. possibly port it to the cx18 module for the CX23418 IR controller
3. have the IR subdevice accessed abstractly in the cx23885 module, so the
driver can ignore the difference between the CX23885 and CX23888.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This changes corrects the ioctl() operations for both the CX2388[578] analog
video and MPEG video device nodes to properly and consistently support
VIDIOC_G_CHIP_IDENT, VIDIOC_DBG_G_REGISTER and VIDIOC_DBG_S_REGISTER ioctl()s.
This caused some ioctl() support routines to be broken out into a separate
source file.
Now v4l2-dbg can be used to manipulate CX2388[578] and CX23417 registers
including the CX2388[57] functions handled by the cx25840 module.
This was done in anticipation of developing a new v4l2_subdev for the
integrated IR controller of the CX23888.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The board support has been validated by the user, so get rid of the warning
that shows up on board load.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Dmitri's patch for the Behold X7 didn't use the #define I had setup for
XC5000_RADIO_FM1, so cut over to using that instead of "1".
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for the digital side of the Behold X7
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Make analog audio, dvb and the remote work on a Terratec Cinergy Hybrid
XS (em2882).
Note by djh: Thanks go out fo Andrej Suligoi for his contribution in providing
and testing pretty much the exact same patch as provided by Uros. Between
the two of them, they got all the core functionality working for the device.
Cc: Andrej Suligoi <suligoi@gmail.com>
Signed-off-by: Uroš Vampl <mobile.leecher@gmail.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Seems that the reference design used for the KWorld 2800d switched from the
em2860 to em2862, so we need to add the new USB id (and the i2c hash remains
so all we need is the default em2862 id.
Thanks to Ian Young for reporting the issue and testing the fix.
Cc: Ian Young <ian@duffrecords.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
"Definition" is misspelled "defintion" in several comments; this
patch fixes them. No code changes.
Signed-off-by: Adam Buchbinder <adam.buchbinder@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Trivial fix for this compile warning:
v4l/sh_mobile_ceu_camera.c:1789: warning: label 'exit_free_irq' defined but not used
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The vpif_config struct was renamed to vpif_display_config, but there
is still a stray vpif_config *config pointer in vpif_display.c, preventing
it from compiling.
Remove this old duplicate pointer.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Set device GPIOs only once. There is no need for .dvb_gpio to select
between analog and digital because device is digital only.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Commit ef373189f62413803b7b816c972fc154c488cdc0 "fix use-after-free Oops,
resulting from a driver-core API change" fixed the Oops, but didn't correct
missing device object initialisation. This patch makes unloading and reloading
of soc-camera host- and client-drivers possible again.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Trivial patch which adds the __init/__exit macros to the module_init/
module_exit functions of the following drivers in media video:
drivers/media/video/ivtv/ivtv-driver.c
drivers/media/video/cx18/cx18-driver.c
drivers/media/video/davinci/dm355_ccdc.c
drivers/media/video/davinci/dm644x_ccdc.c
drivers/media/video/saa7164/saa7164-core.c
drivers/media/video/saa7134/saa7134-core.c
drivers/media/video/cx23885/cx23885-core.c
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Acked-by: Andy Walls <awalls@radix.net>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Acked-By: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch was generated by
git grep -E -i -l 's(le|el)ct' | xargs -r perl -p -i -e 's/([Ss])(le|el)ct/$1elect/
with only skipping net/netfilter/xt_SECMARK.c and
include/linux/netfilter/xt_SECMARK.h which have a struct member called
selctx.
Signed-off-by: Uwe Kleine-Knig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Hauppauge WinTV HVR-1150 retail boards require the FORCE_TS_VALID bit
to be set in order to function properly. This change will work on the early
revisions on the board as well, but the final revision will not function
without this change.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When FORCE_TS_VALID mode is enabled, the saa713x will accept MPEG TS input
without requiring TS_VALID set high. This is required for some new boards
to function properly, due to the hardware design implementation.
The configuration is toggled within the board setup configuration. Boards
that do not have this bit set will function as before with no change.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The abs() macro has changed in 2.6.32 and returns a long instead of an
int. Fix the driver to avoid compilation warnings.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The FIX_BANDWIDTH quirk tries to work around cameras requesting the
maximum bandwidth regardless of the image size by computing a bandwidth
estimate. This works only for uncompressed frames.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Which is why I have always preferred sizeof(struct foo) over
sizeof(var).
Cc: Antti Palosaari <crope@iki.fi>
Acked-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_mr97310a: Change vstart for CIF sensor type 1 cams
This fixes the distortion at the end of the frame, and avoids the bad frame
dropping done because of this distortion, trippling the framerate!
Signed-off-by: Theodore Kilgore <kilgota@banach.math.auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds a vflip quirk for the Fujitsu Amilo Xi 2528. Thanks to Evgeny for the report.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds another vflip quirk for the MSI GX700.
Thanks to John Katzmaier for reporting.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds a vflip quirk for the Bruneinit laptop. Thanks to Jörg for the report
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The s2255 driver had logic which aborted processing of a video frame
if there was no process waiting on the video buffer in question. That
simply doesn't work when the application is doing things in an
asynchronous manner. If the application went to the trouble to queue
the buffer in the first place, then the driver should always attempt
to complete it - even if the application at that moment has its
attention turned elsewhere. Applications which always blocked waiting
for I/O on the capture device would not have been affected by this.
Applications which *mostly* blocked waiting for I/O on the capture
device probably only would have been somewhat affected (frame lossage,
at a rate which goes up as the application blocks less). Applications
which never blocked on the capture device (e.g. polling only) however
would never have been able to receive any video frames, since in that
case this "is anyone waiting on this?" check on the buffer never would
have evalutated true. This patch just deletes that harmful check
against the buffer's wait queue.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
CC: stable@kernel.org
Because the counters were not reset when starting up streaming, they would
be reused from the previous run. This can result in cases such that when the
second instance of streaming starts up, the "cnt" variable in
em28xx_audio_isocirq() can end up being negative, resulting in attempting to
write to memory before the start of runtime->dma_area (as well as having a
negative number of bytes to copy).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bttv driver function which handles switching of the video standard
(set_tvnorm() in bttv-driver.c) includes a check which can optionally
also reset the cropping configuration to a default value. It is
"optional" based on a comparison of the cropcap parameters of the
previous vs the newly requested video standard. The comparison is
being done with a memcmp(), a function which only returns a true value
if the comparison actually fails.
This if-statement appears to have been written to assume wrong
memcmp() semantics. That is, it was re-initializing the cropping
configuration only if the new video standard did NOT have different
cropcap values. That doesn't make any sense. One definitely should
reset things if the cropcap parameters are different - if there's any
comparison to made at all.
The effect of this problem was that a transition from, say, PAL to
NTSC would leave in place old cropping setup that made sense for the
PAL geometry but not for NTSC. If the application doesn't care about
cropping it also won't try to reset the cropping configuration,
resulting in an improperly cropped video frame. In the case I was
testing this actually caused black video frames to be displayed.
Another interesting effect of this bug is that if one does something
which does NOT change the video standard and this function is run,
then the cropping setup gets reset anyway - again because of the
backwards comparison. It turns out that just running anything which
merely opens and closes the video device node (e.g. v4l-info) will
cause this to happen. One can argue that simply opening the device
node and not doing anything to it should not mess with any of its
state - but because of this behavior, any TV app which does such
things (e.g. xawtv) probably therefore doesn't see the problem.
The solution is to fix the sense of the if-statement. It's easy to
see how this mistake could have been made given how memcmp() works.
The patch is therefore removal of a single "!" character from the
if-statement in set_tvnorm in bttv-driver.c.
Signed-off-by: Mike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is a subtle interaction in the bttv driver which can result in
fields being repeatedly processed out of order. This is a problem
specifically when running in V4L2_FIELD_ALTERNATE mode (probably the
most common case).
1. The determination of which fields are associated with which buffers
happens in videobuf, before the bttv driver gets a chance to queue the
corresponding DMA. Thus by the point when the DMA is queued for a
given buffer, the algorithm has to do the queuing based on the
buffer's already assigned field type - not based on which field is
"next" in the video stream.
2. The driver normally tries to queue both the top and bottom fields
at the same time (see bttv_irq_next_video()). It tries to sort out
top vs bottom by looking at the field type for the next 2 available
buffers and assigning them appropriately.
3. However the bttv driver *always* actually processes the top field
first. There's even an interrupt set aside for specifically
recognizing when the top field has been processed so that it can be
marked done even while the bottom field is still being DMAed.
Given all of the above, if one gets into a situation where
bttv_irq_next_video() gets entered when the first available buffer has
been pre-associated as a bottom field, then the function is going to
process the buffers out of order. That first available buffer will be
put into the bottom field slot and the buffer after that will be put
into the top field slot. Problem is, since the top field is always
processed first by the driver, then that second buffer (the one after
the first available buffer) will be the first one to be finished.
Because of the strict fifo handling of all video buffers, then that
top field won't be seen by the app until after the bottom field is
also processed. Worse still, the app will get back the
chronologically later bottom field first, *before* the top field is
received. The buffer's timestamps will even be backwards.
While not fatal to most TV apps, this behavior can subtlely degrade
userspace deinterlacing (probably will cause jitter). That's probably
why it has gone unnoticed. But it will also cause serious problems if
the app in question discards all but the latest received buffer (a
latency minimizing tactic) - causing one field to only ever be
displayed since the other is now always late. Unfortunately once you
get into this state, you're stuck this way - because having consumed
two buffers, now the next time around the "first" available buffer
will again be a bottom field and the same thing happens.
How can we get into this state? In a perfect world, where there's
always a few free buffers queued to the driver, it should be
impossible. However if something disrupts streaming, e.g. if the
userspace app can't queue free buffers fast enough for a moment due
perhaps to a CPU scheduling glitch, then the driver can get
momentarily starved and some number of fields will be dropped. That's
OK. But if an odd number of fields get dropped, then that "first"
available buffer might be the bottom field and now we're stuck...
This patch fixes that problem by deliberately only setting up a single
field for one frame if we don't get a top field as the first available
buffer. By purposely skipping the other field, then we only handle a
single buffer thus bringing things back into proper sync (i.e. top
field first) for the next frame. To do this we just drop the few
lines in bttv_irq_next_video() that attempt to set up the second
buffer when that second buffer isn't for the bottom field.
This is definitely a problem in when in V4L2_FIELD_ALTERNATE mode. In
the other modes this change either has no effect or doesn't harm
things any further anyway.
Signed-off-by: Mike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Commit b402843787 has broken again re-use of
device objects across device_register() / device_unregister() cycles. Fix
soc-camera by nullifying the struct after device_unregister().
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix a bug in cropping calculation, when the client is also scaling the image.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When we call gspca_frame_add, it returns a pointer to the frame passed in,
unless we call it with LAST_PACKET, when it will return a pointer to a
new frame in which to store the frame data for the next frame.
The frame pointer was not updated in stv06xx and ov518.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After m68k's task_thread_info() doesn't refer to current,
it's possible to remove sched.h from interrupt.h and not break m68k!
Many thanks to Heiko Carstens for allowing this.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Jean-Francois Moine