Hi Guennadi, Mauro,
Looks like I have missed this patch, unfortunately, it hasn't been cc'ed
to me. It would have been better to merge it via my soc-camera tree, also
because with this merge window there are a couple more changes, that
affect the generic soc-camera API and the mx2-camera
Hi Andrzej!
Thanks for the patch, but I do have two questions:
On Tue 22 May 2012 17:33:53 Andrzej Hajda wrote:
Those patches add end of stream handling for s5p-mfc encoder.
The first patch was sent already to the list as RFC, but the discussion ended
without any decision.
This patch adds
On Wed, 23 May 2012, javier Martin wrote:
Hi Guennadi, Mauro,
Looks like I have missed this patch, unfortunately, it hasn't been cc'ed
to me. It would have been better to merge it via my soc-camera tree, also
because with this merge window there are a couple more changes, that
affect
Is this the way to proceed or should I send a fix on top of it? This
patch is merged in 'for_v3.5', if Mauro reverts it and I send a new
version, would it be also merged 'for_v3.5' or should it wait for
version 3.6?
I think, it would be better to revert and re-do it for the following
This fixes a regression introduced by commit f7059ea and should be
backported to all supported stable kernels which have this commit.
Signed-off-by: Hans de Goede hdego...@redhat.com
Tested-by: Antonio Ospite osp...@studenti.unina.it
CC: sta...@kernel.org
---
drivers/media/video/gspca/gspca.c |
Hi,
On 05/22/2012 11:02 PM, Antonio Ospite wrote:
snip
I feel I can add a:
Tested-by: Antonio Ospiteosp...@studenti.unina.it
Thanks added to the commit message.
I can backport the change to older kernels and even CC linux-stable if
you think it is appropriate, that's the least I can do to
This fixes a regression introduced by commit f7059ea and should be
backported to all supported stable kernels which have this commit.
Signed-off-by: Hans de Goede hdego...@redhat.com
Tested-by: Antonio Ospite osp...@studenti.unina.it
CC: sta...@vger.kernel.org
---
sorry for the spam, I had to resend it because I got the stable
email address wrong.
On 05/23/2012 10:20 AM, Hans de Goede wrote:
This fixes a regression introduced by commit f7059ea and should be
backported to all supported stable kernels which have this commit.
Signed-off-by: Hans de
Hi Mauro et al,
This is an updated version of this pull request, including a
regression fix in the gspca core
2nd updated version with amended commit msg for the regression fix,
correcting the CC email address for linux-stable
Here is a bunch of fixes for gspca and a couple of fixes for
good
On Wed 23 May 2012 11:09:04 Belisko Marek wrote:
Hi,
I'm planning to start writing driver for si4712 (for GTA04).
Anybody doing same thing to avoid double work?
There is a driver for the si4713 already. Is the si4712 very different from
the si4713? If it is very similar, then I would suggest
Hi Mauro,
Some more fixes for compiler warnings. It's for 3.5, but you can also postpone
it to 3.6.
Regards,
Hans
The following changes since commit abed623ca59a7d1abed6c4e7459be03e25a90a1e:
[media] radio-sf16fmi: add support for SF16-FMD (2012-05-20 16:10:05 -0300)
are available
The lirc TX functionality expects the process which writes (TX) data to
the lirc dev to sleep until the actual data has been transmitted by the
hardware.
Since the same timeout calculation is duplicated in more than one driver
(and would have to be duplicated in even more drivers as they gain TX
This patch lays the groundwork for adding a rc-core chardev.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-main.c | 211
include/media/rc-core.h|6 +
2 files changed, 196 insertions(+), 21 deletions(-)
diff --git
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/dvb/dvb-usb/af9015.c | 22 ++
drivers/media/dvb/dvb-usb/af9035.c | 20
The following patchset provides most of the features necessary for parity with
the LIRC subsystem that rc-core is intended to replace.
Most importantly, a chardev is provided which can be used to control RC hardware
using read (RX), write (TX) and ioctl (setting RX/TX parameters).
The patchset
Use atomic reads to avoid having to take a mutex when getting
the bitmask of supported protocols.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-core-priv.h |2 +-
drivers/media/rc/rc-ir-raw.c| 12
2 files changed, 5 insertions(+), 9 deletions(-)
Remove a redundant spinlock from struct rc_map.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-keytable.c | 43 +---
include/media/rc-core.h|4 ++--
include/media/rc-map.h |1 -
3 files changed, 20
Change the rc_register_device() code so that it isn't necessary to hold any
mutex. When device_add() is called, the norm is that the device should
actually be ready for use.
Holding the mutex is a recipe for deadlocks as (for example) calling
input_register_device() is quite likely to end up in a
As all the basics are now in place, we can finally add the ioctls
for adding/removing keytables from userspace.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-core-priv.h |3 +
drivers/media/rc/rc-keytable.c |6 ++-
drivers/media/rc/rc-main.c | 82
This adds a complementary ioctl to allow IR RX settings to be
changed.
Userspace is expected to first call RCIOCGIRRX, change the relevant parameters
in struct rc_ir_rx and then call RCIOCSIRRX.
The struct will be updated to reflect what the driver actually set the
parameters to (as all values
Add basic support for ioctl operations on the rc chardev.
Only two ioctl's are defined for now: one to get the rc-core
version and one to get the driver type of a given chardev.
Userspace is expected to make sure that both match the expected
values before proceeding with any ioctl/read/write
Fix various sparse warnings under drivers/media/rc/*.c, mostly
by making functions static.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/ene_ir.c |2 +-
drivers/media/rc/fintek-cir.c |4 ++--
drivers/media/rc/imon.c|8
The name is already misleading and will be more so in the future as the
connection to the input subsystem is obscured away further.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-main.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
Reporting pulse/space events via the /dev/rc/rcX device node is an
important step towards having feature parity with LIRC.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-ir-raw.c | 11 +++
include/media/rc-core.h | 10 ++
2 files changed, 21
Having a mutex named lock is a bit misleading.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-keytable.c |8
drivers/media/rc/rc-main.c | 22 +++---
include/media/rc-core.h|4 ++--
3 files changed, 17 insertions(+), 17
Move some more keytable related functionality over to rc-keytable.c which
allows more implementational details to be obscured away.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-core-priv.h | 11 +-
drivers/media/rc/rc-keytable.c | 213
LIRC currently supports quite a number of ioctl's for getting/setting
various TX and RX parameters. One problem with the one-ioctl-per-parameter
approach is that it might be quite elaborate to reprogram the hardware
(an operation which will have to be done once for every parameter change).
LIRC
Simplify and improve the locking in rc-ir-raw by making better use of
the existing kfifo functionality and by using RCU where possible.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-core-priv.h |6 +-
drivers/media/rc/rc-ir-raw.c| 119
Move drivers/media/rc/ir-raw.c to drivers/media/rc/rc-ir-raw.c and make it
a separate kernel module (rc-ir-raw.ko to make it clearer that it belongs to
the rc-* family).
Drivers which use IR decoding must use these functions:
rc_register_ir_raw_device()
As an example, this patch adds support for the new RCIOCGIRRX ioctl
to rc-loopback.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-loopback.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/rc/rc-loopback.c
Add separe rc device events on keytable addition/removal.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-main.c |2 ++
include/media/rc-core.h|2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index
Several drivers poke around in the internals of rc_dev, try to
fix them up in preparation for the next round of patches.
drivers/media/rc/ati_remote.c:
Removing the REP_DELAY setting on the input device should not
change how to driver works (as it does a keydown/keyup and has
This adds a complementary ioctl to allow IR TX settings to be
changed.
Much like the RCIOCSIRRX functionality, userspace is expected to call
RCIOCGIRTX, change values and then call RCIOCSIRTX and finally inspect
the struct rc_ir_tx to see the results.
Also, LIRC is changed to use the new
This patch is the first step towards making the rc chardev usable by adding
read functionality.
Basically the implementation mimics what evdev does. Userspace applications can
open the rc device and read rc_event structs with data. Only some basic events
are supported for now but later patches
In preparation for the next patches I had to understand the redrat driver (not
an easy task).
In the process I noticed that the debug printing functions look quite
suspicious. This is a minimal attempt at cleaning them up (though more work
remains to be done).
Signed-off-by: David Härdeman
As an example, this patch adds support for the new RCIOCSIRTX ioctl
to rc-loopback and removes deprecated functions without a loss in
functionality (as LIRC will automatically use the new functions).
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-loopback.c | 59
The scancode that is reported via the input device(s) is now incomplete
(missing the protocol) and redundant.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-keytable.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git
rc-core is a subsystem so it should be registered earlier if built into the
kernel.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index
Now that the protocol is part of the scancode, it is pretty easy to merge
the rc5 and streamzap decoders. An additional advantage is that the decoder
is now stricter as it waits for the trailing silence before determining that
a command is a valid rc5/streamzap command (which avoids collisions
Change struct rc_keytable to be RCU-friendly by kmalloc():ing an
entire new scancode,protocol - keycode table every time the table
is changed (i.e. via EVIOCSKEYCODE(_V2)).
The advantage is that the performance-critical keycode lookup path
can be made entirely lock-free and that GFP_ATOMIC
As an example, this patch adds support for the new RCIOCSIRRX ioctl
to rc-loopback and removes deprecated functions without a loss in
functionality (as LIRC will automatically use the new functions).
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-loopback.c | 84
This ioctl follows the same rationale and structure as the ioctl for
getting IR RX settings (RCIOCGIRRX) but it works on TX settings instead.
As with the RX ioctl, it would be nice if people could check struct
rc_ir_tx carefully to make sure that their favourite parameter
hasn't been left out.
The previous code allocated a char buffer of size MCE_CMDBUF_SIZE (384) by
kzalloc():ing sizeof(unsigned) * MCE_CMDBUF_SIZE bytes.
The buffer was therefore 4 * the necessary size.
Additionally, zeroing out the buffer is pointless.
Replace the allocated buffer with a stack buffer.
This patch changes rc-core to use a device table rather than atomic integers
to assign unique numbers to each rc device. This is in preparation for
introducing rc-core chardevs.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/ir-raw.c |2 +-
drivers/media/rc/rc-main.c |
Add write functionality to the rc chardev (for use in transmitting remote
control commands on capable hardware).
The data format of the TX data is probably going to have to be dependent
on the rc_driver_type.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-main.c | 68
Remove the RC_MAP_EMPTY hack and instead allow for empty keymaps.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/dvb/dvb-usb/af9015.c |4
drivers/media/dvb/dvb-usb/af9035.c |1 -
drivers/media/dvb/dvb-usb/dvb-usb-remote.c |4 +---
Using struct rc_event as the data unit for writes from userspace provides
more flexibility and easier future compatibility with future developments
(e.g. if rc-core grew support for some very different transmission, such
as RF transmission).
Signed-off-by: David Härdeman da...@hardeman.nu
---
A few ifdef __KERNEL__ and some reorganisation to make rc-core.h usable from
userspace programs.
Signed-off-by: David Härdeman da...@hardeman.nu
---
include/media/rc-core.h | 76 +--
1 file changed, 54 insertions(+), 22 deletions(-)
diff --git
Hi Sakari,
Thanks for the patch.
On Wednesday 16 May 2012 06:12:49 Sakari Ailus wrote:
The chip is typically powered constantly and no board uses the set_power()
callback. Remove it.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/as3645a.c | 39
Hi Laurent,
On Wed, May 23, 2012 at 01:00:08PM +0200, Laurent Pinchart wrote:
Hi Sakari,
Thanks for the patch.
On Wednesday 16 May 2012 06:12:49 Sakari Ailus wrote:
The chip is typically powered constantly and no board uses the set_power()
callback. Remove it.
Signed-off-by:
Hi Sakari,
On Wednesday 23 May 2012 14:19:51 Sakari Ailus wrote:
On Wed, May 23, 2012 at 01:00:08PM +0200, Laurent Pinchart wrote:
On Wednesday 16 May 2012 06:12:49 Sakari Ailus wrote:
The chip is typically powered constantly and no board uses the
set_power() callback. Remove it.
On Wed, May 23, 2012 at 01:31:26PM +0200, Laurent Pinchart wrote:
Hi Sakari,
...
If the chip is powered on constantly, why do we need a .s_power() subdev
operation at all ?
I don't know why was it there in the first place. Probably to make it easier
to use the driver on boards that
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4].
v6:
- fixed missing entry in v4l2_memory_names
- fixed a bug occuring
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/videobuf2-dma-contig.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git
vb2-dma-contig returns a vb2_dc_conf structure instance as the vb2
allocation context. That structure only stores a pointer to the physical
device. Remove it and use the device pointer directly as the allocation
context.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Acked-by:
From: Marek Szyprowski m.szyprow...@samsung.com
This patch adds support for prepare/finish callbacks in VB2 allocators. These
callback are used for buffer flushing.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
From: Sumit Semwal sumit.sem...@ti.com
This patch makes changes for adding dma-contig as a dma_buf user. It provides
function implementations for the {attach, detach, map, unmap}_dmabuf()
mem_ops of DMABUF memory type.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal
This patch introduces usage of dma_map_sg to map memory behind
a userspace pointer to a device as dma-contiguous mapping.
This patch contains some of the code kindly provided by Marek Szyprowski
m.szyprow...@samsung.com and Kamil Debski k.deb...@samsung.com and Andrzej
Pietrasiewicz
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
Group functions by buffer type.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/videobuf2-dma-contig.c | 92
1 file changed, 54 insertions(+), 38 deletions(-)
diff
This patch enhances s5p-fimc with support for DMABUF importing via
V4L2_MEMORY_DMABUF memory type.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
---
From: Sumit Semwal sumit.sem...@ti.com
This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done
This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: linux-...@vger.kernel.org
---
Documentation/DocBook/media/v4l/compat.xml |
This patch enhances s5p-tv with support for DMABUF importing via
V4L2_MEMORY_DMABUF memory type.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-tv/Kconfig |1 +
2012/5/23 Jan Kara j...@suse.cz:
On Sun 20-05-12 22:23:14, Akinobu Mita wrote:
memweight() is the function that counts the total number of bits set
in memory area. The memory area doesn't need to be aligned to
long-word boundary unlike bitmap_weight().
Thanks for the patch. I have some
On Wed 23-05-12 21:12:18, Akinobu Mita wrote:
2012/5/23 Jan Kara j...@suse.cz:
On Sun 20-05-12 22:23:14, Akinobu Mita wrote:
memweight() is the function that counts the total number of bits set
in memory area. The memory area doesn't need to be aligned to
long-word boundary unlike
Hello everyone,
The patches adds support for DMABUF exporting to V4L2 stack. The latest
support for DMABUF importing was posted in [1]. The exporter part is dependant
on DMA mapping redesign [2] which is not merged into the mainline. Therefore it
is posted as a separate patchset. Moreover some
This patch enhances s5p-fimc with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |9 +
1 file changed, 9
This patch adds extension to videobuf2-core. It allow to export a mmap buffer
as a file descriptor.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-core.c | 67
This patch removes vb2_mmap_pfn_range from videobuf2 helpers.
The function is no longer used in vb2 code.
Suggested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
From: Marek Szyprowski m.szyprow...@samsung.com
Let mmap method to use dma_mmap_coherent call. This patch depends on DMA
mapping redesign patches because the usage of dma_mmap_coherent breaks
dma-contig allocator for architectures other than ARM and AVR.
Signed-off-by: Marek Szyprowski
This patch enhances s5p-mfc with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Kamil Debski k.deb...@samsung.com
---
drivers/media/video/s5p-mfc/s5p_mfc_dec.c | 13
This patch adds the setup of sglist list for MMAP buffers.
It is needed for buffer exporting via DMABUF mechanism.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-dma-contig.c | 70
This patch makes use of sg_alloc_table_from_pages to simplify
handling of sg tables.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-dma-contig.c | 90
1 file
This patch adds support for exporting a dma-contig buffer using
DMABUF interface.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-dma-contig.c | 119
1 file changed,
This patch adds extension to V4L2 api. It allow to export a mmap buffer as file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
mmap and return a file descriptor on success.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park
There will be no soc_camera_device instance with a soc-camera device is
used with a non soc-camera host, so we won't be able to pass the
soc_camera_device fake platform device to board code. Pass the physical
device instead.
The argument is currently not used by any board file so this is safe.
Several client drivers access the hardware at probe time, for instance
to read the probe chip ID. Such chips need to be powered up when being
probed.
soc-camera handles this by powering chips up in the soc-camera probe
implementation. However, this will break with non soc-camera hosts that
don't
The .s_power() call only covers the .g_mbus_fmt() operation call.
Several clients required to be powered on to retrieve the current mbus
format but have now been fixed. The .s_power() call is thus not needed
anymore and can be removed.
Signed-off-by: Laurent Pinchart
Instead of forcing all soc-camera drivers to go through the mid-layer to
handle power management, create soc_camera_power_[on|off]() functions
that can be called from the subdev .s_power() operation to manage
regulators and platform-specific power handling. This allows non
soc-camera hosts to use
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
The soc-camera module exports functions that are needed by soc-camera
client drivers even when not running in soc-camera mode. Replace the
platform_driver_probe() with a platform_driver_register() call to avoid
module load failures if no soc-camera device is present.
Signed-off-by: Laurent
Hi Guennadi,
Here's a set of miscellaneous soc-camera patches that I wrote as part of an
effort to improve the interoperability between soc-camera clients and non
soc-camera hosts (namely the ov772x and the OMAP3 ISP in this case).
All patches have been compile-tested but not runtime-tested as I
Hi,
As discussed before 2 different use-cases have come up where we want some
knowledge of there being different radio bands added to the v4l2 API.
In Manjunatha Halli's case, if I understand things correctly, he wants
to limit hw_freq_seek to a certain band, rather then the receiver happily
Hi,
On 05/23/2012 09:24 PM, halli manjunatha wrote:
On Wed, May 23, 2012 at 1:29 PM, Hans de Goedehdego...@redhat.com wrote:
snip my super long proposal intro :)
###
So given all of the above I would like to propose the following:
1) Add a band field to struct v4l2_tuner, and a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/22/2012 06:06 PM, Andy Walls wrote:
Devin Heitmueller dheitmuel...@kernellabs.com wrote:
On Tue, May 22, 2012 at 4:34 PM, Bob Lightfoot
boblf...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Dear LinuxTv and AtRpms
The code attempts to maintain a user format and a sensor format,
but in this case it looks like a typo is passing the user format down
to the sensor.
This was preventing display of video at anything other than 640x480.
Signed-off-by: Daniel Drake d...@laptop.org
---
Laurent Pinchart laurent.pinchart at ideasonboard.com writes:
Hi Josh,
On Wednesday 29 February 2012 17:58:52 Josh Boyer wrote:
Hi Laurent,
We've had a bug report [1] in Fedora for a while now that the uvcvideo
driver no longer works on the Creative Live! Cam Optia AF (ID
Hi Tony,
On Tue, May 8, 2012 at 6:46 PM, Tony Lindgren t...@atomide.com wrote:
* Sergio Aguirre saagui...@ti.com [120502 08:21]:
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
It seems that at this point we should initialize new things
89 matches
Mail list logo
