Hi All
Now I have working radio for our TV cards based on tm6000 and xc5000.
TV works too.
After some time I'll send my changes for discuss here.
With my best regards, Dmitry.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.ker
Reposting. Sorry for the rich text in my previous email.
I'm looking at the videobuf2 stuff, and would like to use it because it solves
a bunch of problems for me that were in videobuf (for example, I'm writing a
variant of videobuf-dma-contig, and there's some private memory allocator state
I
From: Andrew Chew
This soc_camera driver is for Omnivision's OV9740 sensor. This initial
submission provides support for YUV422 output at 1280x720 (720p), which is
the sensor's native resolution. 640x480 (VGA) is also supported, with
cropping and scaling performed by the sensor's ISP.
This dri
On Thu, Jan 06, 2011 at 01:56:40PM +0100, Jean-Francois Moine wrote:
> On Thu, 6 Jan 2011 09:28:36 -0200
> Mauro Carvalho Chehab wrote:
>
> > This patch series backport POWER INV fixes for sonixj sensors.
> >
> > Jean,
> >
> > I'm currently without any sensorj camera. Could you please test this
I'm confused, what tree is this for? .32? It's already in .37, right?
thanks,
greg k-h
On Thu, Jan 06, 2011 at 09:28:35AM -0200, Mauro Carvalho Chehab wrote:
> Backports changeset 5e68f400aad4e2c29e2531cc4413c459fa88cb62
>
> Signed-off-by: Jean-François Moine
> Signed-off-by: Mauro Carvalho
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 Feb 16 19:00:34 CET 2011
git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f
git media-master: gcc version: i6
Hi,
On Wed, 16 Feb 2011, javier Martin wrote:
> Hi,
> does currently soc-camera support using soc-camera host drivers with
> non soc-camera sensors?
> For instance, I would like to use soc-camera host driver
> "mx2_camera.c" with non soc-camera sensor "tvp5150.c".
>
> How much effort would it ta
Em 16-02-2011 15:25, VDR User escreveu:
> On Wed, Feb 16, 2011 at 7:20 AM, Jarod Wilson wrote:
>>> It is not a need. I simply observed that after the IR_ to RC_ rename
>>> there was another set of drivers being built which I did not ask for.
>>
>> So disable them. I think most people would rather
On Wed, Feb 16, 2011 at 7:20 AM, Jarod Wilson wrote:
>> It is not a need. I simply observed that after the IR_ to RC_ rename
>> there was another set of drivers being built which I did not ask for.
>
> So disable them. I think most people would rather have this support
> enabled so that remotes J
Jarod Wilson writes:
> On Wed, Feb 16, 2011 at 10:09:44AM -0500, Stephen Wilson wrote:
>> Andy Walls writes:
>>
>> > On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote:
>> >> Having the RC_CORE config default to INPUT is almost equivalent to
>> >> saying "yes". Default to "no" instead.
>>
On Wed, Feb 16, 2011 at 11:54 AM, Fernando Laudares Camargos
wrote:
> Thanks, Jarod, for re-directing the message and explaining why the fix
> from Mauro's wouldn't suffice here.
>
> Devin: I was hoping they (Hauppauge) had used the same componentry as
> of the predecessor board (HVR-1120) for the
Thanks, Jarod, for re-directing the message and explaining why the fix
from Mauro's wouldn't suffice here.
Devin: I was hoping they (Hauppauge) had used the same componentry as
of the predecessor board (HVR-1120) for the IR, looks that's not the
case. I would like to help to get the card supported
On Tue, Feb 15, 2011 at 5:18 PM, Jarod Wilson wrote:
> On Tue, Feb 15, 2011 at 05:04:33PM -0500, Jarod Wilson wrote:
>> First off, video4linux-list is dead, you want linux-media (added to cc).
>>
>> On Tue, Feb 15, 2011 at 06:27:29PM -0200, Fernando Laudares Camargos wrote:
>> > Hello,
>> >
>> > I
On Wed, Feb 16, 2011 at 10:09:44AM -0500, Stephen Wilson wrote:
> Andy Walls writes:
>
> > On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote:
> >> Having the RC_CORE config default to INPUT is almost equivalent to
> >> saying "yes". Default to "no" instead.
> >>
> >> Signed-off-by: Stephen
First off, video4linux-list is dead, you want linux-media (added to cc).
On Tue, Feb 15, 2011 at 06:27:29PM -0200, Fernando Laudares Camargos wrote:
> Hello,
>
> I have a Hauppauge WinTV-HVR-1150 (model 67201) pci tv tuner working
> (video and audio) under Ubuntu 10.10 and kernel 2.6.35-25. But t
On Tue, Feb 15, 2011 at 05:04:33PM -0500, Jarod Wilson wrote:
> First off, video4linux-list is dead, you want linux-media (added to cc).
>
> On Tue, Feb 15, 2011 at 06:27:29PM -0200, Fernando Laudares Camargos wrote:
> > Hello,
> >
> > I have a Hauppauge WinTV-HVR-1150 (model 67201) pci tv tuner
Hi Sergio
On Wed, 16 Feb 2011, Aguirre, Sergio wrote:
> Hi Guennadi,
>
> I have been working internally in a private 2.6.35.7 kernel with the TI OMAP4
> platform, and as I have a very simple camera support driver (It just enables a
> CSI2 Rx Interface), i decided to go for a soc-camera host impl
Hi Guennadi,
I have been working internally in a private 2.6.35.7 kernel with the TI OMAP4
platform, and as I have a very simple camera support driver (It just enables a
CSI2 Rx Interface), i decided to go for a soc-camera host implementation.
Now, I see that there is a set_bus_param callback fun
Andy Walls writes:
> On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote:
>> Having the RC_CORE config default to INPUT is almost equivalent to
>> saying "yes". Default to "no" instead.
>>
>> Signed-off-by: Stephen Wilson
>
> I don't particularly like this, if it discourages desktop distrib
Le 16/02/2011 09:10, Josu Lazkano a écrit :
> Hello, thanks for the reply.
>
> 2011/2/16 David Liontooth :
>> Does the card work? I see this sort of thing for a different card:
> Yes, it works, sometimes I have some warnings, but it works.
>
>> or51132: Waiting for firmware upload(dvb-fe-or51132-
> -Original Message-
> From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
> Sent: Wednesday, February 16, 2011 7:20 PM
> To: Laurent Pinchart
> Cc: Bhupesh SHARMA; linux-media@vger.kernel.org
> Subject: Re: soc-camera: Benefits of soc-camera interface over specific
> char drivers
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Wednesday, February 16, 2011 7:14 PM
> To: Bhupesh SHARMA
> Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org
> Subject: Re: soc-camera: Benefits of soc-camera interface over s
On Wed, 16 Feb 2011, Laurent Pinchart wrote:
> Hi Bhupesh,
>
> On Wednesday 16 February 2011 06:57:11 Bhupesh SHARMA wrote:
> > Hi Guennadi,
> >
> > As I mentioned in one of my previous mails , we are developing a Camera
> > Host and Sensor driver for our ST specific SoC and considering using th
Em 16-02-2011 10:55, Andy Walls escreveu:
> On Tue, 2011-02-15 at 17:48 -0200, Mauro Carvalho Chehab wrote:
>> Em 15-02-2011 15:25, Andy Walls escreveu:
>>> Mauro Carvalho Chehab wrote:
>>>
tuner-core has no business to do with digital TV. So, don't use
T_DIGITAL_TV on it, as it has no c
Hi Bhupesh,
On Wednesday 16 February 2011 06:57:11 Bhupesh SHARMA wrote:
> Hi Guennadi,
>
> As I mentioned in one of my previous mails , we are developing a Camera
> Host and Sensor driver for our ST specific SoC and considering using the
> soc-camera framework for the same. One of our open-sourc
On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote:
> Having the RC_CORE config default to INPUT is almost equivalent to
> saying "yes". Default to "no" instead.
>
> Signed-off-by: Stephen Wilson
I don't particularly like this, if it discourages desktop distributions
from building RC_CORE.
On Tue, 2011-02-15 at 17:48 -0200, Mauro Carvalho Chehab wrote:
> Em 15-02-2011 15:25, Andy Walls escreveu:
> > Mauro Carvalho Chehab wrote:
> >
> >> tuner-core has no business to do with digital TV. So, don't use
> >> T_DIGITAL_TV on it, as it has no code to distinguish between
> >> them, and no
On Mon, 14 Feb 2011, ac...@nvidia.com wrote:
> From: Andrew Chew
>
> This driver is for Omnivision's OV9740 sensor. This initial submission
> provides support for YUV422 output at 1280x720 (the sensor's native
> resolution), and 640x480 (cropping and scaling performed by the sensor's ISP).
>
>
Hi,
does currently soc-camera support using soc-camera host drivers with
non soc-camera sensors?
For instance, I would like to use soc-camera host driver
"mx2_camera.c" with non soc-camera sensor "tvp5150.c".
How much effort would it take to accomplish this goal?
Does it depends on conversion to v
Hi Laurent
Thanks for commenting.
On Wed, 16 Feb 2011, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Wednesday 16 February 2011 10:02:18 Guennadi Liakhovetski wrote:
> > On Wed, 16 Feb 2011, Hans Verkuil wrote:
> > > On Wednesday, February 16, 2011 08:42:51 Guennadi Liakhovetski wrote:
> > [sni
Hi Guennadi,
On Wednesday 16 February 2011 10:02:18 Guennadi Liakhovetski wrote:
> On Wed, 16 Feb 2011, Hans Verkuil wrote:
> > On Wednesday, February 16, 2011 08:42:51 Guennadi Liakhovetski wrote:
> [snip]
I definitely don't like solutions 1 and 2 either, so I'll only comment on 3.
> > > > 3. N
Hi Hans
Thanks for looking at it!
On Wed, 16 Feb 2011, Hans Verkuil wrote:
> Hi Guennadi,
>
> Here is my take on this:
>
> On Wednesday, February 16, 2011 08:42:51 Guennadi Liakhovetski wrote:
[snip]
> > > 3. Not liking either of the above, it seems we need yet a new API for
> > > this... Ho
Hi Guennadi,
Here is my take on this:
On Wednesday, February 16, 2011 08:42:51 Guennadi Liakhovetski wrote:
> Hi,
>
> On Tue, 15 Feb 2011, Qing Xu wrote:
>
> Please, don't top-post and use a proper quoting.
>
> > Hi,
> >
> > I have a question that why we must check "icf->vb_vidq.bufs[0]" in
>
Hello, thanks for the reply.
2011/2/16 David Liontooth :
> Does the card work? I see this sort of thing for a different card:
Yes, it works, sometimes I have some warnings, but it works.
> or51132: Waiting for firmware upload(dvb-fe-or51132-qam.fw)...
> or51132: Version: 10001334-1743 (133-4
34 matches
Mail list logo
