Hi,
I wonder if there is work in progress for a Linux driver supporting
the NXP SAA7154 Multistandard video decoder with comb filter, component
input and RGB output chip. The chip provides some improvements of the
SAA7119 chip which is (partially?) supported by the kernel right now.
(I'm not so s
On Wednesday 18 November 2009 08:24:13 Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
> > On Wednesday 18 November 2009 08:04:10 Mauro Carvalho Chehab wrote:
> >> Karicheri, Muralidharan escreveu:
> >>> Mauro,
> >>>
> >>> Thanks to your help, I could finish my documentation today.
> >>>
> >>> B
Hans Verkuil wrote:
> On Wednesday 18 November 2009 08:04:10 Mauro Carvalho Chehab wrote:
>> Karicheri, Muralidharan escreveu:
>>> Mauro,
>>>
>>> Thanks to your help, I could finish my documentation today.
>>>
>>> But I have another issue with the v4l2-apps.
>>>
>>> When I do make apps, it doesn't
On Wednesday 18 November 2009 08:04:10 Mauro Carvalho Chehab wrote:
> Karicheri, Muralidharan escreveu:
> > Mauro,
> >
> > Thanks to your help, I could finish my documentation today.
> >
> > But I have another issue with the v4l2-apps.
> >
> > When I do make apps, it doesn't seem to build. I get
On Wednesday 18 November 2009 01:38:45 Laurent Pinchart wrote:
> Replace the video_is_unregistered function by a video_is_registered
> function. The V4L2_FL_UNREGISTERED flag is replaced by a
> V4L2_FL_REGISTERED flag.
>
> This change makes the video_is_registered function return coherent
> result
On Wednesday 18 November 2009 01:38:42 Laurent Pinchart wrote:
> Many drivers access the device number (video_device::v4l2_devnode::num)
> in order to print the video device node name. Add and use a helper
> function to retrieve the video_device node name.
>
> Signed-off-by: Laurent Pinchart
Can
Karicheri, Muralidharan escreveu:
> Mauro,
>
> Thanks to your help, I could finish my documentation today.
>
> But I have another issue with the v4l2-apps.
>
> When I do make apps, it doesn't seem to build. I get the following error
> logs... Is this broken?
Well... no, it is not really broken,
On Wednesday 18 November 2009 01:38:48 Laurent Pinchart wrote:
> Fix all device drivers to use the video_drvdata function instead of
> maintaining a local list of minor to private data mappings. Call
> video_set_drvdata to register the driver private pointer when not
> already done.
>
> Where appl
On Wednesday 18 November 2009 07:42:41 Hans Verkuil wrote:
> On Wednesday 18 November 2009 07:21:30 Joonyoung Shim wrote:
> > The read and poll file operations of the si470x usb driver can be used
> > also equally on the si470x i2c driver, so they go to the common file.
> >
> > Signed-off-by: Joon
On Wednesday 18 November 2009 07:21:30 Joonyoung Shim wrote:
> The read and poll file operations of the si470x usb driver can be used
> also equally on the si470x i2c driver, so they go to the common file.
>
> Signed-off-by: Joonyoung Shim
Why on earth is the i2c driver registering a radio devic
Antonio Ospite wrote:
> pxa_camera init() is going to be removed.
>
> Signed-off-by: Antonio Ospite
> ---
> arch/arm/mach-pxa/em-x270.c |9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
Acked-by: Mike Rapoport
> diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa
On Wednesday 18 November 2009 01:38:43 Laurent Pinchart wrote:
> Fix all device drivers to use the new video_device_node_name function.
>
> Signed-off-by: Laurent Pinchart
>
Using video_device_node_name() is a great improvement! Excellent work!
One suggestion, though: I have to agree with the
This patch is to support RDS on si470x i2c driver. The routine of RDS
operation is almost same with thing of usb driver, but this uses RDS
interrupt.
Signed-off-by: Joonyoung Shim
---
drivers/media/radio/si470x/radio-si470x-i2c.c | 159 +++--
drivers/media/radio/si470x/radio
The read and poll file operations of the si470x usb driver can be used
also equally on the si470x i2c driver, so they go to the common file.
Signed-off-by: Joonyoung Shim
---
drivers/media/radio/si470x/radio-si470x-common.c | 98 ++
drivers/media/radio/si470x/radio-si470x-i
We should use the or operation to set value to the SYSCONFIG1 register
on si470x_start().
Signed-off-by: Joonyoung Shim
---
drivers/media/radio/si470x/radio-si470x-common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
On Nov 17, 2009, at 9:37 AM, Devin Heitmueller wrote:
> On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson wrote:
>> On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote:
>>
>>> On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky
>>> wrote:
> [ 812.465930] tda18271: performing RF tracking filt
Hi Lukáš,
Am Dienstag, den 17.11.2009, 15:06 +0100 schrieb Lukáš Karas:
> Hi Hermann
>
> At first, sorry for my late reaction, I havn't enough time for hacking...
>
> Thank you for detailed subscription. So, the main problem probably is LNB
> supply
> as I understand, yes?
>
> Please, try mod
Laurent,
> -Original Message-
> From: linux-media-ow...@vger.kernel.org
> [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of
> Laurent Pinchart
> Sent: Tuesday, November 17, 2009 6:39 PM
> To: linux-media@vger.kernel.org
> Cc: hverk...@xs4all.nl; mche...@infradead.org;
> sakari.ai
The video_device::minor field is used where it shouldn't, either to
- test for error conditions that can't happen anymore with the current
v4l-dvb core,
- store the value in a driver private field that isn't used anymore,
- check the video device type where video_device::vfl_type should be
use
Now that the video_device registration is tested using
video_is_registered(), drivers don't need to initialize the
video_device::minor field to -1 anymore.
Remove those unneeded assignments.
Signed-off-by: Laurent Pinchart
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/cx231xx/cx231xx-video.c
Instead of using the minor number in kernel log messages, use the device
node name as returned by the video_device_node_name() function. This
makes debug, informational and error messages easier to understand for
end users.
Signed-off-by: Laurent Pinchart
Index: v4l-dvb-mc-uvc/linux/drivers/stag
Fix the hdpvr driver to use the video_is_registered function instead of
video_is_unregistered.
Signed-off-by: Laurent Pinchart
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/hdpvr/hdpvr-video.c
===
--- v4l-dvb-mc-uvc.orig/linux/dri
Fix all device drivers to use the video_is_registered function instead
of checking video_device::minor.
Signed-off-by: Laurent Pinchart
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/bt8xx/bttv-driver.c
===
--- v4l-dvb-mc-uvc.orig/
Fix all device drivers to use the video_drvdata function instead of
maintaining a local list of minor to private data mappings. Call
video_set_drvdata to register the driver private pointer when not
already done.
Where applicable, the local list of mappings is completely removed when
it becomes un
Fix all device drivers to use the new video_device_node_name function.
Signed-off-by: Laurent Pinchart
Index: v4l-dvb-mc-uvc/linux/drivers/media/common/saa7146_fops.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/common/saa7146_fo
Replace the video_is_unregistered function by a video_is_registered
function. The V4L2_FL_UNREGISTERED flag is replaced by a
V4L2_FL_REGISTERED flag.
This change makes the video_is_registered function return coherent
results when called on an initialize but not yet registered video_device
instance
Signed-off-by: Laurent Pinchart
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/vivi.c
===
--- v4l-dvb-mc-uvc.orig/linux/drivers/media/video/vivi.c
+++ v4l-dvb-mc-uvc/linux/drivers/media/video/vivi.c
@@ -1376,9 +1376,6 @@ static int
Hi everybody,
this patch sets attemp to clean up the V4L core to remove the
video_device::minor and video_device::num references in most drivers.
There are two reasons for this. The first one is that drivers really
shouldn't care about those fields, especially the minor number. This
doesn't mean
Many drivers access the device number (video_device::v4l2_devnode::num)
in order to print the video device node name. Add and use a helper
function to retrieve the video_device node name.
Signed-off-by: Laurent Pinchart
Index: v4l-dvb-mc-uvc/linux/drivers/media/video/v4l2-dev.c
=
Mauro,
Thanks to your help, I could finish my documentation today.
But I have another issue with the v4l2-apps.
When I do make apps, it doesn't seem to build. I get the following error
logs... Is this broken?
Thanks.
Murali
make -C
/local/mkaricheri/davinci_git/video_timing/new_v4l2-dvb/v4l-d
Devin Heitmueller escreveu:
> On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab
> wrote:
>> I don't like the idea of creating structs grouping those parameters. While
>> for
>> certain devices this may mean a more direct approach, for others, this may
>> not make sense, due to the way their
From: Alexander Strakh
In driver ./drivers/media/video/usbvideo/konicawc.c in line 227:
227 usb_make_path(dev, cam->input_physname,
sizeof(cam->input_physname));
After this line we use strncat:
228 strncat(cam->input_physname, "/input0",
sizeof(cam->input_physname));
From: Alexander Strakh
In driver ./drivers/media/video/usbvideo/quickcam_messenger.c in line 91:
91 usb_make_path(dev, cam->input_physname,
sizeof(cam->input_physname));
After this line we use strncat:
92 strncat(cam->input_physname, "/input0",
sizeof(cam->input_physname)
From: Roel Kluin
Make id signed so we can't get an invalid pointer when we pass a negative
id.
Signed-off-by: Roel Kluin
Cc: Mauro Carvalho Chehab
Cc: Michael Krufky
Signed-off-by: Andrew Morton
---
drivers/media/dvb/siano/sms-cards.c |2 +-
drivers/media/dvb/siano/sms-cards.h |2 +
From: Julia Lawall
In quickcam_messenger.c, if the NULL test on uvd is needed, then the
dereference should be after the NULL test.
In vpif_display.c, std_info is initialized to the address of a structure
field. This seems unlikely to be NULL. If it could somehow be NULL, then
the assignment sh
From: Jonathan Corbet
The videobuf_queue_ops function vector is not declared constant, but
there's no need for the videobuf layer to ever change it. Make it const
so that videobuf users can make their operations const without warnings.
Signed-off-by: Jonathan Corbet
Cc: Mauro Carvalho Chehab
pxa_camera init() callback is sometimes abused to setup MFP for PXA CIF, or
even to request GPIOs to be used by the camera *sensor*. These initializations
can be performed statically in machine init functions.
The current semantics for this init() callback is ambiguous anyways, it is
invoked in px
pxa_camera init() is going to be removed.
Configure PXA CIF pins directly in machine init function.
Signed-off-by: Antonio Ospite
---
arch/arm/mach-pxa/pcm990-baseboard.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/
pxa_camera init() is going to be removed.
Signed-off-by: Antonio Ospite
---
arch/arm/mach-pxa/em-x270.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index aec7f42..f71f34c 100644
--- a/arch/arm/mach-pxa
Hi,
this series removes the init() callback from pxa_camera_platform_data, and
fixes its users to do initialization statically at machine init time.
Guennadi requested this change because there seems to be no use cases for
dynamic initialization. I also believe that the current semantics for this
On Tue, 17 Nov 2009 14:55:51 -0500, Devin Heitmueller wrote:
> On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab
> wrote:
> > I don't like the idea of creating structs grouping those parameters. While
> > for
> > certain devices this may mean a more direct approach, for others, this may
> >
Hi,
I've got a MSI VOX USB2.0 Video grabber (analog TV in, USB framegrabber out)
which is partially detected with Linux 2.6.31-11-generic (Ubuntu version).
The logs suggest that I E-mail the output of the logs to here, so
that's what I do.
The dmesg log says:
[ 6672.753915] em28xx: New device @ 4
On Mon, Nov 16, 2009 at 1:10 PM, Gordon Smith
wrote:
> Hello -
>
> I'm unable to find a working environment for saa7134 based RTD
> Technologies VFG7350 (two channel, no tuner) using vanilla kernel.
>
Please disregard, apparently this is a problem with busybox modprobe.
--
To unsubscribe from thi
Hello, people.
I did it! I looked at the log and modified the driver to support my
webcam. It's working!! I'm sending an image attached. :]
I'll clean up my code now, and submit a patch later. Help is
appreciated, because I don't have much experience contributing to
large projects...
This webcam
On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab
wrote:
> I don't like the idea of creating structs grouping those parameters. While for
> certain devices this may mean a more direct approach, for others, this may
> not make sense, due to the way their API's were implemented (for example,
>
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 Nov 17 19:00:03 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset: 1:e341e9e85af2
gcc version: gcc (
Manu Abraham escreveu:
> On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
> wrote:
>> Em Thu, 22 Oct 2009 21:13:30 +0200
>> Jean Delvare escreveu:
>>
>>> Hi folks,
>>>
>>> I am looking for details regarding the DVB frontend API. I've read
>>> linux-dvb-api-1.0.0.pdf, it roughly explains wh
On Wed, 18 Nov 2009, Tejun Heo wrote:
>
> I might have been too early with the 'easy' part but I definitely can
> give it a shot. What do you think about the scheduler notifier
> implementation? It seems we'll end up with three callbacks. It can
> either be three hlist_heads in the struct_tas
Karicheri, Muralidharan escreveu:
> Mauro,
>
> Thanks for your reply. I made progress after my email. My new file
> is being processed by Makefile now. I have some issues with some
> tags.
>
>> This probably means that videodev2.h has it defined, while you didn't have
>
> Do you mean videodev2.h
Mauro,
Thanks for your reply. I made progress after my email. My new file
is being processed by Makefile now. I have some issues with some
tags.
>
>This probably means that videodev2.h has it defined, while you didn't have
Do you mean videodev2.h.xml? I see there videodev2.h under linux/include.
Em Tue, 17 Nov 2009 10:00:07 -0600
"Karicheri, Muralidharan" escreveu:
> >Hi Mauro,
> >
> >Is there some instructions on adding new sections in the v4l2 documentation.
No, sorry. The documentation build is undocumented..
> >I had been struggling yesterday to add my documentation for video timin
Hello,
11/17/2009 09:05 PM, Andy Walls wrote:
>> Implementing strict ordering
>> shouldn't be too difficult but I can't help but feeling that such
>> assumption is abuse of implementation detail.
>
> Hmmm, does not the "queue" in workqueue mean "FIFO"?
I don't think it necessarily means strict
Hello,
I did correct work with circular polarisation (R=V)
Added call for setup_switch function for Monopoint LNBf, because somebody may
use it with diseqc switch and we also should set correct polarisation.
Signed-off-by: Anton Myachin
--- a/util/scan/scan.c 2009-11-16 19:29:41.0 +05
Hello, Linus.
11/18/2009 12:05 AM, Linus Torvalds wrote:
>> Do you think that usage is wide-spread? Implementing strict ordering
>> shouldn't be too difficult but I can't help but feeling that such
>> assumption is abuse of implementation detail.
>
> I think it would be good if it were more than
After compilation I get the following error
Error: no ID for contstraint linkend: v4l2-dv-enum-presets.
v4l2-dv-enum-presets is the new structure type added.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
>-
Hi Mauro,
Is there some instructions on adding new sections in the v4l2 documentation. I
had been struggling yesterday to add my documentation for video timing API. It
is easy to make minor documentation changes. But since I am adding new ioctls,
Looks like I need to create vidioc-.xml under Do
On Tue, 17 Nov 2009, Tejun Heo wrote:
>
> Do you think that usage is wide-spread? Implementing strict ordering
> shouldn't be too difficult but I can't help but feeling that such
> assumption is abuse of implementation detail.
I think it would be good if it were more than an implementation deta
Good Morning!
I could not find the AVerTVHD Duet A188 in the wiki, and searching the mailing
list did not produce much either.
Is the card now supported in Linux?
Thanks!
--
Mit freundlichen Grüßen / Best Regards
Andreas Schlehahn
--
To unsubscribe from this list: send the line "unsubscribe l
This patch is dependent on the patch
[PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
>From cda5b97d02784318d89a029a2fde97903610d2b2 Mon Sep 17 00:00:00 2001
From: Kishore Y
Date: Wed, 11 Nov 2009 19:22:46 +0530
Subject: [PATCH] V4L2: Allow rotation between stream off-
On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson wrote:
>> It happened at every tuning operation, and made mythfrontend unhappy
>> (unable to tune after the first channel). I disabled the check for
>> RF_CAL_OK which triggered the recalibration, and mythfrontend worked.
>
> Yeah, tuning is much quick
On Tue, Nov 17, 2009 at 9:15 AM, Jarod Wilson wrote:
> On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote:
>
>> On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky wrote:
[ 812.465930] tda18271: performing RF tracking filter calibration
[ 818.572446] tda18271: RF tracking filter
Hi Patrick,
A friend of mine got a Geniatech S870 ISDB-T card. According to him, this
device is based
on stk8090 chipset and wants to use it in Brazil.
The board has the following USB ID:
Bus 002 Device 002: ID 10b8:1fa0 DiBcom
I was wandering if the existing dib8000 driver will work
> Hi Bertrand,
>
> Please, always send patches c/c to:
> linux-me...@vger.kernel.org.
> This way, people can better review it.
>
> For more details, please read:
> http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
>
> There are some additional details on how patc
This patch is dependent on the patch
[PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
>From eb4302232f15e0af075604a9cf24fcaa9688e8a5 Mon Sep 17 00:00:00 2001
From: Kishore Y
Date: Tue, 10 Nov 2009 21:44:10 +0530
Subject: [PATCH] omap_vout: Change allocated buffer to on
On Nov 17, 2009, at 1:03 AM, Robert Cicconetti wrote:
> On Tue, Nov 17, 2009 at 12:55 AM, Michael Krufky wrote:
>>> [ 812.465930] tda18271: performing RF tracking filter calibration
>>> [ 818.572446] tda18271: RF tracking filter calibration complete
>>> [ 818.953946] tda18271: perform
This patch is dependent on the patch
[PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
>From 41b85f02f441771ace6c42ee08475ab7be04eb90 Mon Sep 17 00:00:00 2001
From: Kishore Y
Date: Wed, 11 Nov 2009 19:47:14 +0530
Subject: [PATCH] omap_vout: default colorspace for RGB565
Hi Bertrand,
Please, always send patches c/c to:
linux-me...@vger.kernel.org.
This way, people can better review it.
For more details, please read:
http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
There are some additional details on how patch submission work
On Tue, 2009-11-17 at 14:23 +0900, Tejun Heo wrote:
> Hello,
>
> 11/17/2009 09:47 AM, Andy Walls wrote:
> > An important property of the single threaded workqueue, upon which the
> > cx18 driver relies, is that work objects will be processed strictly in
> > the order in which they were queued. Th
Devin Heitmueller wrote:
> On Mon, Nov 16, 2009 at 10:01 AM, Sietse Achterop wrote:
>> Context:
>> debian/lenny with usb frame grabber:
>> Zoran Co. Personal Media Division (Nogatech) Hauppauge WinTV Pro
>> (PAL/SECAM)
>> This uses the usbvision driver.
>>
>> The problem is that while xawt
Hi,
Antonio Ospite wrote:
Hi,
gspca does not implement vidioc_enum_frameintervals yet, so even if a
camera can support multiple frame rates (or frame intervals) there is
still no way to enumerate them from userspace.
The following is just a quick and dirty implementation to show the
problem an
Hi,
gspca does not implement vidioc_enum_frameintervals yet, so even if a
camera can support multiple frame rates (or frame intervals) there is
still no way to enumerate them from userspace.
The following is just a quick and dirty implementation to show the
problem and to have something to base t
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the remaining
2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the
subsequent MPEG2-TS frame.
This patch was generated against v2.6.32-rc7, however i
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the remaining
2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the
subsequent MPEG2-TS frame.
This patch was generated against v2.6.32-rc7, however i
On Tue, 17 Nov 2009 07:47:40 +0100
Németh Márton wrote:
> From: Márton Németh
>
> Add check for the mandatory config, init, start and pkt_scan
> gspca subdriver operations.
>
> Signed-off-by: Márton Németh
> ---
> diff -r 182b5f8fa160 linux/drivers/media/video/gspca/gspca.c
> --- a/linux/driv
Hi Uwe
On Mon, 16 Nov 2009, Uwe Taeubert wrote:
> Hi Guennadi
> You will find the driver sources for our Sharp module in lz0p39ha.c and the
> initialization data in lz0p39ha_init.c. In lz0p35du_set_fmt_cap() you can see
> the resolution depending change of the divider. In our system we get corr
75 matches
Mail list logo
