On Tuesday 06 April 2010 00:12:48 Hans Verkuil wrote:
> On Monday 05 April 2010 23:47:10 Hans Verkuil wrote:
> > Hi all,
> >
> > The new control framework makes it very easy to expose controls in sysfs.
> > The way it is implemented now in the framework is that each device node
> > will get a 'con
On Tuesday 06 April 2010 00:58:54 Hans Verkuil wrote:
> On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
> > On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
> > > After looking at the proposed solution, I personally find the
> > > suggestion for a serialization flag to be quite
On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
> On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
> > After looking at the proposed solution, I personally find the
> > suggestion for a serialization flag to be quite ridiculous. As others
> > have mentioned, the mere presence of
Jean Delvare wrote:
> Hi Mauro,
>
> On Mon, 05 Apr 2010 15:26:32 -0300, Mauro Carvalho Chehab wrote:
>> Jean Delvare wrote:
>>> Now that i2c-core offers the possibility to provide custom probing
>>> function for I2C devices, let's make use of it.
>>>
>>> Signed-off-by: Jean Delvare
>>> ---
>>> I
Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
>> I have an RC-5 decoder in cx23885-input.c that isn't as clean as the NEC
>> protocol decoder I developed. The cx23885-input.c RC-5 decoder is not a
>> very explicit state machine however (it is a bit hack-ish).
>
> The state machine seems to be
Hi
Add support our new TV cards.
diff -r 4ee1e97ba6ad linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Apr 04 20:58:13
2010 -0400
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Apr 06 13:51:11
2010 +1000
@@ -5411,6 +5411
On Mon, 2010-04-05 at 11:25 +0200, Hans Verkuil wrote:
> On Monday 05 April 2010 04:58:02 Andy Walls wrote:
> > On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote:
> > 1. cx18 volume control: av_core subdev has a volume control (which the
> > bridge driver currently reports as it's volume contr
On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
> After looking at the proposed solution, I personally find the
> suggestion for a serialization flag to be quite ridiculous. As others
> have mentioned, the mere presence of the flag means that driver
> writers will gloss over any concurre
Hi Hans,
On Sunday 04 April 2010 17:41:51 Hans Verkuil wrote:
> Hi all,
>
> The support in drivers for the V4L2 control API is currently very chaotic.
> Few if any drivers support the API correctly. Especially the support for
> the new extended controls is very much hit and miss.
>
> Combine tha
This change adds support for Avermedia M733A. The original version for
linux 2.6.31 was sent to me from Avermedia, original author is unknown.
I ported it to current kernels, and modified for the two pci ids
supported (1461:4155, 1461:4255).
Signed-off-by: Herton Ronaldo Krzesinski
---
Documenta
On Monday 05 April 2010 23:47:10 Hans Verkuil wrote:
> Hi all,
>
> The new control framework makes it very easy to expose controls in sysfs.
> The way it is implemented now in the framework is that each device node
> will get a 'controls' subdirectory in sysfs. Below which are all the controls
> a
Hi all,
The new control framework makes it very easy to expose controls in sysfs.
The way it is implemented now in the framework is that each device node
will get a 'controls' subdirectory in sysfs. Below which are all the controls
associated with that device node.
So different device nodes can h
Hi Mauro,
On Mon, 05 Apr 2010 15:26:32 -0300, Mauro Carvalho Chehab wrote:
> Jean Delvare wrote:
> > Now that i2c-core offers the possibility to provide custom probing
> > function for I2C devices, let's make use of it.
> >
> > Signed-off-by: Jean Delvare
> > ---
> > I wasn't too sure where to p
On Fri, Apr 2, 2010 at 6:20 AM, David Härdeman wrote:
> On Thu, Apr 01, 2010 at 09:44:12PM -0400, Jon Smirl wrote:
>> On Thu, Apr 1, 2010 at 1:56 PM, Mauro Carvalho Chehab
>> wrote:
>> > This series of 15 patches improves support for IR, as discussed at the
>> > "What are the goals for the archit
Hi Mauro,
Hans Verkuil has provided the patches to support the V4L2 events on ivtv
(thanks, Hans!). Those patches are part of this pull request. The
documentation has been improved --- v4l2_fh is now clearly marked as
optional interface. Rebased, too.
Please pull.
The following changes since com
For some time I have been having problems with VDR seemingly loosing
control over one of the two tuners. It seems to be related to the
atscepg plugin. It happened quicker after VDR had timer recorded a show.
Removing the plugin seemed to stop it but also get no epg data. basicly,
which ever tun
On Monday 05 April 2010 20:11:13 Hans Verkuil wrote:
> Another option would be to set aside a range of IDs at the end of each control
> class that could be used as a 'remap' area.
>
> For example: the IDs for user class controls go from 0x98-0x98. Of
> which anything >= 0x981000 is a priva
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:Mon Apr 5 19:00:22 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 14544:4ee1e97ba6ad
git master:
Hello everyone,
I'm glad to announce Nokia will be hosting a V4L2 and Media controller
mini-summit in Helsinki, Finland from 14th to 16th June --- that's from
Monday to Wednesday. The event replaces the V4L2 Media Controller
mini-summit in Oslo in April / May proposed by Hans Verkuil. Just the
loc
There is a macro called dev_info that prints struct device specific
information. Having variables with the same name can be confusing and
prevents conversion of the macro to a function.
Rename the existing dev_info variables to something else in preparation
to converting the dev_info macro to a f
There is a macro called dev_info that prints struct device specific
information. Having variables with the same name can be confusing and
prevents conversion of the macro to a function.
Rename the existing dev_info variables to something else in preparation
to converting the dev_info macro to a f
Andy Walls wrote:
>>> 2. A common glitch filtering library function that can be used by all
>>> decoders, and that also can accept a decoder specified minimum
>>> acceptable pulse width.
>> Seems a nice improvement. I doubt I'll have time for handling it right now,
>> since there are still many thi
Hi Jean,
Jean Delvare wrote:
> Now that i2c-core offers the possibility to provide custom probing
> function for I2C devices, let's make use of it.
>
> Signed-off-by: Jean Delvare
> ---
> I wasn't too sure where to put the custom probe function: in each driver,
> in the ir-common module or in th
On Monday 05 April 2010 17:41:47 Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
> > On Monday 05 April 2010 04:58:02 Andy Walls wrote:
> >> On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote:
> >>> Hi all,
> >>>
> >>> The support in drivers for the V4L2 control API is currently very chaotic.
Hi Mauro
as agreed on IRC, please add the following
Acked-by: Sascha Hauer
(see also
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17845
)
when pulling from:
The following changes since commit a8f0df5fc2bc2e0aa0ead578bb93214915573efd:
Michael Hunold (1):
V
On Sun, Apr 4, 2010 at 10:58 PM, Andy Walls wrote:
> I think I have 2 cases where that is undesriable:
>
> 1. cx18 volume control: av_core subdev has a volume control (which the
> bridge driver currently reports as it's volume control) and the cs5435
> subdev has a volume control.
>
> I'd really n
Hans Verkuil wrote:
> On Monday 05 April 2010 04:58:02 Andy Walls wrote:
>> On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote:
>>> Hi all,
>>>
>>> The support in drivers for the V4L2 control API is currently very chaotic.
>>> Few if any drivers support the API correctly. Especially the support
Hi Patrick,
On Mon, Apr 5, 2010 at 5:21 PM, Patrick Boettcher
wrote:
> Hi Igor,
> hi Manu,
>
> I'm currently adding support for a device based on STV0903+STV6110 frontend
> combination.
>
> Early investigation have shown that for both devices there is a driver - now
> looking in more detail becau
Hi Igor,
hi Manu,
I'm currently adding support for a device based on STV0903+STV6110 frontend
combination.
Early investigation have shown that for both devices there is a driver - now
looking in more detail because I'm doing the actual coding, I'm finding out
that there is actually 2 drivers f
The problem with all the trees (http://linuxtv.org/hg/v4l-dvb/ and
http://linuxtv.org/hg/v4l-dvb/) are the used perl scripts to build the
makefile. They use "uname -r" to get the kernel version and they use
directories like "/lib/modules" as default.
Now, I try to cross compile the tree on my ub
On Monday 05 April 2010 04:58:02 Andy Walls wrote:
> On Sun, 2010-04-04 at 17:41 +0200, Hans Verkuil wrote:
> > Hi all,
> >
> > The support in drivers for the V4L2 control API is currently very chaotic.
> > Few if any drivers support the API correctly. Especially the support for the
> > new extend
Hi,
On 04/04/2010 08:47 PM, rath wrote:
Hi,
I have a 2.6.29 kernel for my embedded ARM system. I need an newer gspca
driver, so I downloaded the gspca driver from
http://linuxtv.org/hg/~hgoede/gspca/ an copied the content of the linux
folder to my 2.6.29 source tree and tried to cross compile i
Hi Andy,
On Sun, 04 Apr 2010 21:54:39 -0400, Andy Walls wrote:
> On Sun, 2010-04-04 at 16:14 +0200, Jean Delvare wrote:
> > Now that i2c-core offers the possibility to provide custom probing
> > function for I2C devices, let's make use of it.
> >
> > Signed-off-by: Jean Delvare
> > ---
> > I was
33 matches
Mail list logo
