Re: Creating a V4L driver for a USB camera

2009-06-03 Thread Erik de Castro Lopo
On Thu, 4 Jun 2009 14:02:37 +1000
Theodore Kilgore  wrote:

> Well, if you are interested in using the camera as a still camera, then 
> probably you ought also to send an inquiry over to
> 
> gphoto-de...@lists.sourceforge.net
> 
> because that is, basically, where the still camera support is done, not 
> here.

Well our current camera has a V4L based driver so we'd like to stick
to that :-).

> So the reason for these examples is, it is this kind of information which 
> one must use to judge the situation, and it is this kind of information 
> which one would have to provide in order to begin to get definitive 
> answers. This, in fact, is where one must start.

Ok, to the lsusb -v info:

Bus 001 Device 011: ID 0547:8031 Anchor Chips, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0547 Anchor Chips, Inc.
  idProduct  0x8031 
  bcdDevice0.00
  iManufacturer   1 
  iProduct2 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0004  1x 4 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0


The "Vendor Specific Class" above suggests that this camera does not
behave like a proper USV video or still camera, but rather uses its
own protocol (just like the camera we are replacing).

I have managed to convince the manufactuer of the fact that its a
good idea to provide some information and/or windows source code,
but as yet I can't predict how good that information will be.

Erik
-- 
===
erik de castro lopo
senior design engineer

bCODE
level 2, 2a glen street
milsons point
sydney nsw 2061
australia

tel +61 (0)2 9954 4411
fax +61 (0)2 9954 4422
www.bcode.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH]V4L:some v4l drivers have error for video_register_device

2009-06-03 Thread figo.zhang
The function video_register_device() will call the 
video_register_device_index().
In this function, firtly it will do some argments check , if failed,it will 
return a 
negative number such as -EINVAL, and then do cdev_alloc() and 
device_register(), if
success return zero. so video_register_device_index() canot return a a positive 
number.

for example, see the drivers/media/video/stk-webcam.c (line 1325):

err = video_register_device(&dev->vdev, VFL_TYPE_GRABBER, -1);
if (err)
STK_ERROR("v4l registration failed\n");
else
STK_INFO("Syntek USB2.0 Camera is now controlling video device"
" /dev/video%d\n", dev->vdev.num);

in my opinion, it will be cleaner to do something like this:

err = video_register_device(&dev->vdev, VFL_TYPE_GRABBER, -1);
if (err != 0)
STK_ERROR("v4l registration failed\n");
else
STK_INFO("Syntek USB2.0 Camera is now controlling video device"
" /dev/video%d\n", dev->vdev.num);



Figo.zhang


