headers
Brandon Philips | 1 Feb 2008 01:01
Gravatar

Re: videobuf lock problem

On 10:44 Thu 31 Jan 2008, Hans Verkuil wrote:
> > On Wed, 30 Jan 2008 11:52:40 +0100 (CET) "Hans Verkuil" <hverkuil <at> xs4all.nl> wrote:
> It's using kernelspace mmap. The driver is for the TI DaVinciHD
> System-on-a-Chip videoports. This driver is not in the kernel, but it is
> GPL. It's not really relevant to this problem. 

Why are you keeping the code out of the Kernel tree?  Can you send me a
URL to the driver source?

> For the time being I'll add the unlock/locks in our kernel.

Can you send the patch that you added to your kernel?

Thanks,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 1 comment |
headers
Brandon Philips | 1 Feb 2008 01:19
Gravatar

Re: gspca drivers

On 18:33 Thu 31 Jan 2008, James Klaas wrote:
> I was hoping to get my webcam working with the latest v4l-dvb sources.
>  After reading about on this list and elsewhere, I ran:
> 
> # make kernel-links
> 
> from my v4l-dvb directory in order to modify my current linux sources
> to use the v4l-dvb drivers.  Then I went to my gspca directory and ran
> the "gspca_build" script:
> 
> ./gspca_build
> 
>  REMOVE the old module if present
> Unknown symbol in module, or unknown parameter (see dmesg)
> 
>  PRINT COMPILATION MESSAGES if ERRORS look kgspca.err
> make -C /lib/modules/`uname -r`/build SUBDIRS=/usr/src/modules/gspca
> CC=cc modules
> make[1]: Entering directory `/usr/src/linux-source-2.6.22'
>   CC [M]  /usr/src/modules/gspca/gspca_core.o
> /usr/src/modules/gspca/gspca_core.c:2542: error: unknown field
> 'hardware' specified in initializer

Are you using the latest gspca driver?  The hardware field was removed
months ago.

Thanks,

	Brandon
(Continue reading)

Permalink | Reply | 6 comments |
headers
Hans Verkuil | 1 Feb 2008 08:01
Picon
Picon
Favicon

Re: videobuf lock problem

On Friday 01 February 2008 01:01:09 Brandon Philips wrote:
> On 10:44 Thu 31 Jan 2008, Hans Verkuil wrote:
> > > On Wed, 30 Jan 2008 11:52:40 +0100 (CET) "Hans Verkuil"
> > > <hverkuil <at> xs4all.nl> wrote:
> >
> > It's using kernelspace mmap. The driver is for the TI DaVinciHD
> > System-on-a-Chip videoports. This driver is not in the kernel, but
> > it is GPL. It's not really relevant to this problem.
>
> Why are you keeping the code out of the Kernel tree?  Can you send me
> a URL to the driver source?

It's not my code, it's from Texas Instruments. I don't actually know if 
there is a URL somewhere for the code. I am actually trying to get them 
to work with me to merge it into the kernel. It will definitely be an 
interesting driver to add.

> > For the time being I'll add the unlock/locks in our kernel.
>
> Can you send the patch that you added to your kernel?

It's trivial:

--- videobuf-core.c.org 2008-02-01 07:58:10.000000000 +0100
+++ videobuf-core.c     2008-02-01 07:58:34.000000000 +0100
 <at>  <at>  -606,7 +606,9  <at>  <at> 
                goto done;
        }
        buf = list_entry(q->stream.next, struct videobuf_buffer, 
stream);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul | 1 Feb 2008 09:34

RE: Yuan MPC788 and MPC583

> -----Original Message-----
> From: hermann pitton [mailto:hermann-pitton <at> arcor.de] 
> Sent: 31 January 2008 22:37
> To: Paul
> Cc: Markus Rechberger; video4linux-list <at> redhat.com
> Subject: RE: Yuan MPC788 and MPC583
> 
> Am Donnerstag, den 31.01.2008, 15:13 +0000 schrieb Paul:
> > > > Hi,
> > > >
> > > > The remaining bug is definitely a mplayer/xawtv issue.
> > > > mplayer test.avi (which doesn't touch the V4L dev files)
> > > breaks xawtv.
> > > >
> > > > However, mplayer tv:// works (but the picture is purple)
> > > after showing
> > > > digital TV.
> > > > I guess mplayer must leave the Xv system in a state that
> > > xawtv can't
> > > > handle.
> > > 
> > > try mplayer -vo x11 this won't use the xv output and it takes 
> > > significantly more CPU power.
> > > If you see the same issues there some chips might be 
> misconfigured.
> > > 
> > > Markus
> > > >
> > > > Anyway, the driver works for both Yuan cards.
> > > > The patch for the main V4L repository (b0815101889d) is at
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guennadi Liakhovetski | 1 Feb 2008 11:57
Picon
Favicon

Re: [PATCH 3/3] Add support for PCA953[4-8] I2C GPIO extenders to the pca953x driver

On Thu, 31 Jan 2008, David Brownell wrote:

> Compare to this cleaned up version of your patch 3/3 ... which is a bit
> smaller since it removes reg_shift.  (Tell me I didn't break anything!)

You didn't:-) It still works.

Thanks
Guennadi
---
Guennadi Liakhovetski

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 0 comments |
headers
matti | 1 Feb 2008 15:44
Picon
Gravatar

Grabbee X (Terratec Cinergy 200 USB)

I got the grabbee X usb 2.0 video grabber to work on ubuntu 7.10 by 
using the stock kernel e28xx module then using usbreplay to load up a 
usbsnoop processed logfile.
I can view video in mplayer but the image is half-wide and twice-high.
Any hints how to fix it?
How can I share my positive experience so far?
Would someone like the 88kB analyzed log?

Matti Picus

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 1 comment |
headers
Oliver Neukum | 1 Feb 2008 15:52

autosuspend for si470x

Hi,

this should implement autosuspend. Could you please test it?
It's against 1.0.6.

	Regards
		Oliver

----

commit 5929871d540c96a05df7c7d3cbaeff4524ffe8e2
Author: Oliver Neukum <oneukum@...>
Date:   Fri Feb 1 15:48:09 2008 +0100

    autosuspend for the si470x driver

diff --git a/drivers/media/radio/radio-si470x.c b/drivers/media/radio/radio-si470x.c
index bb29e44..251e081 100644
--- a/drivers/media/radio/radio-si470x.c
+++ b/drivers/media/radio/radio-si470x.c
 <at>  <at>  -416,6 +416,7  <at>  <at>  MODULE_PARM_DESC(rds_poll_time, "RDS poll time (ms): *40*");
 struct si470x_device {
 	/* reference to USB and video device */
 	struct usb_device *usbdev;
+	struct usb_interface *intf;
 	struct video_device *videodev;

 	/* driver management */
 <at>  <at>  -763,9 +764,15  <at>  <at>  static int si470x_stop(struct si470x_device *radio)
  */
(Continue reading)

Permalink | Reply | 6 comments |
headers
Trent Piepho | 1 Feb 2008 19:51
Picon

Re: bttv driver bug: VIDIOC_ENUMSTD returns wrong NTSC value

On Mon, 28 Jan 2008, Daniel [iso-8859-1] Glöckner wrote:
> On Sun, Jan 27, 2008 at 10:37:34AM -0800, Trent Piepho wrote:
> > The bt848 chip does support NTSC-JP, I guess no one has bothered to add it.
>
> It has already been added to bttv as a separate standard. It can't be merged
> with plain NTSC because it needs a different value for the IFORM register.

That's strange, the original poster said:

> > bttv reports NTSC as 36864  0x9000  1001000000000000
> > ( V4L2_STD_NTSC_M | V4L2_STD_NTSC_M_KR )

He's saying bttv does _not_ report NTSC-JP as a supported standard.  Yet
you're right, NTSC-JP is listed along with all the other standards in the
bttv source.

I don't have time to test this.  Maybe the original poster was mistaken, or
maybe there is a bug in the code that provides the bitmask?

Having NTSC-M-JP be it's own standard is the correct thing to do, IMHO.
It's having NTSC-M-KR as another standard that's wrong, since there is no
difference in the video signal.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 1 comment |
headers
Tobias Lorenz | 1 Feb 2008 20:23
Picon
Gravatar

Re: autosuspend for si470x

Hi Oliver,

> +	mutex_lock(&radio->lock);
> +	mutex_unlock(&radio->lock);

You are adding a lot of mutexes around si470x rds register accesses, which I don't think is necessary.
Parallel accesses to the registers will never harm anything or cannnot cause any data corruption.
I used radio->lock just for RDS buffer modifications, so multiple read/write attempts do not interfere.

But anyway, I applied anything else.
For testing it, I finally have to setup a kernel and environment, that support suspend and resume.
I try to give a feedback soon.

Bye,
  Toby
Permalink | Reply | 2 comments |
headers
Trent Piepho | 1 Feb 2008 20:41
Picon

Re: [RFC PATCH 6/8] Add V4L2_CID_AUTOEXPOSURE control

On Thu, 31 Jan 2008, Guennadi Liakhovetski wrote:
> On Thu, 24 Jan 2008, Trent Piepho wrote:
>
> > On Wed, 23 Jan 2008, Guennadi Liakhovetski wrote:
> > > The MT9V022 camera has hardware AEC support, that can be switched on and
> > > off in software. MT9M001 emulates Autoexposure control in software. Add a
> > > V4L2 control, similar to already present Autogain.
> >
> > If you're going to add a new-non private control, there should be
> > documentation.  There are already several drivers with auto-exposure
> > controls.
>
> Ok, I looked harder yet... First, to documentation - I haven't found
> anything under Documentation/video4linux on controls, nor in the
> cideodevice2.h. Where should it be documented?

It's not in the kernel tree yet, but should be there soon.  See this thread
about Brandon's changes for UVC controls:
http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2008-January/006206.html

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 1 comment |

Gmane