On Wed, 2011-03-16 at 16:24 -0400, Jarod Wilson wrote:
> Signed-off-by: Jarod Wilson
> ---
> drivers/staging/lirc/lirc_zilog.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/lirc/lirc_zilog.c
> b/drivers/staging/lirc/lirc_zilog.c
> index 407d4b4
Hi Vaibhav,
On Thursday 10 March 2011 19:20:02 Hiremath, Vaibhav wrote:
> On Thursday, March 10, 2011 11:25 PM Laurent Pinchart wrote: > > On Thursday
10 March 2011 18:09:42 Hiremath, Vaibhav wrote:
> > > On Thursday, March 10, 2011 10:12 PM Laurent Pinchart wrote:
> > > > On Thursday 10 March 20
On 13/03/11 11:47, Martin Vidovic wrote:
>>
>> Btw, we should choose a more meaningful name for 'camX'.
>> I would prefer something like cainoutX or caioX or cinoutX or cioX.
>>
>
>
> I agree, camX could be misleading since it's not necessarily a CAM
> application.
>
> According to EN 50221 the
On Wed, 2011-03-16 at 12:47 -0700, Greg KH wrote:
> Very cool stuff. You are away of:
> http://vusb-analyzer.sourceforge.net/
> right?
>
> I know you are doing this in console mode, but it looks close to the
> same idea.
Perhaps there should be some references to vusb-analyzer and similar
On Wed, Mar 16, 2011 at 09:20:24PM +0100, Paul Bolle wrote:
> On Wed, 2011-03-16 at 12:47 -0700, Greg KH wrote:
> > Very cool stuff. You are away of:
> > http://vusb-analyzer.sourceforge.net/
> > right?
> >
> > I know you are doing this in console mode, but it looks close to the
> > same idea
Signed-off-by: Jarod Wilson
---
drivers/media/rc/mceusb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index eedefce..044fb7a 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -261,7 +261,7
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_zilog.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 407d4b4..5ada643 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/
Both lirc_imon and lirc_sasem were causing gcc to complain about the
possible use of uninitialized variables.
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/lirc_imon.c |2 +-
drivers/staging/lirc/lirc_sasem.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/d
The new hauppauge key tables use both device code button code.
Signed-off-by: Jarod Wilson
---
drivers/media/video/ir-kbd-i2c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index 672935f..3ab875d 100
Signed-off-by: Jarod Wilson
---
drivers/media/rc/imon.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index e7dc6b4..f714e1a 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -277,12 +277,2
Reported-by: Daniel Burr
Signed-off-by: Jarod Wilson
---
.../DocBook/v4l/lirc_device_interface.xml |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml
b/Documentation/DocBook/v4l/lirc_device_interface.xml
index 6
This is a stack of relatively small miscellaneous IR fixes for 2.6.39.
The ir-kbd-i2c one is actually relatively important, following the
pending changes to the hauppauge keymaps though, and the zilog error's
usefulness becomes apparent the second you try running lirc_zilog on
a pre-2.6.33 kernel w
The hdpvr's IR part, in short, sucks. As observed with a usb traffic
sniffer, the Windows software for it uses a polling interval of 405ms.
Its still not behaving as well as I'd like even with this change, but
this inches us closer and closer to that point...
Signed-off-by: Jarod Wilson
---
driv
Make the hdpvr's i2c master implementation more closely mirror that of
the pvrusb2 driver. Currently makes no significant difference in IR
reception behavior with ir-kbd-i2c (i.e., it still sucks).
Signed-off-by: Jarod Wilson
---
drivers/media/video/hdpvr/hdpvr-i2c.c | 67 +
From: Juan J. Garcia de Soria
Remove older drivers lirc_it87 and lirc_ite8709 from the LIRC staging area,
since they're now superceded by ite-cir.
Signed-off-by: Juan J. Garcia de Soria
Tested-by: Stephan Raue
Signed-off-by: Jarod Wilson
---
drivers/staging/lirc/Kconfig| 12 -
driv
This is a re-submission, my previous patch has not been send in plain text.
This patch add a new jeilin dual mode camera support and some specific controls
settings.
Regards
Signed-off-by: Patrice CHOTARD
Theodore Kilgore
---
Documentation/video4linux/gspca.txt |1 +
drive
On Wed, Mar 16, 2011 at 03:34:17PM -0300, Mauro Carvalho Chehab wrote:
> While trying to debug some issues on a driver on Linux, and using a
> Beagleboard card as a
> hardware USB sniffer[1], I noticed the need of having a parser to work with
> the sniffer data. While wireshark provides a good way
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:Wed Mar 16 19:00:36 CET 2011
git hash:41f3becb7bef489f9e8c35284dd88a1ff59b190c
gcc version: i686-linux-gcc (GCC) 4.5.
First post to this list, but not new to Linux.
I'm trying to get a Compro VideoMate S350 card to work in a 32bit Centos
5.5 system that also has a Hauppauge WinTV-NOVA-T-500 that uses the
dvb-usb-dib0700.ko kernel module as its driver. The Nova-T appears to be
working.
I've used the v4l sou
While trying to debug some issues on a driver on Linux, and using a Beagleboard
card as a
hardware USB sniffer[1], I noticed the need of having a parser to work with
the sniffer data. While wireshark provides a good way of looking into the info,
most of the times, I just want to convert the data i
On Wed, Mar 16, 2011 at 1:49 PM, Laurent Pinchart
wrote:
> Hi Alex,
>
> On Wednesday 16 March 2011 17:09:45 Alex Deucher wrote:
>> On Wed, Mar 16, 2011 at 3:37 AM, Li Li wrote:
>> > Sorry but I feel the discussion is a bit off the point. We're not
>> > going to compare the pros and cons of curren
Hi Alex,
On Wednesday 16 March 2011 17:09:45 Alex Deucher wrote:
> On Wed, Mar 16, 2011 at 3:37 AM, Li Li wrote:
> > Sorry but I feel the discussion is a bit off the point. We're not
> > going to compare the pros and cons of current code (GEM/TTM, HWMEM,
> > UMP, CMA, VCM, CMEM, PMEM, etc.)
> >
Hi Sakari,
On Wednesday 16 March 2011 18:08:04 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > Hi Sakari,
> >>> + return in_info->bpp - out_info->bpp + additional_shift <= 6;
> >>
> >> Currently there are no formats that would behave badly in this check?
> >> Perhaps it'd be good idea to take t
Laurent Pinchart wrote:
> Hi Sakari,
Hi Laurent and Michael!
...
>>> + return in_info->bpp - out_info->bpp + additional_shift <= 6;
>>
>> Currently there are no formats that would behave badly in this check?
>> Perhaps it'd be good idea to take that into consideration. The shift
>> that can be
Hi Alex,
On Wednesday 16 March 2011 17:00:03 Alex Deucher wrote:
> On Wed, Mar 16, 2011 at 4:52 AM, Laurent Pinchart wrote:
> > On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote:
> >
> > [snip]
> >
> >> FWIW, I have yet to see any v4l developers ever email the dri mailing
> >> list while disc
Hi Sakari,
Thanks for the comments.
On Wednesday 16 March 2011 16:44:49 Sakari Ailus wrote:
> Hi Michael,
>
> Thanks for the patch. I have some comments below.
>
> Michael Jones wrote:
> > To use the lane shifter, set different pixel formats at each end of
> > the link at the CCDC input.
> >
>
On Wed, Mar 16, 2011 at 3:37 AM, Li Li wrote:
> Sorry but I feel the discussion is a bit off the point. We're not
> going to compare the pros and cons of current code (GEM/TTM, HWMEM,
> UMP, CMA, VCM, CMEM, PMEM, etc.)
>
> The real problem is to find a suitable unified memory management
> module f
On Wed, Mar 16, 2011 at 4:52 AM, Laurent Pinchart
wrote:
> Hi Alex,
>
> On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote:
>
> [snip]
>
>> FWIW, I have yet to see any v4l developers ever email the dri mailing
>> list while discussing GEM, TTM, or the DRM, all the while conjecturing
>> on aspect
Hi,
2011. 3. 17., 오전 12:27, Laurent Pinchart 작성:
> On Wednesday 16 March 2011 16:17:30 Kim HeungJun wrote:
>> 2011. 3. 16., 오후 11:15, Laurent Pinchart 작성:
>>> On Wednesday 16 March 2011 05:50:11 Kim, HeungJun wrote:
2011-03-16 오전 9:14, Laurent Pinchart 쓴 글:
>>> [snip]
[snip]
>>> Is the macr
2011/3/15 matthieu castet :
> Hi,
>
> can this file be added to dvb-apps/util/scan/dvb-t
No. Use "auto-Normal" [1] (or the +-167kHz file if needed).
Christoph
[1] http://linuxtv.org/hg/dvb-apps/file/tip/util/scan/dvb-t/auto-Normal
> Thanks
>
> Matthieu
>
> #http://tvignaud.pagesperso-orange.fr
Hi Michael,
Thanks for the patch. I have some comments below.
Michael Jones wrote:
> To use the lane shifter, set different pixel formats at each end of
> the link at the CCDC input.
>
> Signed-off-by: Michael Jones
> ---
> drivers/media/video/omap3-isp/isp.c |7 ++-
> drivers/media/v
On Wednesday 16 March 2011 16:17:30 Kim HeungJun wrote:
> 2011. 3. 16., 오후 11:15, Laurent Pinchart 작성:
> > On Wednesday 16 March 2011 05:50:11 Kim, HeungJun wrote:
> >> 2011-03-16 오전 9:14, Laurent Pinchart 쓴 글:
> > [snip]
> >
> >>> What bothers me with your auto-focus implementation is that the us
2011. 3. 16., 오후 11:15, Laurent Pinchart 작성:
> Hi,
>
> On Wednesday 16 March 2011 05:50:11 Kim, HeungJun wrote:
>> 2011-03-16 오전 9:14, Laurent Pinchart 쓴 글:
>
> [snip]
>
>>> What bothers me with your auto-focus implementation is that the user
>>> might want to perform auto-focus several times.
>From 81a09633855b88d19f013d7e559e0c4f602ba711 Mon Sep 17 00:00:00 2001
From: Michael Jones
Date: Thu, 10 Mar 2011 16:16:38 +0100
Subject: [PATCH] ignore Documentation/DocBook/media/
It is created and populated by 'make htmldocs'
Signed-off-by: Michael Jones
---
Documentation/DocBook/.gitigno
Hi,
On Wednesday 16 March 2011 05:50:11 Kim, HeungJun wrote:
> 2011-03-16 오전 9:14, Laurent Pinchart 쓴 글:
[snip]
> > What bothers me with your auto-focus implementation is that the user
> > might want to perform auto-focus several times. Let's imagine this use
> > case:
> >
> > 1. The user point
Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated
image signal processor.
Signed-off-by: Heungjun Kim
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Hi Hans and everyone,
This is sixth version of M-5MOLS 8 Mega Pixel camera sensor. And, if you see
previo
On Tue, Feb 22, 2011 at 6:57 PM, Guennadi Liakhovetski
wrote:
> Use soc_camera_platform helper functions to dynamically manage the
> camera device.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> arch/arm/mach-shmobile/board-mackerel.c | 28 +++-
> 1 files changed, 7 i
I have been able to make it working using "em28xx-new" driver patched
for 2.6.30 kernel
Thanks Oravecz Csaba for help
At least I don't receive I/O error when reading from /dev/dsp2
But for that I needed to build frankenstein openSUSE 11.1 which runs
quite unstable
What has been done:
---
Hi Bastian,
On 03/16/2011 11:01 AM, Bastian Hecht wrote:
> Hello dear omap-isp developers,
>
> I'm working with a OV5642 sensor with an 8-bit parallel bus.
>
> I'm referring to this patch:
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/29876/match=sgrbg8
>
> Michael,
Hello dear omap-isp developers,
I'm working with a OV5642 sensor with an 8-bit parallel bus.
I'm referring to this patch:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/29876/match=sgrbg8
Michael, you say that the patch applies to media-0005-omap3isp from Laurent.
I can
Hi Alex,
On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote:
[snip]
> FWIW, I have yet to see any v4l developers ever email the dri mailing
> list while discussing GEM, TTM, or the DRM, all the while conjecturing
> on aspects of it they admit to not fully understanding. For future
> reference
On Tuesday 15 March 2011 17:07:10 Robert Fekete wrote:
> On 8 March 2011 20:23, Laurent Pinchart wrote:
> > On Tuesday 08 March 2011 20:12:45 Andy Walls wrote:
> >> On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote:
> >>
> >> [snip]
> >>
> >> > > > It really shouldn't be that hard to get
On Wed, Mar 16, 2011 at 4:37 PM, Li Li wrote:
> Sorry but I feel the discussion is a bit off the point. We're not
> going to compare the pros and cons of current code (GEM/TTM, HWMEM,
> UMP, CMA, VCM, CMEM, PMEM, etc.)
>
> The real problem is to find a suitable unified memory management
> module f
Sorry but I feel the discussion is a bit off the point. We're not
going to compare the pros and cons of current code (GEM/TTM, HWMEM,
UMP, CMA, VCM, CMEM, PMEM, etc.)
The real problem is to find a suitable unified memory management
module for various kinds of HW components (including CPU, VPU, GPU
44 matches
Mail list logo