On Wed, 2009-05-27 at 11:25 +0800, Figo.zhang wrote:
> For video_register_device(), it return zero means register success.It would 
> be return zero
> or a negative number (on failure),it would not return a positive number.so it 
> have better to
> use this to check err:
>   int err = video_register_device(vdev, VFL_TYPE_GRABBER, -1);
>   if (err != 0) {
>   /*err code*/
>   }
> 
>  
> Signed-off-by: Figo.zhang 
> --- 
>  Documentation/video4linux/v4l2-framework.txt |2 +-
>  drivers/media/radio/radio-maestro.c  |2 +-
>  drivers/media/radio/radio-si470x.c   |2 +-
>  drivers/media/video/cafe_ccic.c  |2 +-
>  drivers/media/video/cx231xx/cx231xx-video.c  |2 +-
>  drivers/media/video/em28xx/em28xx-video.c|2 +-
>  drivers/media/video/et61x251/et61x251_core.c |2 +-
>  drivers/media/video/hdpvr/hdpvr-video.c  |2 +-
>  drivers/media/video/ivtv/ivtv-streams.c  |2 +-
>  drivers/media/video/sn9c102/sn9c102_core.c   |2 +-
>  drivers/media/video/stk-webcam.c |2 +-
>  drivers/media/video/w9968cf.c|2 +-
>  drivers/media/video/zc0301/zc0301_core.c |2 +-
>  drivers/media/video/zr364xx.c|2 +-
>  sound/i2c/other/tea575x-tuner.c  |2 +-
>  15 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/video4linux/v4l2-framework.txt 
> b/Documentation/video4linux/v4l2-framework.txt
> index 854808b..250232a 100644
> --- a/Documentation/video4linux/v4l2-framework.txt
> +++ b/Documentation/video4linux/v4l2-framework.txt
> @@ -447,7 +447,7 @@ Next you register the video device: this will create the 
> character device
>  for you.
>  
>   err = video_register_device(vdev, VFL_TYPE_GRABBER, -1);
> - if (err) {
> + if (err != 0) {
>   video_device_release(vdev); /* or kfree(my_vdev); */
>   return err;
>   }
> diff --git a/drivers/media/radio/radio-maestro.c 
> b/drivers/media/radio/radio-maestro.c
> index 64d737c..b5e93c2 100644
> --- a/drivers/media/radio/radio-maestro.c
> +++ b/drivers/media/radio/radio-maestro.c
> @@ -379,7 +379,7 @@ static int __devinit maestro_probe(struct pci_dev *pdev,
>   video_set_drvdata(&dev->vdev, dev);
>  
>   retval = video_register_device(&dev->vdev, VFL_TYPE_RADIO, radio_nr);
> - if (retval) {
> + if (retval != 0) {
>   v4l2_err(v4l2_dev, "can't register video device!\n");
>   goto errfr1;
>   }
> diff --git a/drivers/media/radio/radio-si470x.c 
> b/drivers/media/radio/radio-si470x.c
> index bd945d0..edb520a 100644
> --- a/drivers/media/radio/radio-si470x.c
> +++ b/drivers/media/radio/radio-si470x.c
> @@ -1740,7 +1740,7 @@ static int si470x_usb_driver_probe(struct usb_interface 
> *intf,
>  
>   /* register video device */
>   retval = video_register_device(radio->videodev, VFL_TYPE_RADIO, 
> radio_nr);
> - if (retval) {
> + if (retval != 0) {
>   printk(KERN_WARNING DRIVER_NAME
>   ": Could not register video device\n");
>   goto err_all;
> diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c
> index c4d181d..fd93698 100644
> --- a/drivers/media/video/cafe_ccic.c
> +++ b/drivers/media/video/cafe_ccic.c
> @@ -1974,7 +1974,7 @@ static int cafe_pci_probe(struct pci_dev *pdev,
>  /*   cam->vdev.debug = V4L2_DEBUG_IOCTL_ARG;*/
>   cam->vdev.v4l2_dev = &cam->v4l2_dev;
>   ret = video_register_device(&cam->vdev, VFL_TYPE_GRABBER, -1);
> - if (ret)
> + if (ret != 0)
>   goto out_smbus;
>   video_set_drvdata(&cam->vdev, cam);
>  
> diff --git a/drivers/media/video/cx231xx/cx231xx-video.c 
> b/drivers/media/video/cx231xx/cx231xx-video.c
> index a23ae73..14e5008 100644
> --- a/drivers/media/video/cx231xx/cx231xx-video.c
> +++ b/drivers/media/video/cx231

Re: Creating a V4L driver for a USB camera

2009-06-03 Thread Theodore Kilgore



On Thu, 4 Jun 2009, Erik de Castro Lopo wrote:


On Thu, 4 Jun 2009 11:28:38 +1000
Theodore Kilgore  wrote:


If this is the case, then it ought not to be terribly difficult to write a
basic driver. If you wanted still camera support, with which I have a bit
more experience than with streaming support,


Yep, only interested in still images ATM.


Of course, I said above "basic" driver. That does not include things like
color balance, contrast, or brightness controls. Such would probably take
a little bit longer.


Als need contol over things like this. We have pretty good control
over the lighting the camera works under so we tweak contrast/brightness/
whatever in the camera to provide the bext possible image to the image
processing.


Well, if you are interested in using the camera as a still camera, then 
probably you ought also to send an inquiry over to


gphoto-de...@lists.sourceforge.net

because that is, basically, where the still camera support is done, not 
here. At the same time, though, you have gotten some responses here from 
some pretty clever folks who have volunteered to help. So if I were you I 
would certainly not want to drop those offers into the sea.


The reason for the distinction between V4L  type of things and Gphoto type 
of things is the old and time-honored rigid distinction between 
kernelspace and userspace in Linux. Basically, the idea is that a video 
device or a streaming camera (webcam) requires a kernel device to be 
created, usually named /dev/videoX where X is a number, and if you have 
just one such device hooked up then X=0, of course. But userspace 
applications do not require that, and a device can be communicated with 
through libusb, for example, or even can be communicated with directly.


So, Gphoto is a project which supports still cameras, using libusb as its 
infrastructure. It was conceived and intended to support proprietary 
cameras, which do not use any standard communication protocol. More 
recently, it has also evolved into supporting the cameras which use the 
PTP protocol. If your camera is proprietary or uses PTP and you want to 
get still photos off it, then Gphoto is the way to go. If it can also 
stream and you want _that_ supported, then here is the right place.


Many still cameras, though, are not using a proprietary or a PTP 
communication protocol, but instead are using Mass Storage, usually with 
protocol Transparent SCSI, and with Bulk Transport. Such still cameras do 
not in general need any particular driver software at all. Rather, one 
gets access to such a camera by mounting it. For, as a USB device it acts 
just like any USB external hard drive or flash drive and the photos on it 
are files ready to download.


Unfortunately, if you have mentioned what are the characteristics of your 
camera as a USB device, then that mention did not register on me. What 
might really help in getting started (whichever way this is going) is the 
full output of lsusb. Here, for example, is part of the output from a 
camera, from lsusb -v:


Bus 005 Device 002: ID 093a:010f Pixart Imaging, Inc. Argus 
DC-1610/DC-1620/Emprex PCD3600/Philips P44417B keychain camera/Precision 
Mini,Model HA513A/Vivitar Vivicam 55

Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass   255 Vendor Specific Subclass
  bDeviceProtocol   255 Vendor Specific Protocol
  bMaxPacketSize0 8
  idVendor   0x093a Pixart Imaging, Inc.
  idProduct  0x010f Argus DC-1610/DC-1620/Emprex PCD3600/Philips 
P44417B keychain camera/Precision Mini,Model HA513A/Vivitar Vivicam 55

  bcdDevice1.00
  iManufacturer   0
  iProduct2 USB Dual-mode Camera

Note in particular these lines

  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass   255 Vendor Specific Subclass
  bDeviceProtocol   255 Vendor Specific Protocol

which tell that, whatever else, this camera needs to have a driver 
provided or else one can do nothing at all with it. It does have a 
stillcam driver, in fact, in libgphoto2. A webcam driver for it is under 
development, too, over here, since the camera is "Dual-mode" and can be 
used both as a still camera and as a webcam.


Now, here is another camera:

Bus 005 Device 003: ID 2770:915d NHJ, Ltd Cyberpix S-210S / Little Tikes 
My Real Digital Camera

Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x2770 NHJ, Ltd
  idProduct  0x915d Cyberpix S-210S / Little Tikes My Real Digital 
Camera


So, the note says "Defined at Interface level" so we can scroll down a bit 
and we see


  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI

Re: Creating a V4L driver for a USB camera

2009-06-03 Thread Erik de Castro Lopo
On Thu, 4 Jun 2009 11:28:38 +1000
Theodore Kilgore  wrote:

> If this is the case, then it ought not to be terribly difficult to write a 
> basic driver. If you wanted still camera support, with which I have a bit 
> more experience than with streaming support,

Yep, only interested in still images ATM.

> Of course, I said above "basic" driver. That does not include things like 
> color balance, contrast, or brightness controls. Such would probably take 
> a little bit longer.

Als need contol over things like this. We have pretty good control
over the lighting the camera works under so we tweak contrast/brightness/
whatever in the camera to provide the bext possible image to the image
processing.

Cheers,
Erik
-- 
===
erik de castro lopo
senior design engineer

bCODE
level 2, 2a glen street
milsons point
sydney nsw 2061
australia

tel +61 (0)2 9954 4411
fax +61 (0)2 9954 4422
www.bcode.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Creating a V4L driver for a USB camera

2009-06-03 Thread Theodore Kilgore



On Thu, 4 Jun 2009, Erik de Castro Lopo wrote:


On Wed, 3 Jun 2009 16:18:33 +1000
Erik Andrén  wrote:


Do you have any datasheet available on what usb bridge / sensor that is used?


The USB device itself comes up as :

   Bus 001 Device 011: ID 0547:8031 Anchor Chips, Inc

The sensor is a Micron MT9T001P12STC and I have the data sheet for it.

I've asked the manufacturer for source code to the windows driver
and docs/source/whatever for the USB interface.


If the chipsets are undocumented and some proprietary image
compression technique is used, the time to reverse-engineer them can
be quite lengthy.


I happen to know that the sensor/camera (via the windows driver) can
provide raw bayer data which is what I'm after (our application is
machine vision and bayer works best).

Cheers,
Erik


If this is the case, then it ought not to be terribly difficult to write a 
basic driver. If you wanted still camera support, with which I have a bit 
more experience than with streaming support, I would say it would take me 
about a week or so. The real obstacle is proprietary data compression 
which is usually totally undocumented, as others have already said.


Of course, I said above "basic" driver. That does not include things like 
color balance, contrast, or brightness controls. Such would probably take 
a little bit longer.


From what I read here, I think you will have good luck if you follow 

through with this project.


Theodore Kilgore

(Greetings from the monthly meeting of the East Alabama LUG)

Re: Fwd: driver trident tm5600

2009-06-03 Thread Daniel Santibáñez
hello again!

now when i tried to compile, appear :

v4l/tm6000-dvb.c:240: error: unknown field 'video_dev' specified in
initializer
v4l/tm6000-dvb.c:240: warning: initialization makes integer from
pointer without a cast

after i tried changing video_dev by videodev, but still happend

>>
>> Daniel Santibáńez wrote:
>>
>>
>> Hello.!!
>> i tried to install a driver for this usb device, long time
>> i try
>> to finish but, when i probe the driver error by erro
>> appear,and
>>  this don't work aparently.. when i run modprobe this say:
>>
>> tm6000-alsa: Unknow symbol tm6000_get_reg
>> tm6000-alsa: Unknow symbol tm6000_set_reg
>>
>> what i have to do.? could you help me.?? exist a how to?
>> actualy? thanks.
>>
>>
>> I currently use:
>>
>> Kernel: Linux 2.6.28-12-generic (i686)
>> Compiled: #43-Ubuntu SMP Fri May 1 19:27:06 UTC 2009
>> C Library: GNU C Library version 2.9 (stable)
>> Distribution: Ubuntu 9.04
>> Desktop Environment: GNOME 2.26
>>
>> Hi Daniel,
>>
>> I suggest you post to the linux-media mailing list in future. That
>> way the mailing lists acts as a knowledge base for other people
>> with
>> the same problem. See http://www.linuxtv.org/lists.php for
>> details.
>> I used BCC in case you don't want your e-mail address on a
>> public site.
>>
>> Did you pull from the http://linuxtv.org/hg/~mchehab/tm6010
>>  repository with last
>> change dated 28 Nov 2008? That code compiles on Ubuntu 8.10 but
>> not
>> on Ubuntu 9.04. You could try the following (untested) patch to
>> resolve this.
>>
>> I only have experience trying to get the Hauppauge HVR-900H
>> working
>> with this driver. It does not currently work for me with New
>> Zealand
>> television.
>>
>> Kevin
>>
>> diff -r ca10a33f275b linux/drivers/media/dvb/dvb-core/dvbdev.c
>> --- a/linux/drivers/media/dvb/dvb-core/dvbdev.c Sun Apr 05
>> 10:57:01
>> 2009 +1200
>> +++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c Wed Jun 03
>> 20:45:03
>> 2009 +1200
>> @@ -261,7 +261,7 @@
>>
>>  #if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 27)
>>clsdev = device_create(dvb_class, adap->device,
>> -  MKDEV(DVB_MAJOR,
>> nums2minor(adap->num, type, id)),
>> +  MKDEV(DVB_MAJOR, minor),
>>   NULL, "dvb%d.%s%d", adap->num,
>> dnames[type], id);
>>  #elif LINUX_VERSION_CODE == KERNEL_VERSION(2, 6, 27)
>>clsdev = device_create_drvdata(dvb_class, adap->device,
>> diff -r ca10a33f275b
>> linux/drivers/media/video/tm6000/tm6000-alsa.c
>> --- a/linux/drivers/media/video/tm6000/tm6000-alsa.cSun Apr 05
>> 10:57:01 2009 +1200
>> +++ b/linux/drivers/media/video/tm6000/tm6000-alsa.cWed Jun 03
>> 20:45:03 2009 +1200
>> @@ -17,7 +17,7 @@
>>  #include 
>>
>>  #include 
>> -#include 
>> +/*#include */
>>  #include 
>>  #include 
>>  #include 
>> diff -r ca10a33f275b linux/drivers/media/video/tm6000/tm6000-i2c.c
>> --- a/linux/drivers/media/video/tm6000/tm6000-i2c.c Sun Apr 05
>> 10:57:01 2009 +1200
>> +++ b/linux/drivers/media/video/tm6000/tm6000-i2c.c Wed Jun 03
>> 20:45:03 2009 +1200
>> @@ -258,7 +258,7 @@
>>
>>  /* Tuner callback to provide the proper gpio changes needed for
>> xc2028 */
>>
>> -static int tm6000_tuner_callback(void *ptr, int command, int arg)
>> +static int tm6000_tuner_callback(void *ptr, int component, int
>> command, int arg)
>>  {
>>int rc=0;
>>struct tm6000_core *dev = ptr;
>>
>>

-- 
Daniel Santibáñez
Ð.§.

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Creating a V4L driver for a USB camera

2009-06-03 Thread Erik de Castro Lopo
On Wed, 3 Jun 2009 16:18:33 +1000
Erik Andrén  wrote:

> Do you have any datasheet available on what usb bridge / sensor that is used?

The USB device itself comes up as :

Bus 001 Device 011: ID 0547:8031 Anchor Chips, Inc

The sensor is a Micron MT9T001P12STC and I have the data sheet for it.

I've asked the manufacturer for source code to the windows driver
and docs/source/whatever for the USB interface.

> If the chipsets are undocumented and some proprietary image
> compression technique is used, the time to reverse-engineer them can
> be quite lengthy.

I happen to know that the sensor/camera (via the windows driver) can
provide raw bayer data which is what I'm after (our application is
machine vision and bayer works best).

Cheers,
Erik
-- 
===
erik de castro lopo
senior design engineer

bCODE
level 2, 2a glen street
milsons point
sydney nsw 2061
australia

tel +61 (0)2 9954 4411
fax +61 (0)2 9954 4422
www.bcode.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: Sound capture with Osprey 230

2009-06-03 Thread Sverker Abrahamsson
Hi Trent

> -Original Message-
> From: Trent Piepho [mailto:xy...@speakeasy.org]
> Sent: den 14 maj 2009 22:37
> To: Sverker Abrahamsson
> Cc: 'Jose Diaz'; linux-media@vger.kernel.org
> Subject: Re: Sound capture with Osprey 230
> 
> On Mon, 11 May 2009, Sverker Abrahamsson wrote:
> > Hi all,
> > I've been using Osprey 230 cards for AV capture for several years,
> earlier
> > with a modified version of Viewcast's driver but it was never very
> stable.
> > When doing a new setup I therefore wanted to get the Alsa driver to
> work. I
> > found that there were two trees in the repository in regards to these
> cards,
> > http://linuxtv.org/hg/~mchehab/osprey and
> http://linuxtv.org/hg/~tap/osprey.
> > It seems that mchehab tree is the patches that Viewcast submitted
> which does
> > not address the necessary changes for ALSA driver while tap tree does
> but
> > for Osprey 440 and older kernels.
> 
> Mauro's tree with viewcast's patches is even older than mine, wrt
> kernel
> support.
> 
> > I've therefore ported the changes from tap to the main tree and added
> > support for detecting Osprey 210/220/230 plus a minor fix to support
> > specifying digital_rate as module parameter. It might also work for
> Osprey
> > 240 (which is PCI-e variant of 230) but I don't have any such card so
> I
> > haven't been able to test.
> 
> Instead of modifying my patch, it would be better if you could provide
> a
> patch on top of it that adds support for your new card.

The reason why I didn't do that was your tree is almost two years old and
didn't compile on a 2.6.27 kernel. It was far less work to take the
significant parts of your driver and port them over to the main tree.

> > The only question mark I have is that the current implementation use
> the
> > depreciated interfaces from bttv-if.c to find which bttv driver
> corresponds
> > to this audio driver and adds a function to get the bttv core. It is
> > suggested to use the routines in bttv-gpio.c instead but I don't find
> an
> > obvious replacement for bttv_get_pcidev nor how to get bttv_core.
> 
> The interface in bttv-if.c has been "deprecated" for years now, yet no
> one
> has come up with something to replace it with.  I think Gerd was
> getting a
> bit ahead of himself when he declared it obsolete.

The function I use is the one you added to get a reference to the bttv
structure. For gpio operations it would be possible to use the new
interface, only that those functions aren't exported so that other drivers
can call them.
 
> > I see two alternatives:
> > 1. Implement snd-87x module as a subdevice to bttv. Is this correct
> as the
> > video and audio devices are two separate pci devices?
> 
> The audio and video devices aren't just separate pci devices, they are
> also
> two unrelated devices to the linux device model.  The driver model
> doesn't
> have any means to call one a subdevice of the other.
> 
> Somehow, there needs to be a means for the audio driver to find the
> video
> driver so that it can get access to the gpio lines and the i2c bus.
> But,
> this is only necessary for the osprey cards.  The audio driver for
> other
> cards doesn't need gpios or i2c.  So, it would be nice to allow just
> the
> audio driver with no video to be loaded.

While I partly agree with you that it would be a nicer solution to be able
to use the audio driver separately I don't see the need in reality. The
video chip is there, to have it's driver loaded to be able to use the audio
capture is a small drawback, if any. Only if someone needed that
functionality badly enough to do the work to implement it would happen, but
it would require substantial rewrite of the base driver with the potential
to create problems for other cards.
 
> The problem with my implementation is that after the audio bttv driver
> gets
> a pointer to the video driver's core, the video driver could go away
> and
> leave the audio driver with a dangling pointer.  That's one of the
> reasons
> I haven't merged my osprey code.  The other is that I have cards with
> bttv
> audio to test with.
 
No, the video driver can't be unloaded without the audio driver have been
unloaded before as the latter is depending on the former

/Sverker
 
 

__ Information fran ESET NOD32 Antivirus, version av
virussignaturdatabas 4127 (20090603) __

Meddelandet har kontrollerats av ESET NOD32 Antivirus.

http://www.esetscandinavia.com
 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PULL] generic image bounds setting and alignment function

2009-06-03 Thread Guennadi Liakhovetski
On Mon, 1 Jun 2009, Robert Jarzmik wrote:

> Trent Piepho  writes:
> 
> > Mauro,
> >
> > Please pull from http://linuxtv.org/hg/~tap/v4l-dvb
> >
> > This series adds a function for bounding and alignment image sizes and
> > modifies a number of drivers to use it.  It came up when the pxa patches to
> > deal with the alignment issues for that driver were posted.  I haven't
> > tested these patches for pxa.
> 
> Hi Trent,
> 
> I didn't see the review of that serie, I'm curious what others said.

I strongly agree with Robert. Can we PLEASE have this series posted to the 
list for a review first? I don't think a CC in a pull-request suffices.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2009-06-03 Thread Hans Verkuil
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 Jun  3 19:00:03 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   11921:111c819aed36
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: WARNINGS
linux-2.6.28-armv5: WARNINGS
linux-2.6.29.1-armv5: OK
linux-2.6.30-rc7-armv5: OK
linux-2.6.27-armv5-ixp: WARNINGS
linux-2.6.28-armv5-ixp: WARNINGS
linux-2.6.29.1-armv5-ixp: WARNINGS
linux-2.6.30-rc7-armv5-ixp: WARNINGS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-rc7-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.12-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-rc7-i686: WARNINGS
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-rc7-m32r: OK
linux-2.6.22.19-mips: ERRORS
linux-2.6.26-mips: ERRORS
linux-2.6.27-mips: ERRORS
linux-2.6.28-mips: ERRORS
linux-2.6.29.1-mips: ERRORS
linux-2.6.30-rc7-mips: ERRORS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-rc7-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.12-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.11-x86_64: WARNINGS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: WARNINGS
linux-2.6.28-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-rc7-x86_64: WARNINGS
sparse (linux-2.6.29.1): OK
sparse (linux-2.6.30-rc7): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The V4L2 specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 1/9] vpfe-capture bridge driver for DM355 & DM6446

2009-06-03 Thread Karicheri, Muralidharan
Laurent,

See my responses below. I have accepted and modified the code based on your 
comments. Few are discussed here for conclusion.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com

>> +#include 
>
>We should try to get rid of the TVP514x dependency. See below where TVP5146
>support is explicit for a discussion on this.
>
[MK]Agree. Only reason this is included is to configure the vpfe hw interface 
based on the sub device (tvp5146) output format. The output from TVP device is 
BT656. The bridge driver is expected to work with multiple interfaces such as 
BT.656, BT.1120, RAW image data bus consisting of 10 bit data, vsync, hsync 
etc. So I need to have a way of getting/setting hw interface parameters based 
on sub device output interface. Currently this support is not available in sub 
device. I see some discussion in the mailing list for allowing bridge driver to 
set the platform data in the sub device using s_config or 
v4l2_i2c_subdev_board(). I am not sure what will come out of this. Hans had a 
comment against DM6467 display driver to use the new v4l2 api 
v4l2_i2c_new_probed_subdev_addr(). When using this API, I find that the i2c 
driver is probed without setting the platform data (assume this is not defined 
statically using i2c_board_info in board setup file). Since both sub-device and 
bridge driver needs to be aware of the interface or bus that are used for 
connecting the devices, I strongly feel a need for defining a structure for 
interface configuration in the v4l2-subdev.h, define the values in board setup 
file and pass the same from bridge driver to sub device as an argument to 
v4l2_i2c_new_probed_subdev_addr() and set the same before calling the probe. I 
have posted an RFC for this in the linux media mailing list. So this cannot be 
done at this time.

>> +struct v4l2_routing *route =
>> +&(subdev->routes[vpfe_dev->current_input]);
>
>I think there's something wrong with how the current input is handled.
>current_input as assigned the input index number in vpfe_s_input, which is
>a
>global index across all subdevices. However, you use it as a subdevice
>local
>input index here.
[MK] current_input refers to the current input in the current subdev. When
application set input, vpfe_get_subdev_input_index() is called to do map of
application index to index in a sub device. I will add a description to the 
vpfe_get_subdev_input_index() function to clarify this.
>
>> +}
>> +
>> +/* set if client specific interface param is available */
>> +if (subdev->pdata) {
>> +/* each client will have different interface requirements */
>> +if (!strcmp(subdev->name, "tvp5146")) {
>> +struct tvp514x_platform_data *pdata = subdev->pdata;
>> +
>> +if (pdata->hs_polarity)
>> +vpfe_dev->vpfe_if_params.hdpol =
>> +VPFE_PINPOL_POSITIVE;
>> +else
>> +vpfe_dev->vpfe_if_params.hdpol =
>> +VPFE_PINPOL_NEGATIVE;
>> +
>> +if (pdata->vs_polarity)
>> +vpfe_dev->vpfe_if_params.vdpol =
>> +VPFE_PINPOL_POSITIVE;
>> +else
>> +vpfe_dev->vpfe_if_params.hdpol =
>> +VPFE_PINPOL_NEGATIVE;
>> +} else {
>> +v4l2_err(&vpfe_dev->v4l2_dev, "No interface params"
>> +" defined for subdevice, %d\n", route->output);
>> +return -EFAULT;
>> +}
>
>I'd really like to get rid of this. Instead of checking for a specific
>subdevice, we need a way to pass subdevice-agnostic data to the VPFE driver.
>Hans, what's your opinion on this ?
>
[MK] I have posted a RFC to deal with this. I don't have a response yet.
I need to wait on this. If no response, I will do my implementation and
send an RFC patch for this (adding a way to set the interface parameter
in sub device as well as bridge driver).
>> +
>> +/* vpfe_config_default_format: Update format information */
>> +static int vpfe_config_default_format(struct vpfe_device *vpfe_dev)
>> +{
>> +struct vpfe_config *cfg = vpfe_dev->cfg;
>> +struct vpfe_subdev_info *sub_dev =
>> +&cfg->sub_devs[vpfe_dev->current_subdev];
>> +struct v4l2_rect win;
>> +int ret = 0;
>> +
>> +vpfe_dev->crop.top = 0;
>> +vpfe_dev->crop.left = 0;
>> +/*
>> + * first get format information from the decoder.
>> + * if not available, get it from CCDC
>> + */
>> +ret = v4l2_device_call_until_err(&vpfe_dev->v4l2_dev,
>> +sub_dev->grp_id,
>> +video, g_fmt, &vpfe_dev->fmt);
>> +
>> +if (ret) {
>> +ret = vpfe_get_image_format(vpfe_dev, &vpfe_dev

Re: Digital Everywhere FloppyDTV / FireDTV (incl. CI)

2009-06-03 Thread Lou Otway

David Lister wrote:

Hi all,

just found out that these cards have finally some preliminary Linux
support. They seem quite versatile and even customizable -- a true gift
for dedicated hobbyists. :) PCI/PCIe/AGP or floppy drive mounting and
firewire /connection/ chaining look especially interesting. Even
FloppyDTV is apparently half internal, half external - sort of. Anybody
with hands-on access? Any updates? Share your experience! :o)


I have been evaluating the Floppy DTV DVB-S2, DVB-T and DVB-C variants.

So far I have managed to get fairly good results from the DVB-S2 and 
DVB-T adapters but I can't get the DVB-C device to tune under linux. I 
tested it with a windows PC to be sure it wasn't faulty and it worked fine.


I've had them all working (i.e. appearing as devices) while chained one 
to the next and when individually connected to a 1394 adapter card.


Now I need to spend some more time to see if they will give the 
performance I need, but so far so good.


If anyone has been able to tune the cable adapter under linux I'd like 
to hear more.


I had to make a small modification to the driver to enable some frontend 
settings required by my applications, but apart from that the latest v4l 
 drivers have been sufficient.


Cheers,

Lou
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Supportive (TV) hardware manufactures/companies

2009-06-03 Thread Paul Menzel
Dear list,


I am planning on buying (USB) DVB-T hardware. One of my criteria is to
buy a product from a company supporting GNU/Linux or free driver
development (code, hardware, etc.).

I did only find this message [1] about TechnoTrend Görler GmbH and
Terratec has an extra URL for GNU/Linux [2].

There were no information about manufacturers supporting free drivers in
the German article about hardware support in the Linux kernel in the
Linux Magazin 8/2008 [3 »Webcams und DVB-Empfänger«, not yet freely
available].

Could you please give me some information about this, what buying
decision would most profit your goals/free drivers.


Thanks,

Paul


[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg05625.html
[2] http://linux.terratec.de/
[3] http://www.linux-magazin.de/Heft-Abo/Ausgaben/2008/08


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: [RFC] Analog Device ADMTV 102 silicon tuner support patch

2009-06-03 Thread Mauro Carvalho Chehab
Em Wed, 3 Jun 2009 10:13:22 +0800
David Wong  escreveu:

> Hi all,
> 
>   This ADMTV102 tuner code is grab from open sourced driver for
> MyCinema U3100 Mini DMB-TH from ASUS.
> I made some clean up to separate the tuner code from demod code.
> 
>   The original driver author cannot be reached, so I don't know should
> I declare the copyright.

This is probably the most important thing to do: we should be sure that
the driver doesn't have any licensing troubles, since you'll need to testify it
via Signed-off-by. So, if you couldn't find the original author, you may try to
reach the companies envolved, e. g. the distro kernel people, Asus and Analog
Device, asking for their SOB at the original driver.

Also, if the driver is authored by Oliver, as stated at the .h comment:

+ *  Driver for Analog Device ADMTV102 silicon tuner
+ *
+ *  Copyright (c) 2006 Olivier DANET 

You should preserve his name at the meta-tags, instead of:

+MODULE_AUTHOR("David T.L. Wong");

(or, if you made significant changes, it is OK to add your name, without
suppressing the original author's name)

Another important point: when committing such drivers, the better is to add the
first patch (without Kconfig/Makefile changes) as-is, and then write a second
patch with your changes. This helps to have a clearer boundary line about your
contributions. The last patch should be the Kconfig/Makefile changes. This
helps to avoid trying to build a driver that may not compile well, due to some
API changes, for example, that needs to be fixed during the upstream merging
phase.

> Please comment.
> 
> Regards,
> David T.L. Wong




Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: videodev: Unknown symbol i2c_unregister_device (in kernels older than 2.6.26)

2009-06-03 Thread Mauro Carvalho Chehab
Em Wed, 03 Jun 2009 21:50:21 +1000
Matt Doran  escreveu:

> Mauro Carvalho Chehab wrote:
> > Em Mon, 25 May 2009 09:10:17 +1000
> > Matt Doran  escreveu:
> >
> >   
> >> Hi there,
> >>
> >> I tried using the latest v4l code on an Mythtv box running 2.6.20, but 
> >> the v4l videodev module fails to load with the following warnings:
> >>
> >> videodev: Unknown symbol i2c_unregister_device
> >> v4l2_common: Unknown symbol v4l2_device_register_subdev
> >>
> > I've just applied a patch at the tree that should fix this issue. It adds
> > several tests and the code, but, hopefully, it should be possible even to 
> > use
> > the IR's with kernels starting from 2.6.16.
> >
> >
> >   
> Thanks Mauro. 
> 
> I've recompiled all drivers without compile error and I've been using 
> everything for a few days now and it all works great.

Great!
> 
> Thanks again!

Anytime.




Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: videodev: Unknown symbol i2c_unregister_device (in kernels older than 2.6.26)

2009-06-03 Thread Matt Doran

Mauro Carvalho Chehab wrote:

Em Mon, 25 May 2009 09:10:17 +1000
Matt Doran  escreveu:

  

Hi there,

I tried using the latest v4l code on an Mythtv box running 2.6.20, but 
the v4l videodev module fails to load with the following warnings:


videodev: Unknown symbol i2c_unregister_device
v4l2_common: Unknown symbol v4l2_device_register_subdev


It seems the "i2c_unregister_device" function was added in 2.6.26.   
References to this function in v4l2-common.c are enclosed in an ifdef like:


#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 26)


However in "v4l2_device_unregister()" in v4l2-device.c, there is a 
reference to "i2c_unregister_device" without any ifdefs.   I am running 
a pretty old kernel, but I'd guess anyone running 2.6.25 or earlier will 
have this problem.   It seems this code was added by Mauro 3 weeks ago 
in this rev:


http://linuxtv.org/hg/v4l-dvb/rev/87afa7a4ccdf



I've just applied a patch at the tree that should fix this issue. It adds
several tests and the code, but, hopefully, it should be possible even to use
the IR's with kernels starting from 2.6.16.


  
Thanks Mauro. 

I've recompiled all drivers without compile error and I've been using 
everything for a few days now and it all works great.


Thanks again!
Matt

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: dib0700 Nova-TD-Stick problem

2009-06-03 Thread Soeren . Moch

Soeren.Moch wrote:

For a few weeks I use a Nova-TD-Stick and was annoyed with dvb stream
errors, although the demod bit-error-rate (BER/UNC) was zero.

I could track down this problem to dib0700_streaming_ctrl:
When one channel is streaming and the other channel is switched on, the
stream of the already running channel gets broken.

I think this is a firmware bug and should be fixed there, but I attach a
driver patch, which solved the problem for me. (Kernel 2.6.29.1, FW
1.20, Nova-T-Stick + Nova-TD-Stick used together). Since I had to reduce
the urb count to 1, I consider this patch as quick hack, not a real
solution.

Probably the same problem exists with other dib0700 diversity/dual
devices, without a firmware fix a similar driver patch may be helpful.

Regards,
Soeren



Hi Patrick,

do you see any chance that somebody will fix the firmware? If not, can  
you take

into consideration to remove the dib0700_streaming_ctrl callback as in the
(again) attached patch so solve the switch-on problem?
The patch runs flawlessly on my vdr system for weeks now. There are no  
negative

side effects from reducing the urb count to 1.

If you prefer a patch that removes the callback for all dib0700 devices or
only for all dual devices, I can prepare that. But I can test it only with
Nova-T-Stick and Nova-TD-Stick.

Regards,
Soeren


--- drivers/media/dvb/dvb-usb/dib0700_devices.c.orig	2009-04-18 16:45:12.0 +0200
+++ drivers/media/dvb/dvb-usb/dib0700_devices.c	2009-04-18 18:58:54.0 +0200
@@ -290,6 +290,9 @@ static int stk7700d_frontend_attach(stru
 	adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap,0x80+(adap->id << 1),
 &stk7700d_dib7000p_mt2266_config[adap->id]);
 
+adap->props.streaming_ctrl = NULL;
+dib0700_streaming_ctrl(adap, 1);
+
 	return adap->fe == NULL ? -ENODEV : 0;
 }
 
@@ -1414,7 +1417,7 @@ MODULE_DEVICE_TABLE(usb, dib0700_usb_id_
 	.streaming_ctrl   = dib0700_streaming_ctrl, \
 	.stream = { \
 		.type = USB_BULK, \
-		.count = 4, \
+		.count = 1, \
 		.endpoint = ep, \
 		.u = { \
 			.bulk = { \


[PATCH] video: Initial support for ADV7180

2009-06-03 Thread Richard Ršöjfors
This is an initial driver for Analog Devices ADV7180 Video Decoder.

So far it only supports query standard.

Signed-off-by: Richard Röjfors 
---
Index: linux-2.6.30-rc7/drivers/media/video/adv7180.c
===
--- linux-2.6.30-rc7/drivers/media/video/adv7180.c  (revision 0)
+++ linux-2.6.30-rc7/drivers/media/video/adv7180.c  (revision 867)
@@ -0,0 +1,221 @@
+/*
+ * adv7180.c Analog Devices ADV7180 video decoder driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define ADV7180_INPUT_CONTROL_REG  0x00
+#define ADV7180_INPUT_CONTROL_PAL_BG_NTSC_J_SECAM  0x00
+#define ADV7180_AUTODETECT_ENABLE_REG  0x07
+#define ADV7180_AUTODETECT_DEFAULT 0x7f
+
+
+#define ADV7180_STATUS1_REG 0x10
+#define ADV7180_STATUS1_AUTOD_MASK 0x70
+#define ADV7180_STATUS1_AUTOD_NTSM_M_J 0x00
+#define ADV7180_STATUS1_AUTOD_NTSC_4_43 0x10
+#define ADV7180_STATUS1_AUTOD_PAL_M0x20
+#define ADV7180_STATUS1_AUTOD_PAL_60   0x30
+#define ADV7180_STATUS1_AUTOD_PAL_B_G  0x40
+#define ADV7180_STATUS1_AUTOD_SECAM0x50
+#define ADV7180_STATUS1_AUTOD_PAL_COMB 0x60
+#define ADV7180_STATUS1_AUTOD_SECAM_5250x70
+
+#define ADV7180_IDENT_REG 0x11
+#define ADV7180_ID_7180 0x18
+
+
+static unsigned short normal_i2c[] = { 0x42 >> 1, I2C_CLIENT_END };
+
+I2C_CLIENT_INSMOD;
+
+struct adv7180_state {
+   struct v4l2_subdev sd;
+};
+
+static v4l2_std_id determine_norm(struct i2c_client *client)
+{
+   u8 status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
+
+   switch (status1 & ADV7180_STATUS1_AUTOD_MASK) {
+   case ADV7180_STATUS1_AUTOD_NTSM_M_J:
+   return V4L2_STD_NTSC_M_JP;
+   case ADV7180_STATUS1_AUTOD_NTSC_4_43:
+   return V4L2_STD_NTSC_443;
+   case ADV7180_STATUS1_AUTOD_PAL_M:
+   return V4L2_STD_PAL_M;
+   case ADV7180_STATUS1_AUTOD_PAL_60:
+   return V4L2_STD_PAL_60;
+   case ADV7180_STATUS1_AUTOD_PAL_B_G:
+   return V4L2_STD_PAL;
+   case ADV7180_STATUS1_AUTOD_SECAM:
+   return V4L2_STD_SECAM;
+   case ADV7180_STATUS1_AUTOD_PAL_COMB:
+   return V4L2_STD_PAL_Nc | V4L2_STD_PAL_N;
+   case ADV7180_STATUS1_AUTOD_SECAM_525:
+   return V4L2_STD_SECAM;
+   default:
+   return V4L2_STD_UNKNOWN;
+   }
+}
+
+static inline struct adv7180_state *to_state(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct adv7180_state, sd);
+}
+
+static int adv7180_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+   *(v4l2_std_id *)std = determine_norm(client);
+   return 0;
+}
+
+static int adv7180_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+{
+   return -EINVAL;
+}
+
+static int adv7180_s_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+{
+   return -EINVAL;
+}
+
+static int adv7180_g_chip_ident(struct v4l2_subdev *sd,
+   struct v4l2_dbg_chip_ident *chip)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+   return v4l2_chip_ident_i2c_client(client, chip, V4L2_IDENT_ADV7180, 0);
+}
+
+static int adv7180_log_status(struct v4l2_subdev *sd)
+{
+   v4l2_info(sd, "Normal operation\n");
+   return 0;
+}
+
+static irqreturn_t adv7180_irq(int irq, void *devid)
+{
+   return IRQ_NONE;
+}
+
+static const struct v4l2_subdev_video_ops adv7180_video_ops = {
+   .querystd = adv7180_querystd,
+};
+
+static const struct v4l2_subdev_core_ops adv7180_core_ops = {
+   .log_status = adv7180_log_status,
+   .g_chip_ident = adv7180_g_chip_ident,
+   .g_ctrl = adv7180_g_ctrl,
+   .s_ctrl = adv7180_s_ctrl,
+};
+
+static const struct v4l2_subdev_ops adv7180_ops = {
+   .core = &adv7180_core_ops,
+   .video = &adv7180_video_ops,
+};
+
+/*
+ * Generic i2c probe
+ * concerning the addresses: i2c wants 7 bit (without the r/w bit), so '>>1'
+ */
+
+static int adv7180_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct adv7180_state *state;
+   struct v4l2_subdev *sd;
+
+   /* Check if the adapter supports the needed feature

libv4l release: 0.5.99 (The don't crash release)

2009-06-03 Thread Hans de Goede

Hi All,

So 0.5.98 had a few nasty bugs, causing black screens
and crashes in certain cases.

This release should fix all those.


libv4l-0.5.99
-
* Link libv4lconvert with -lm for powf by Gregor Jasny
* Fix black screen on devices with hardware gamma control
* Fix crash with devices on which we do not emulate fake controls
* Add a patch by Hans Petter Selasky , which should
  lead to allowing use of libv4l (and the Linux webcam drivers ported
  to userspace usb drivers) on FreeBSD, this is a work in progress


Get it here:
http://people.atrpms.net/~hdegoede/libv4l-0.5.99.tar.gz

Regards,

Hans

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Aspect ratio change does not take effect (DVB-S)

2009-06-03 Thread Soeren D. Schulze
BOUWSMA Barry schrieb:
> Moin Sören,
> 
> On Tue, 2 Jun 2009, Soeren D. Schulze wrote:
> 
>> right now, but there seems to be a little bug:  When watching the TV
>> stream using and szap and mplayer, changes in the aspect ratio of the TV
>> program do not take effect until mplayer is restarted.  This used to
>> work with the former device!
> 
> This should be an issue with `mplayer' -- the aspect ratio is
> simply part of the datastream sent as an MPEG transport stream
> as encoded by the broadcaster.
> 
> `mplayer' is known to have this issue with the option `-vc mpeg12'
> while in recent mplayer, the default is `-vc ffmpeg12' where this
> aspect ratio switching works properly.  Try adding that latter
> option and see if it works as expected.

Gotcha.  It works.  Thanks again.


Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Fwd: driver trident tm5600

2009-06-03 Thread Kevin Wells

Daniel Santibáñez wrote:


Hello.!!
i tried to install a driver for this usb device, long time i try to 
finish but, when i probe the driver error by erro appear,and  this don't 
work aparently.. when i run modprobe this say:


tm6000-alsa: Unknow symbol tm6000_get_reg
tm6000-alsa: Unknow symbol tm6000_set_reg

what i have to do.? could you help me.?? exist a how to? actualy? thanks.


I currently use:

Kernel: Linux 2.6.28-12-generic (i686)
Compiled: #43-Ubuntu SMP Fri May 1 19:27:06 UTC 2009
C Library: GNU C Library version 2.9 (stable)
Distribution: Ubuntu 9.04
Desktop Environment: GNOME 2.26


Hi Daniel,

I suggest you post to the linux-media mailing list in future. That way 
the mailing lists acts as a knowledge base for other people with the 
same problem. See http://www.linuxtv.org/lists.php for details. I used 
BCC in case you don't want your e-mail address on a public site.


Did you pull from the http://linuxtv.org/hg/~mchehab/tm6010 repository 
with last change dated 28 Nov 2008? That code compiles on Ubuntu 8.10 
but not on Ubuntu 9.04. You could try the following (untested) patch to 
resolve this.


I only have experience trying to get the Hauppauge HVR-900H working with 
this driver. It does not currently work for me with New Zealand television.


Kevin

diff -r ca10a33f275b linux/drivers/media/dvb/dvb-core/dvbdev.c
--- a/linux/drivers/media/dvb/dvb-core/dvbdev.c	Sun Apr 05 10:57:01 2009 
+1200
+++ b/linux/drivers/media/dvb/dvb-core/dvbdev.c	Wed Jun 03 20:45:03 2009 
+1200

@@ -261,7 +261,7 @@

 #if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 27)
clsdev = device_create(dvb_class, adap->device,
-  MKDEV(DVB_MAJOR, nums2minor(adap->num, type, 
id)),
+  MKDEV(DVB_MAJOR, minor),
   NULL, "dvb%d.%s%d", adap->num, dnames[type], id);
 #elif LINUX_VERSION_CODE == KERNEL_VERSION(2, 6, 27)
clsdev = device_create_drvdata(dvb_class, adap->device,
diff -r ca10a33f275b linux/drivers/media/video/tm6000/tm6000-alsa.c
--- a/linux/drivers/media/video/tm6000/tm6000-alsa.c	Sun Apr 05 10:57:01 
2009 +1200
+++ b/linux/drivers/media/video/tm6000/tm6000-alsa.c	Wed Jun 03 20:45:03 
2009 +1200

@@ -17,7 +17,7 @@
 #include 

 #include 
-#include 
+/*#include */
 #include 
 #include 
 #include 
diff -r ca10a33f275b linux/drivers/media/video/tm6000/tm6000-i2c.c
--- a/linux/drivers/media/video/tm6000/tm6000-i2c.c	Sun Apr 05 10:57:01 
2009 +1200
+++ b/linux/drivers/media/video/tm6000/tm6000-i2c.c	Wed Jun 03 20:45:03 
2009 +1200

@@ -258,7 +258,7 @@

 /* Tuner callback to provide the proper gpio changes needed for xc2028 */

-static int tm6000_tuner_callback(void *ptr, int command, int arg)
+static int tm6000_tuner_callback(void *ptr, int component, int command, 
int arg)

 {
int rc=0;
struct tm6000_core *dev = ptr;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Creating a V4L driver for a USB camera

2009-06-03 Thread Hans de Goede

Hi,

On 06/03/2009 06:13 AM, Erik de Castro Lopo wrote:

Hi all,

I'm a senior software engineer [0] with a small startup. Our product
is Linux based and makes use of a 3M pixel camera. Unfortunately, the
camera we have been using for the last 3 years is no longer being
produced.

We have found two candidate replacement cameras, one with a binary
only driver and user space library and one with a windows driver
but no Linux driver.

My questions:

  - How difficult is it to create a GPL V4L driver for a USB camera
by snooping the USB traffic of the device when connected to
a windows machine? The intention is to merge this work into
the V4L mainline and ultimately the kernel.



That depends mainly on the format of the image data by the cam,
if the cam sends raw bayer data, or raw yuv / rgb then this is doable,
if it uses plain JPEG it is also doable. If it uses some custom
compression then you need a wizzkid to crack the code. I've tried
this myself, and I failed, you really need someone with the right
mindset to reverse engineer a compression algorithm. Merely being
a good programmer is not enough.


  - How much work is involved in the above for someone experienced
in writing V4L drivers?


This can vary wildly, assuming the video data format is a known one,
a wild estimate would be that this takes 2 fulltime weeks (with hands
on hardware access). But it could be that it takes much longer if
somehow the cam is strange (or worse, like buggy).


  - Are there people involved with the V4L project that would be
willing to undertake this project under contract?



Your welcome to send me a couple of cams, that is usually all the
payment I expect, I also don't make any promises (I do this on top
of my dayjob). But first things first, what are the usb-id's of
the cams, can you send me (offlist) the windows drivers ? Chances are
the chipset used is already supported.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PULL] generic image bounds setting and alignment function

2009-06-03 Thread Trent Piepho
On Mon, 1 Jun 2009, Robert Jarzmik wrote:
> Trent Piepho  writes:
> > Please pull from http://linuxtv.org/hg/~tap/v4l-dvb
> >
> > This series adds a function for bounding and alignment image sizes and
> > modifies a number of drivers to use it.  It came up when the pxa patches to
> > deal with the alignment issues for that driver were posted.  I haven't
> > tested these patches for pxa.
>
> Hi Trent,
>
> I didn't see the review of that serie, I'm curious what others said.
> As for my comments, I'll inline your code, sorry about that.
>
> > 02/14: v4l2: Create helper function for bounding and aligning images
> > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b4d3ec8d363d
> >
> +static unsigned int clamp_align(unsigned int x, unsigned int min,
> + unsigned int max, unsigned int align)
> +{
> + /* Bits that must be zero to be aligned */
> + unsigned int mask = ~((1 << align) - 1);
> +
> + /* Round to nearest aligned value */
> + if (align)
> + x = (x + (1 << (align - 1))) & mask;
>
> If I'm not mistaken, these lines are an equivalent of :
>   balign = 1 << align;
> if (align)
>   x = ALIGN(x + 1 - balign/2, balign);
>
> Isn't that simpler to read ?

I don't think so, it's not obvious that it will round to the nearest value.
You have to look up ALIGN and then __ALIGN_MASK and see that it will in
effect add balign - 1 and then reduce x + 1 - balign/2 + balign - 1 into x
+ balign/2.

It also generates worse code.  You'd think the compiled would be able to
optimize it into the same code, but it doesn't.  Unless there is some issue
with how it will work with negative values that causes a subtle difference.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html