This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Tue Jul 21 08:14:53 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 12321:824d2ff85bd5
gcc version: gcc
Hi to all,
one question about the frontend ves1820.c.
Why are these calculations in register 0x13, 0x14, 0x15, 0x16, 0x17 and 0x18
made?
For example, function FE_READ_SIGNAL_STRENGT. Why is the content of register
0x17 shifted 8 bit to the left and then concatenate with itself?
Best regards,
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the
following:
- flexcop: fix compile error
When this fix is committed I'll start another daily build run.
Thanks,
Hans
diffstat:
flexcop-fe-tuner.c |2 +-
1 file changed, 1 insertion(+), 1
Em Wed, 15 Jul 2009 09:41:53 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:
Mauro,
Thanks for taking care of this.
Anytime. Yet, it seems that those patches depend on Chaithrika DM646x patches
that weren't accepted yet by arm maintainer:
File to patch:
On Dienstag, 23. Juni 2009, Trent Piepho wrote:
On Tue, 23 Jun 2009, Matthias Schwarzott wrote:
On Mon, 2009-06-22 at 16:36 +0200, Matthias Schwarzott wrote:
It seems the path to lsmod tool is hardcoded in the Makefile for
out-of-tree building of v4l-dvb.
Shouldn't $PATH of root be
On Mon, 20 Jul 2009 20:09:44 -0400, Andy Walls wrote:
On Sun, 2009-07-19 at 14:59 +0200, Jean Delvare wrote:
Functions which are referenced by their address can't be inlined by
definition.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Jean,
Looks godd to me, but you forgot to add
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Tue Jul 21 09:33:58 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 12322:6c5317c966eb
gcc version: gcc
Hi,
Am Dienstag, den 21.07.2009, 08:36 +0200 schrieb Hans Verkuil:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the
following:
that link fails. You have it in
http://linuxtv.org/hg/~hverkuil/v4l-dvb-strctrl
- flexcop: fix compile error
When this fix
Am Dienstag, den 21.07.2009, 11:04 +0200 schrieb hermann pitton:
Hi,
Am Dienstag, den 21.07.2009, 08:36 +0200 schrieb Hans Verkuil:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the
following:
that link fails. You have it in
Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
Trent Piepho xy...@speakeasy.org wrote:
On Mon, 20 Jul 2009, Andrew Morton wrote:
(switched to email. Please respond via emailed
Hi Andy,
On Mon, 20 Jul 2009 20:07:50 -0400, Andy Walls wrote:
On Sun, 2009-07-19 at 14:47 +0200, Jean Delvare wrote:
Hi Andy,
On Fri, 17 Jul 2009 16:35:37 -0400, Andy Walls wrote:
This patch augments the init data passed by bridge drivers to ir-kbd-i2c
so that the ir_type can be
Hi,
as in subject I've a problem with this hardware, identified as USB device with
id eb1a:2881.
I've already seen that someone has it working on different arch and kernel
version
(http://www.mail-archive.com/linux-media@vger.kernel.org/msg07551.html); I've
no error on build time, nor in
Hrm, okay, I'll double-check that... If its not there, perhaps the card
isn't quite seated correctly. Or the machine is bunk. Or the card has
gone belly up. Amusing that it works as much as it does though, if any
of the above is the case...
Thanks for the info!
Jrod,
Yeah. If the pci enable
Hi,
This patch implements changing resolution in zr364xx_vidioc_s_fmt_vid_cap for
zr364xx driver. This version is synced with v4l-dvb as of 20/Jul/2009. Tested
with Creative PC-CAM 880.
Nice, I successfully tested your patch with 2 compatible webcams.
From the users feedbacks I had before,
Mauro,
Please pull from http://linuxtv.org/hg/~ajacquet/v4l-dvb
for the following changeset:
01/01: Implement changing resolution on the fly for zr364xx driver
http://linuxtv.org/hg/~ajacquet/v4l-dvb?cmd=changeset;node=ebb57057cf4d
zr364xx.c | 65
Mauro and Hans,
Not sure if you are referring to vpfe capture patch or DM6467 display patch.
I think Makefile and Kconfig changes needs to be cherry picked...
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
Em Terça-feira 21 Julho 2009, Antoine Jacquet escreveu:
Hi,
Hi,
This patch implements changing resolution in zr364xx_vidioc_s_fmt_vid_cap
for zr364xx driver. This version is synced with v4l-dvb as of
20/Jul/2009. Tested with Creative PC-CAM 880.
Nice, I successfully tested your
From: Julia Lawall ju...@diku.dk
It seems from other code that it is the dst_type field rather than the
type_flags field that contains values of the form DST_TYPE_IS...
The type_flags field contains values of the form DST_TYPE_HAS...
The semantic match that finds this problem is as follows:
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Tue Jul 21 19:00:07 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 12324:6477aa1782d5
gcc version: gcc
Mauro,
Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/
for the following 2 changesets:
uvcvideo: Add PROBE_DEF quirk and enable it for the MT6227 device
uvcvideo: Don't apply the FIX_BANDWIDTH quirk to all ViMicro devices
uvc_driver.c | 25 ++---
uvc_video.c
Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh:
Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
Trent Piepho xy...@speakeasy.org wrote:
On Mon, 20 Jul 2009, Andrew
in
http://bach.metasys.com.br/~lamarque/zr364xx/zr364xx.c-resolution.patch-
incremental-v4l-dvb-20090721
Signed-off-by: Lamarque V. Souza lamar...@gmail.com
---
diff -r 6477aa1782d5 linux/drivers/media/video/zr364xx.c
--- a/linux/drivers/media/videon/zr364xx.c Tue Jul 21 09:17:24 2009 -0300
Mauro,
The following revised patch series, incorporating comments I received,
will allow the cx18 bridge driver to properly set up supported IR
devices to allow use by ir-kbd-i2c, lirc_i2c, lirc_pvr150, and
lirc_zilog for both old and new (= 2.6.30) kernels.
They are:
1/4: ir-kbd-i2c: Remove
(This is a resubmission of a patch by Jean Delvare)
Functions which are referenced by their address can't be inlined by
definition.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Signed-off-by: Andy Walls awa...@radix.net
diff -r 6477aa1782d5 linux/drivers/media/video/ir-kbd-i2c.c
---
This patch augments the init data passed by bridge drivers to
ir-kbd-i2c, so that the ir_type can be set explicitly, and so
ir-kbd-i2c internal get_key functions can be reused without
requiring symbols from ir-kbd-i2c in the bridge driver.
Signed-off-by: Andy Walls awa...@radix.net
Reviewed-by:
Hello everyone-
Apologies in advance for spamming the list, but we're after adding
dual device support for the existing, GPL'd em28xx tuner driver
currently in the mainline Linux kernel. We do not have this development
resource in house and had hoped perhaps someone on the list might be
This patch add support to the cx18 driver for setting up the
Z8F0811/Hauppauge IR Tx/Rx chip with the i2c binding model in newer
kernels.
Signed-off-by: Andy Walls awa...@radix.net
Reviewed-by: Jean Delvare kh...@linux-fr.org
diff -r 6477aa1782d5 linux/drivers/media/video/cx18/cx18-cards.c
---
This patch adds support for Zilog Z8F0811 IR transceiver chips on
CX2341[68] based boards to ir-kbd-i2c for both the old i2c binding model
and the new i2c binding model.
Signed-off-by: Andy Walls awa...@radix.net
Reviewed-by: Jean Delvare kh...@linux-fr.org
diff -r 6477aa1782d5
On Tuesday 21 July 2009 10:23:53 Steven Toth wrote:
Hrm, okay, I'll double-check that... If its not there, perhaps the card
isn't quite seated correctly. Or the machine is bunk. Or the card has
gone belly up. Amusing that it works as much as it does though, if any
of the above is the
On Tue, Jul 21, 2009 at 9:09 PM, Steve Castellottis...@eyemagnet.com wrote:
Hello everyone-
Apologies in advance for spamming the list, but we're after adding dual
device support for the existing, GPL'd em28xx tuner driver currently in the
mainline Linux kernel. We do not have this
On Tue, 21 Jul 2009 21:35:47 -0400
Jarod Wilson ja...@redhat.com wrote:
So its either I have *two* machines with bad, but only slightly bad,
and in the same way, PCI slots which seem to work fine with any other
card I have (uh, unlikely),
... not unlikely if the two machines are similar -
On 07/21/2009 06:42 PM, Devin Heitmueller wrote:
On Tue, Jul 21, 2009 at 9:09 PM, Steve Castellottis...@eyemagnet.com wrote:
We can confirm that a development system running Fedora 11 with the
latest stable kernel (2.6.29.5-191.fc11.i686.PAE), with identical em28xx
devices connected still
On Tue, Jul 21, 2009 at 10:19 PM, Steve Castellottis...@eyemagnet.com wrote:
On 07/21/2009 06:42 PM, Devin Heitmueller wrote:
On Tue, Jul 21, 2009 at 9:09 PM, Steve Castellottis...@eyemagnet.com
wrote:
We can confirm that a development system running Fedora 11 with the
latest stable
These changes were a direct result of using a semantic patch
More information can be found at http://www.emn.fr/x-info/coccinelle/
Signed-off-by: Stoyan Gaydarov sgay...@uiuc.edu
---
drivers/media/video/gspca/conex.c |2 +-
drivers/media/video/gspca/etoms.c |4 ++--
Am Mittwoch 22 Juli 2009 00:16:54 schrieben Sie:
Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh:
Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
Trent Piepho
On 07/21/2009 07:32 PM, Devin Heitmueller wrote:
I agree that *in theory* you should be able to do two devices. A back
of the envelope calculation of 640x480 at 30fps in YUVY capture should
be about 148Mbps. That said, I don't think the scenario you are
describing has really been
On Tue, Jul 21, 2009 at 11:47 PM, Steve Castellottis...@eyemagnet.com wrote:
On 07/21/2009 07:32 PM, Devin Heitmueller wrote:
I agree that *in theory* you should be able to do two devices. A back
of the envelope calculation of 640x480 at 30fps in YUVY capture should
be about 148Mbps. That
Em Tue, 21 Jul 2009 20:47:05 -0700
Steve Castellotti s...@eyemagnet.com escreveu:
On 07/21/2009 07:32 PM, Devin Heitmueller wrote:
I agree that *in theory* you should be able to do two devices. A back
of the envelope calculation of 640x480 at 30fps in YUVY capture should
be about 148Mbps.
38 matches
Mail list logo
