Re: Status of the patches under review (45 patches)

2010-03-12 Thread Hans de Goede

Hi,


== Gspca patches - Waiting Hans de Goedehdego...@redhat.com  
submission/review ==

Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown packet received   
http://patchwork.kernel.org/patch/75837


I nacked this one, as the zc3xx sends many non button press interrupt packets 
per second which this patch would all
log to dmesg as being unknown.


Mar, 8 2010: [1/1] gspca-stv06xx: Remove the 046d:08da usb id from linking to 
the   http://patchwork.kernel.org/patch/84145



I acked this one, this should go in through Erik Andren's own tree.

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: Status of the patches under review (45 patches)

2010-03-12 Thread Jean-Francois Moine
Hi Hans,

On Fri, 12 Mar 2010 09:07:22 +0100
Hans de Goede hdego...@redhat.com wrote:
  == Gspca patches - Waiting Hans de
  Goedehdego...@redhat.com  submission/review ==
 
  Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown
  packet received   http://patchwork.kernel.org/patch/75837
 
 I nacked this one, as the zc3xx sends many non button press interrupt
 packets per second which this patch would all log to dmesg as being
 unknown.

Agree.

  Mar, 8 2010: [1/1] gspca-stv06xx: Remove the 046d:08da usb id from
  linking to the   http://patchwork.kernel.org/patch/84145
 
 
 I acked this one, this should go in through Erik Andren's own tree.

I already sent a pull request for this one.

Cheers.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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: Status of the patches under review (45 patches)

2010-03-12 Thread Jean-Francois Moine
Hi Mauro,

On Tue, 09 Mar 2010 16:05:44 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:

   == Gspca patches - Waiting Jean-Francois Moine
 moin...@free.fr submission/review == 
 
 Jan,14 2010: Problem with gspca and zc3xx
 http://patchwork.kernel.org/patch/72895

This is not the right way to fix the problem.

[snip]
 Feb,28 2010: [1/3] add feedback LED control
 http://patchwork.kernel.org/patch/82773
 Feb,28 2010: [2/3] gspca pac7302: add LED control
 http://patchwork.kernel.org/patch/82774
 Feb,28 2010: [3/3] gspca pac7302: remove LED blinking when switching
 stream on and http://patchwork.kernel.org/patch/82775

It is not sure yet that using the LED system is the right way...

Regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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 2/5] drivers/media/video: move dereference after NULL test

2010-03-12 Thread Julia Lawall
From: Julia Lawall ju...@diku.dk

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.  Test std_info-stdid instead.

In saa7134-alsa.c, the function is only called from one place, where the
chip argument has already been dereferenced.  On the other hand, if it
should be kept, then card should be initialized after it.

A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):

// smpl
@match exists@
expression x, E;
identifier fld;
@@

* x-fld
  ... when != \(x = E\|x\)
* x == NULL
// /smpl

Signed-off-by: Julia Lawall ju...@diku.dk

---
 drivers/media/video/davinci/vpif_display.c|2 +-
 drivers/media/video/saa7134/saa7134-alsa.c|2 --
 drivers/media/video/usbvideo/quickcam_messenger.c |3 ++-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/usbvideo/quickcam_messenger.c 
b/drivers/media/video/usbvideo/quickcam_messenger.c
index 803d3e4..f0043d0 100644
--- a/drivers/media/video/usbvideo/quickcam_messenger.c
+++ b/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -692,12 +692,13 @@ static int qcm_start_data(struct uvd *uvd)
 
 static void qcm_stop_data(struct uvd *uvd)
 {
-   struct qcm *cam = (struct qcm *) uvd-user_data;
+   struct qcm *cam;
int i, j;
int ret;
 
if ((uvd == NULL) || (!uvd-streaming) || (uvd-dev == NULL))
return;
+   cam = (struct qcm *) uvd-user_data;
 
ret = qcm_camera_off(uvd);
if (ret)
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c 
b/drivers/media/video/saa7134/saa7134-alsa.c
index d48c450..d3bd82a 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -1011,8 +1011,6 @@ static int snd_card_saa7134_new_mixer(snd_card_saa7134_t 
* chip)
unsigned int idx;
int err, addr;
 
-   if (snd_BUG_ON(!chip))
-   return -EINVAL;
strcpy(card-mixername, SAA7134 Mixer);
 
for (idx = 0; idx  ARRAY_SIZE(snd_saa7134_volume_controls); idx++) {
diff --git a/drivers/media/video/davinci/vpif_display.c 
b/drivers/media/video/davinci/vpif_display.c
index dfddef7..b2dce78 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -383,7 +383,7 @@ static int vpif_get_std_info(struct channel_obj *ch)
int index;
 
std_info-stdid = vid_ch-stdid;
-   if (!std_info)
+   if (!std_info-stdid)
return -1;
 
for (index = 0; index  ARRAY_SIZE(ch_params); index++) {
--
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 v2] V4L/DVB: mx1-camera: compile fix

2010-03-12 Thread Guennadi Liakhovetski
Hi Uwe

On Fri, 5 Mar 2010, Uwe Kleine-König wrote:

 This is a regression of
 
   7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old 
 names)
 
 Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
 ---
  drivers/media/video/mx1_camera.c |   12 +++-
  1 files changed, 7 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/media/video/mx1_camera.c 
 b/drivers/media/video/mx1_camera.c
 index 2ba14fb..29c2833 100644
 --- a/drivers/media/video/mx1_camera.c
 +++ b/drivers/media/video/mx1_camera.c
 @@ -45,11 +45,13 @@
  #include mach/hardware.h
  #include mach/mx1_camera.h
  
 +#define __DMAREG(offset) (MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) + offset)
 +

Well, I think, Sascha is right, we have to fix 
arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h, because that's what actually 
got broken. The line

#define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR)

in it is no longer valid, right? So, we have to either remove it, or fix 
it, if we think, that other drivers might start using it. And even if we 
decide to remove it from the header and implement here, wouldn't it be 
better to choose a name, not beginning with __? Something like 
MX1_DMA_REG, perhaps? Or maybe even we shall remap those registers?

Thanks
Guennadi

  /*
   * CSI registers
   */
 -#define DMA_CCR(x)   (0x8c + ((x)  6)) /* Control Registers */
 -#define DMA_DIMR 0x08/* Interrupt mask Register */
 +#define DMA_CCR(x)   __DMAREG(0x8c + ((x)  6)) /* Control Registers */
 +#define DMA_DIMR __DMAREG(0x08)  /* Interrupt mask Register */
  #define CSICR1   0x00/* CSI Control Register 
 1 */
  #define CSISR0x08/* CSI Status Register 
 */
  #define CSIRXR   0x10/* CSI RxFIFO Register 
 */
 @@ -783,7 +785,7 @@ static int __init mx1_camera_probe(struct platform_device 
 *pdev)
  pcdev);
  
   imx_dma_config_channel(pcdev-dma_chan, IMX_DMA_TYPE_FIFO,
 -IMX_DMA_MEMSIZE_32, DMA_REQ_CSI_R, 0);
 +IMX_DMA_MEMSIZE_32, MX1_DMA_REQ_CSI_R, 0);
   /* burst length : 16 words = 64 bytes */
   imx_dma_config_burstlen(pcdev-dma_chan, 0);
  
 @@ -797,8 +799,8 @@ static int __init mx1_camera_probe(struct platform_device 
 *pdev)
   set_fiq_handler(mx1_camera_sof_fiq_start, mx1_camera_sof_fiq_end -
  mx1_camera_sof_fiq_start);
  
 - regs.ARM_r8 = DMA_BASE + DMA_DIMR;
 - regs.ARM_r9 = DMA_BASE + DMA_CCR(pcdev-dma_chan);
 + regs.ARM_r8 = (long)DMA_DIMR;
 + regs.ARM_r9 = (long)DMA_CCR(pcdev-dma_chan);
   regs.ARM_r10 = (long)pcdev-base + CSICR1;
   regs.ARM_fp = (long)pcdev-base + CSISR;
   regs.ARM_sp = 1  pcdev-dma_chan;
 -- 
 1.7.0
 

---
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


Re: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants

2010-03-12 Thread Jean Delvare
Hi Daro,

On Fri, 26 Feb 2010 17:19:38 +0100, Daro wrote:
 I did not forget I had offered to test the patch however I am now on vacation 
 skiing so I will get back to you as soon I am back home.

Are you back home by now? We are still waiting for your test results.
We can't push the patch upstream without it, and if it takes too long,
I'll probably just discard the patch and move to other tasks.

-- 
Jean Delvare
--
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 v2] V4L/DVB: mx1-camera: compile fix

2010-03-12 Thread Uwe Kleine-König
Hello,

On Fri, Mar 12, 2010 at 10:22:31AM +0100, Guennadi Liakhovetski wrote:
 On Fri, 5 Mar 2010, Uwe Kleine-König wrote:
  This is a regression of
  
  7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old 
  names)
  
  Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
  ---
   drivers/media/video/mx1_camera.c |   12 +++-
   1 files changed, 7 insertions(+), 5 deletions(-)
  
  diff --git a/drivers/media/video/mx1_camera.c 
  b/drivers/media/video/mx1_camera.c
  index 2ba14fb..29c2833 100644
  --- a/drivers/media/video/mx1_camera.c
  +++ b/drivers/media/video/mx1_camera.c
  @@ -45,11 +45,13 @@
   #include mach/hardware.h
   #include mach/mx1_camera.h
   
  +#define __DMAREG(offset)   (MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) + offset)
  +
 
 Well, I think, Sascha is right, we have to fix 
 arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h, because that's what actually 
 got broken. The line
 
 #define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR)
 
 in it is no longer valid, right? So, we have to either remove it, or fix 
 it, if we think, that other drivers might start using it.
I thought a minimal fix would be a good idea.  I have no problem with a
clean one though.

   And even if we 
 decide to remove it from the header and implement here, wouldn't it be 
 better to choose a name, not beginning with __? Something like 
 MX1_DMA_REG, perhaps?
Then the register definitions should go into the header, too.  I will
prepare a patch later today.
   Or maybe even we shall remap those registers?
Well, they are remapped, don't they?  Otherwise IO_ADDRESS wouldn't
work.

Best regards
Uwe
-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.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


Re: [PATCH v2] V4L/DVB: mx1-camera: compile fix

2010-03-12 Thread Guennadi Liakhovetski
On Fri, 12 Mar 2010, Uwe Kleine-König wrote:

Or maybe even we shall remap those registers?
 Well, they are remapped, don't they?  Otherwise IO_ADDRESS wouldn't
 work.

Yes, they are (statically, I presume), but not in _this_ driver...

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


Announcing v4l-utils-0.7.91

2010-03-12 Thread Hans de Goede

Hi,

I'm happy to announce the second release of v4l-utils, nothing
special this time around just a few small bug fixes and cleanups
left and right.
New this release:

v4l-utils-0.7.91

* Utils changes:
  * Improve v4l-keytable to better support IR (mchehab)
  * Rename v4l-keytable to ir-keytable (mchehab)
* libv4l changes (hdegoede):
  * Add more laptop models to the upside down devices table
  * Ignore convert errors in the first few frames of a stream

Go get it here:
http://people.fedoraproject.org/~jwrdegoede/v4l-utils-0.7.91.tar.bz2

You can always find the latest developments here:
http://git.linuxtv.org/v4l-utils.git

Note, it would be good to have some place at linuxtv.org to host the
tarbals, if someone could help me set that up that would be great.

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


tzap -r doesn't work on new Swedish DVB-T channels

2010-03-12 Thread Hörlin Magnus
Hi. Since february there are some new h264 SD channels in the Swedish DVB-T 
network. I get a lock with tzap, I can watch the channels in VDR but I get no 
output on /dev/dvb/adapterX/dvr0 then running tzap -r on 506 MHz. On all other 
transponders I get a stream on dvr0. Scan finds some strange channels that 
don't provide a name on this frequency:

[04b0]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:1200:3
[0316]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:790:3
[0320]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:800:3
Boxer 
Navigator:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:65534:3
[0302]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:770:3
[02ee]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:750:3
BBC World 
News:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:560:3
Discovery 
TL:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:570:3
Discovery 
Science:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:580:3
Disney 
XD:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:590:3
Showtime:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:600:3
7:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:810:3
Star!:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:960:3

Can anyone point me in the right direction in the tzap code to try to find the 
reason for this?

/Magnus H


The information contained in this e-mail message is privileged and
confidential and is for the exclusive use of the addressee. The person
who receives this message and who is not the addressee, one of his
employees or an agent entitled to hand it over to the addressee, is
informed that he may not use, disclose or reproduce the contents
thereof, and is kindly asked to notify the sender and delete the e-mail
immediately.


--
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


tzap -r doesn't work on new Swedish DVB-T channels

2010-03-12 Thread Magnus H
Hi. Since february there are some new h264 SD channels in the Swedish DVB-T
network. I get a lock with tzap, I can watch the channels in VDR but I get
no output on /dev/dvb/adapterX/dvr0 then running tzap -r on 506 MHz. On all
other transponders I get a stream on dvr0. Scan finds some strange channels
that don't provide a name on this frequency:

[04b0]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:1200:3
[0316]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:790:3
[0320]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:800:3
Boxer
Navigator:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:T
RANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:65534:3
[0302]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:770:3
[02ee]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:750:3
BBC World
News:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSM
ISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:560:3
Discovery
TL:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMI
SSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:570:3
Discovery
Science:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRA
NSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:580:3
Disney
XD:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMIS
SION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:590:3
Showtime:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR
ANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:600:3
7:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISS
ION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:810:3
Star!:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANS
MISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:960:3

Can anyone point me in the right direction in the tzap code to try to find
the reason for this?

/Magnus H


--
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


terratec hybrid xs fm

2010-03-12 Thread Adriano Gigante

Devin,
I know I'm boring...
any news about 0072/terratec hybrid xs fm driver develop progress?
Thanks
Adri
--
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


xc2028 1-0061: error: bandwidth not supported. If anyone could help me ?

2010-03-12 Thread Arnaud Boy
Hi,

I have 2 differents dongle but the same errors appairs because there's
the same tuner system. I'll use this dongles for dvb-t reception.

The driver i'm using is the mercurial revision 82c3b0033929 tip

Maybe I forget something, please anyone should help me.

When I'll try to see a dvb-t channel with the card 1 (PCTV 330e) i'll
get this error.
==
[12687.577100] xc2028 1-0061: error: bandwidth not supported.
[12687.636069] xc2028 1-0061: Loading firmware for type=BASE MTS (5),
id .
[12688.768071] xc2028 1-0061: Loading firmware for type=BASE MTS (5),
id .

With the card 2 (USB 2881 Video) I've the same errors
===
[12888.431519] xc2028 1-0061: error: bandwidth not supported.
[12888.488512] xc2028 1-0061: Loading firmware for type=BASE (1), id
.
[12889.589077] xc2028 1-0061: Loading firmware for type=BASE (1), id
.


Card 1 dmesg
==
[12308.004121] usb 1-1: new high speed USB device using ehci_hcd and address 11
[12308.145714] usb 1-1: New USB device found, idVendor=2304, idProduct=0226
[12308.145725] usb 1-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[12308.145733] usb 1-1: Product: PCTV 330e
[12308.145739] usb 1-1: Manufacturer: Pinnacle Systems
[12308.145744] usb 1-1: SerialNumber: 061101027954
[12308.145960] usb 1-1: configuration #1 chosen from 1 choice
[12308.14] em28xx: New device Pinnacle Systems PCTV 330e @ 480
Mbps (2304:0226, interface 0, class 0)
[12308.148053] em28xx #0: chip ID is em2882/em2883
[12308.324566] em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 26 02 d0 12
5c 03 8e 16 a4 1c
[12308.324589] em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00
00 00 00 00 00 00
[12308.324610] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00
00 00 5b e0 00 00
[12308.324629] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01
00 00 00 00 00 00
[12308.324647] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324665] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324683] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00
24 03 50 00 69 00
[12308.324701] em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00
65 00 20 00 53 00
[12308.324719] em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00
73 00 00 00 16 03
[12308.324737] em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00
33 00 33 00 30 00
[12308.324755] em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 36 00
31 00 31 00 30 00
[12308.324773] em28xx #0: i2c eeprom b0: 31 00 30 00 32 00 37 00 39 00
35 00 34 00 00 00
[12308.324791] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324809] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324827] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324845] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324867] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb0b3aebf
[12308.324873] em28xx #0: EEPROM info:
[12308.324877] em28xx #0:   AC97 audio (5 sample rates)
[12308.324882] em28xx #0:   500mA max power
[12308.324888] em28xx #0:   Table at 0x27, strings=0x168e, 0x1ca4, 0x246a
[12308.326783] em28xx #0: Identified as Pinnacle Hybrid Pro (330e) (card=56)
[12308.330650] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0)
[12308.336375] tuner 1-0061: chip found @ 0xc2 (em28xx #0)
[12308.336536] xc2028 1-0061: creating new instance
[12308.336543] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
[12308.336558] usb 1-1: firmware: requesting xc3028-v27.fw
[12308.346584] xc2028 1-0061: Loading 80 firmware images from
xc3028-v27.fw, type: xc2028 firmware, ver 2.7
[12308.392088] xc2028 1-0061: Loading firmware for type=BASE MTS (5),
id .
[12309.399125] xc2028 1-0061: Loading firmware for type=MTS (4), id
b700.
[12309.415115] xc2028 1-0061: Loading SCODE for type=MTS LCD NOGD MONO
IF SCODE HAS_IF_4500 (6002b004), id b700.
[12309.540632] input: em28xx IR (em28xx #0) as
/devices/pci:00/:00:12.2/usb1/1-1/input/input22
[12309.540781] Creating IR device irrcv0
[12309.541715] em28xx #0: Config register raw data: 0xd0
[12309.542565] em28xx #0: AC97 vendor ID = 0x
[12309.542933] em28xx #0: AC97 features = 0x6a90
[12309.542941] em28xx #0: Empia 202 AC97 audio processor detected
[12309.673039] tvp5150 1-005c: tvp5150am1 detected.
[12309.777174] em28xx #0: v4l2 driver version 0.1.2
[12309.863427] em28xx #0: V4L2 video device registered as video1
[12309.863432] em28xx #0: V4L2 VBI device registered as vbi0
[12309.863435] em28xx-audio.c: probing for em28x1 non standard usbaudio
[12309.863438] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger
[12309.915259] xc2028 1-0061: attaching existing instance
[12309.915264] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner

Hybrid Yuan MC770A TV tuner and UVC Video

2010-03-12 Thread Damian Krasowski
Hello

I'm interresing in analog part (tv/radio) of Hybrid Yuan MC770A TV
tuner from ASUS F3 series notebook and many other newer series.
You could add uvcvideo support for vflip Sonix 1.3M Webcam placed in
ASUS F3 series notebook?

-- 
Damian Krasowski
--
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: v4l-utils: i2c-id.h and alevt

2010-03-12 Thread Devin Heitmueller
On Fri, Mar 12, 2010 at 2:27 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 For unmaintained applications the problem is that even those people that
 have patches for them have no easy way to get them applied, precisely because
 they are unmaintained.

 We as v4l-dvb developers don't have the time to make TV apps, but perhaps if
 we 'adopted' one unmaintained application and just update that whenever we
 make new features, then that would be very helpful I think. Or perhaps just
 provide a place for such applications where there is someone who can take
 community supplied patches and review and apply them.

This is the key reason that KernelLabs adopted tvtime - the goal being to:

1.  Consolidate all the distro patches floating around
2.  Have a source tree that compiles without patches on modern distributions
3.  Have a channel for people to submit new patches
4.  Make improvements as necessary to make the app just work for
most modern tuner cards.

The goal is to get the distros to switch over to treating our tree as
the official upstream source so that people will finally have a
lightweight application for analog tv that just works and ships with
their Linux distro by default.

 Such an application does not have to be in v4l2-utils, it can have its own
 tree.

If the goal is for the LinuxTV group to adopt some of these
applications, I would definitely recommend it not be in the v4l-utils
tree (for reasons stated in the previous email).  that said, I
certainly have no objection to it in principle.

 Anyway, regarding alevt: I believe that the consensus is that it should be
 moved to v4l2-utils? Or am I wrong?

I haven't looked at the alevt code itself but I believe the answer
should be based on the following questions:

1.  How big is it?  Will distros not want to include the package by
default because along with a few KB of utilities they also end up with
several megabytes of crap that the vast majority of people don't care
about?

2.  What external dependencies does it have?  Right now, v4l-utils is
just a few command line tools with minimal dependencies (meaning it is
trivial to install in pretty much all environments, including those
without X11).  If the result is that you would now have to install
dozens of packages, then that would be a bad thing.

Jamming stuff into v4l-utils should not be seen as some sort of
backdoor way to get Linux distributions to include programs that they
wouldn't have otherwise.  The distributions should see real value in
the additional tool.  If they value the program, they will package the
program if we host it even as a standalone project outside of
v4l-utils.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: v4l-utils: i2c-id.h and alevt

2010-03-12 Thread Hans de Goede

Hi,

On 03/12/2010 08:27 AM, Hans Verkuil wrote:

On Thursday 11 March 2010 15:31:32 Devin Heitmueller wrote:

On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
dougsl...@gmail.com  wrote:

On 03/10/2010 02:04 AM, hermann pitton wrote:

Hi Hans, both,

Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:

It's nice to see this new tree, that should be make it easier to develop
utilities!

After a quick check I noticed that the i2c-id.h header was copied from the
kernel. This is not necessary. The only utility that includes this is v4l2-dbg
and that one no longer needs it. Hans, can you remove this?

The second question is whether anyone would object if alevt is moved from
dvb-apps to v4l-utils? It is much more appropriate to have that tool in
v4l-utils.


i wonder that this stays such calm, hopefully a good sign.

In fact alevt analog should come with almost every distribution, but the
former alevt-dvb, named now only alevt, well, might be ok in some
future, is enhanced for doing also dvb-t-s and hence there ATM.


Does anyone know of other unmaintained but useful tools that we might merge
into v4l-utils? E.g. xawtv perhaps?


If for xawtv could be some more care, ships also since close to ever
with alevtd, that would be fine, but I'm not sure we are talking about
tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
example are also there and unmaintained.



I think would be nice to hear a word from Devin, which have been working in 
tvtime. Devin?


Sorry, I've been sick for the last couple of days and not actively on email.

I don't think it's a good idea to consolidate applications like xawtv
and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
nice because it's small and what the packages provides what it says it
does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
applications to be utilities.

The apps in question are currently packaged by multiple distros today
as standalone packages.  Today distros can decide whether they want
the bloat associated with large GUI applications just to get the
benefits of a couple of command line utilities.  Bundling them
together makes that much harder (and would also result in a package
with lots of external dependencies on third party libraries).

Adding them into v4l2-utils doesn't really solve the real problem -
that there are very few people willing to put in the effort to
extend/improve these applications (something which, as Douglas pointed
out, I'm trying to improve in the case of tvtime).


For unmaintained applications the problem is that even those people that
have patches for them have no easy way to get them applied, precisely because
they are unmaintained.

We as v4l-dvb developers don't have the time to make TV apps, but perhaps if
we 'adopted' one unmaintained application and just update that whenever we
make new features, then that would be very helpful I think. Or perhaps just
provide a place for such applications where there is someone who can take
community supplied patches and review and apply them.

Such an application does not have to be in v4l2-utils, it can have its own
tree.

Anyway, regarding alevt: I believe that the consensus is that it should be
moved to v4l2-utils? Or am I wrong?



I'm not in favor of moving alevt into v4l-utils, if there are
people who want to pick up its maintenance and host a separate tree for
it at linuxtv.org including doing regular tarbal releases for upstream to 
consume
that would seem a good idea to me.

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: v4l-utils: i2c-id.h and alevt

2010-03-12 Thread Hans de Goede

Hi,

On 03/11/2010 03:31 PM, Devin Heitmueller wrote:

On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
dougsl...@gmail.com  wrote:

On 03/10/2010 02:04 AM, hermann pitton wrote:

Hi Hans, both,

Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:

It's nice to see this new tree, that should be make it easier to develop
utilities!

After a quick check I noticed that the i2c-id.h header was copied from the
kernel. This is not necessary. The only utility that includes this is v4l2-dbg
and that one no longer needs it. Hans, can you remove this?

The second question is whether anyone would object if alevt is moved from
dvb-apps to v4l-utils? It is much more appropriate to have that tool in
v4l-utils.


i wonder that this stays such calm, hopefully a good sign.

In fact alevt analog should come with almost every distribution, but the
former alevt-dvb, named now only alevt, well, might be ok in some
future, is enhanced for doing also dvb-t-s and hence there ATM.


Does anyone know of other unmaintained but useful tools that we might merge
into v4l-utils? E.g. xawtv perhaps?


If for xawtv could be some more care, ships also since close to ever
with alevtd, that would be fine, but I'm not sure we are talking about
tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
example are also there and unmaintained.



I think would be nice to hear a word from Devin, which have been working in 
tvtime. Devin?


Sorry, I've been sick for the last couple of days and not actively on email.

I don't think it's a good idea to consolidate applications like xawtv
and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
nice because it's small and what the packages provides what it says it
does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
applications to be utilities.

The apps in question are currently packaged by multiple distros today
as standalone packages.  Today distros can decide whether they want
the bloat associated with large GUI applications just to get the
benefits of a couple of command line utilities.  Bundling them
together makes that much harder (and would also result in a package
with lots of external dependencies on third party libraries).

Adding them into v4l2-utils doesn't really solve the real problem -
that there are very few people willing to put in the effort to
extend/improve these applications (something which, as Douglas pointed
out, I'm trying to improve in the case of tvtime).



Ack,

What would be good to do IMHO is decide for unmaintained apps like xawtv
and alevt if we want to adopt them and if we do, to create separate git
trees for them, and become a new upstream including doing regular
tarbals releases. Some time ago I did a lot of work on the Fedora xawtv
packages and I would be willing to pull such an effort for xawtv.

If we start doing this we really should start running some sort of
bugtracker on linuxtv.org btw, or ask if we can use bugzilla.kernel.org
for this.

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: pushes at v4l-utils tree

2010-03-12 Thread Hans de Goede

Hi,

On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:

Hi Hans,

As we've agreed that the idea is to allow multiple people to commit at 
v4l-utils,
today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1 is 
.gitignore
stuff). One of the reasons were to test the viability for such commits.

I've temporarily enabled the same script that we use for upstream patches to
generate patches against linuxtv-commits ML.

 From my experiences, I have some notes:
1) git won't work fine if more than one is committing at the same tree.
The reason is simple: it won't preserve the same group as the previous commits. 
So,
the next committer will have troubles if we allow multiple committers;



I assume you are talking about some issues with permissions on the server side 
here ?


2) people need to pull/rebase before pushing, if we fix the group 
permission
issue above. I've enabled a hook that is meant to avoid rebase upstream, to 
prevent
troubles if people push something with -f. I hope it works fine.



Ack, actually I just did that (rebase my local tree before pushing) as you 
pushed
some changes before I did.


In summary, for now, I think that the better is to post all patches to 
v4l-utils at ML
and ask Hans to merge them.



Yes and no, if you've a few patches, sure. If you are doing regular development 
you should
get commit access. In my experience in various projects multiple people pushing 
to the
same git tree will work fine.

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: v4l-utils: i2c-id.h and alevt

2010-03-12 Thread Hans de Goede

Hi,

On 03/11/2010 03:14 PM, Douglas Schilling Landgraf wrote:

On 03/10/2010 02:04 AM, hermann pitton wrote:

Hi Hans, both,

Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:

It's nice to see this new tree, that should be make it easier to develop
utilities!

After a quick check I noticed that the i2c-id.h header was copied from the
kernel. This is not necessary. The only utility that includes this is v4l2-dbg
and that one no longer needs it. Hans, can you remove this?




I somehow missed the original mail from Hans Verkuil here, so I'm replying here,
sorry for messing up the threading.

Fixed!

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: v4l-utils: i2c-id.h and alevt

2010-03-12 Thread Manu Abraham
On Fri, Mar 12, 2010 at 7:40 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 03/11/2010 03:31 PM, Devin Heitmueller wrote:

 On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
 dougsl...@gmail.com  wrote:

 On 03/10/2010 02:04 AM, hermann pitton wrote:

 Hi Hans, both,

 Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:

 It's nice to see this new tree, that should be make it easier to
 develop
 utilities!

 After a quick check I noticed that the i2c-id.h header was copied from
 the
 kernel. This is not necessary. The only utility that includes this is
 v4l2-dbg
 and that one no longer needs it. Hans, can you remove this?

 The second question is whether anyone would object if alevt is moved
 from
 dvb-apps to v4l-utils? It is much more appropriate to have that tool in
 v4l-utils.

 i wonder that this stays such calm, hopefully a good sign.

 In fact alevt analog should come with almost every distribution, but the
 former alevt-dvb, named now only alevt, well, might be ok in some
 future, is enhanced for doing also dvb-t-s and hence there ATM.

 Does anyone know of other unmaintained but useful tools that we might
 merge
 into v4l-utils? E.g. xawtv perhaps?

 If for xawtv could be some more care, ships also since close to ever
 with alevtd, that would be fine, but I'm not sure we are talking about
 tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
 example are also there and unmaintained.


 I think would be nice to hear a word from Devin, which have been working
 in tvtime. Devin?

 Sorry, I've been sick for the last couple of days and not actively on
 email.

 I don't think it's a good idea to consolidate applications like xawtv
 and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
 nice because it's small and what the packages provides what it says it
 does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
 applications to be utilities.

 The apps in question are currently packaged by multiple distros today
 as standalone packages.  Today distros can decide whether they want
 the bloat associated with large GUI applications just to get the
 benefits of a couple of command line utilities.  Bundling them
 together makes that much harder (and would also result in a package
 with lots of external dependencies on third party libraries).

 Adding them into v4l2-utils doesn't really solve the real problem -
 that there are very few people willing to put in the effort to
 extend/improve these applications (something which, as Douglas pointed
 out, I'm trying to improve in the case of tvtime).


 Ack,


ACK

 What would be good to do IMHO is decide for unmaintained apps like xawtv
 and alevt if we want to adopt them and if we do, to create separate git
 trees for them, and become a new upstream including doing regular
 tarbals releases. Some time ago I did a lot of work on the Fedora xawtv
 packages and I would be willing to pull such an effort for xawtv.


Simply creating a tree for an application doesn't really help. At
least it needs a commitment to that app to keep it updated. Unless,
someone really puts in such an effort, creating a tree doesn't really
help, it simplyt adds to the confusion for a normal user as to where
he should download his application for his distro, if such a package
doesn't exist.


Regards,
Manu
--
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


[PULL] http://kernellabs.com/hg/~mkrufky/dvb-usb

2010-03-12 Thread Michael Krufky
Doug,

If possible, would you pull this changeset from my hg tree rather than
doing a git backport, after Mauro merges this?  If possible, I'd like
to retain the hash value of this changeset so that I don't have to
rebuild all of my development trees.  If you can do this for me, I'd
really appreciate it.  If a more detailed explanation of why I am
making this request is required, please say so and I'll explain in
further detail.

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/dvb-usb

for:

- dvb-usb: enable specifying a separate generic bulk ctrl response endpoint

 dvb-usb-urb.c |2 ++
 dvb-usb.h |7 +++
 2 files changed, 9 insertions(+)

This opens the door to make the dvb-usb framework more generic to be
able to support a variety of additional new devices.  It also will
allow us to cleanup / remove some redundant code in some existing
dvb-usb drivers.  After this is merged, cleanup patches on existing
drivers will follow.

Thanks  regards,

Mike Krufky
--
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] http://kernellabs.com/hg/~mkrufky/dvb-usb

2010-03-12 Thread Douglas Schilling Landgraf

Hey Michael,

Michael Krufky wrote:

Doug,

If possible, would you pull this changeset from my hg tree rather than
doing a git backport, after Mauro merges this?  If possible, I'd like
to retain the hash value of this changeset so that I don't have to
rebuild all of my development trees.  If you can do this for me, I'd
really appreciate it.  If a more detailed explanation of why I am
making this request is required, please say so and I'll explain in
further detail.


Sure.

Cheers
Douglas



Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/dvb-usb

for:

- dvb-usb: enable specifying a separate generic bulk ctrl response endpoint

 dvb-usb-urb.c |2 ++
 dvb-usb.h |7 +++
 2 files changed, 9 insertions(+)

This opens the door to make the dvb-usb framework more generic to be
able to support a variety of additional new devices.  It also will
allow us to cleanup / remove some redundant code in some existing
dvb-usb drivers.  After this is merged, cleanup patches on existing
drivers will follow.

Thanks  regards,

Mike Krufky


--
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: DNTV Dual Hybrid (7164) PCIe

2010-03-12 Thread Jed

Judging by the silence I'm guessing that's a negative  ;-)

I actually had a closer read of this...
http://www.kernellabs.com/blog/?p=1339

So even if I donated a card I guess that's not going to compensate you
nearly enough to get analogue a/v-in at least partially working?

So it seems I went for a bells  whistles card which may never be 
fully supported. I seem to recall having the same experience

with a prior card, I wonder if I'll ever learn!

Are there any tuners with similar raw analogue capture/encoding
abilities (ideally component-in) that you do support more completely or
intend to?

Or should I be looking at dedicated video capture devices for better
linux-media support?

Thank-you

Jed wrote:

By analogue side I mainly mean A/V-in
Thank-you/Good night

Jed wrote:

Actually I'd be happy to donate...
So long as I knew there'd be some progress on the analogue side.
Already got the HVR-2200 for DVB.

Jed wrote:

Happy to do this, so long as I can get it back eventually?

Steven Toth wrote:

On 3/11/10 11:26 AM, Jed wrote:

Hi Kernellabs,

I'm thinking of getting this:
http://forums.dvbowners.com/index.php?showtopic=11720
It seems very similar to the HVR-2200 yet has component-in.
Do you reckon your module/s might support it?

Thank-you!


Highly likely the drivers will not support it. Each card has unique
firmware identifiers that need to be added manually to the driver.

If you'd like to provide me a card then I'd consider adding support.

- Steve










--
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: Hw capabilities of the HVR-2200

2010-03-12 Thread Jed

19/09/09 Jed wrote:

2) Component input for the A/V-in


Yes, this exists on the HVR2250 product only.


Ah shite, are you sure?
If you look at the specs for the reference card it was there, did they
take it out at the last minute?


It's not feature Hauppauge supports on the HVR2200 today. I have a
suspicion this may change but I'm neither confirming, denying or
announcing anything. It would make sense to officially support
component cables on the HVR2200 since the silicon supports it.
If/when it does I'm sure it will be mentioned in the forums or on the
HVR2200 product packaging.


Hi Steve, when you said this is not a feature Hauppauge supports.
Did you mean it's not fully enabled physically in the PCB...
Or is it just something they need to add support for in the driver?
If the latter do you know if their policy has changed or is about to?


No idea, I have no answer.


Considering that in the specs for the reference card it was highlighted
as part of the silicon... Wouldn't it be safe to assume that it's
something that'd be unlocked by drivers?

But if that were true, what is their motivation in not wanting to enable
it? (assuming they still haven't)


3) Hw encode bypass for A/V-in


No idea. Regardless of whether it does or does not I wouldn't plan to
add basic raw TV support to the driver, without going through the
encoder.


Why do you rule it out unequivocally, is it just because I've annoyed
you? :-(


Raw analog TV isn't a high priority feature on my mental check-list.
Analog TV via the encoder is much more interesting and applicable to
many people.


Assuming that progress has been made on analogue to
h.263/mpeg4/VC-1/DivX/Xvid via the A/V-in encoder.
Is this still considered a low priority?


Raw analog is still very low down any list I have for the HVR22xx driver.



Has progress been made on hw encode via A/V-in?
I'm finally putting my entire system together soon, can't wait!
Looking forward to seeing how everything has progressed.
I'll be sure to do some donations once I'm up  running!


The current driver supports DTV only. I have no ETA for analog on the
HVR22xx driver. If you need analog support then the HVR22xx isn't the
right product for you.


--
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: [linux-dvb] Twinhan dtv 3030 mantis

2010-03-12 Thread Niklas Claesson
I saw that there has been som recent development on the
mantis-v4l-dvb-tree. Unfortunately it still doesn't work for my 3030.
Is there anyway I can help? Is it normal that the IRQ 23 is used with
more then one card?

Mar 12 18:19:03 niklas-desktop kernel: [  254.410969] Mantis
:05:02.0: PCI INT A - GSI 23 (level, low) - IRQ 23
Mar 12 18:19:03 niklas-desktop kernel: [  254.411971] DVB: registering
new adapter (Mantis DVB adapter)
Mar 12 18:19:04 niklas-desktop kernel: [  255.084297] Mantis: probe of
:05:02.0 failed with error -1

Regards,
Niklas Claesson


2010/2/11 Manu Abraham abraham.m...@gmail.com

 Can you please try again ?

 Regards,
 Manu
 --
 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
--
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: Hw capabilities of the HVR-2200

2010-03-12 Thread Devin Heitmueller
On Fri, Mar 12, 2010 at 12:26 PM, Jed jedi.the...@gmail.com wrote:
 Considering that in the specs for the reference card it was highlighted
 as part of the silicon... Wouldn't it be safe to assume that it's
 something that'd be unlocked by drivers?

 But if that were true, what is their motivation in not wanting to enable
 it? (assuming they still haven't)

The features of a given piece of silicon do not always match what a
company has ultimately licensed.  This is especially true for things
like codec support which can have significant royalties that have to
be paid.  Hence it's possible that while the chip *in theory* could
support some particular codec, that doesn't mean that the firmware
that ultimately got licensed has the necessary support.

Regarding component support, it's entirely possible that although the
chip supports it, it may have been cost prohibitive to put the
supporting hardware on the PCB.  It's ultimately up to the product
vendor to decide what subset of the functionality on the reference
design to ship with.

Of course, everything I said in the above is complete speculation
(based on my own previous experience working for a company that makes
hardware), as I have no actual knowledge of why they chose to take the
approach they did.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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


Analog (PAL) PCI or PCIe with MPEG HW encoder

2010-03-12 Thread RoboSK
Hi, exist Analog (PAL) PCI or PCIe with MPEG HW encoder card that is 
supported into linux and is still possible purchase this card into shop 
(as new)?


thanks

Robo
--
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: pushes at v4l-utils tree

2010-03-12 Thread Mauro Carvalho Chehab
Hans de Goede wrote:
 Hi,
 
 On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
 Hi Hans,

 As we've agreed that the idea is to allow multiple people to commit at
 v4l-utils,
 today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1
 is .gitignore
 stuff). One of the reasons were to test the viability for such commits.

 I've temporarily enabled the same script that we use for upstream
 patches to
 generate patches against linuxtv-commits ML.

  From my experiences, I have some notes:
 1) git won't work fine if more than one is committing at the same
 tree.
 The reason is simple: it won't preserve the same group as the previous
 commits. So,
 the next committer will have troubles if we allow multiple committers;

 
 I assume you are talking about some issues with permissions on the
 server side here ?

Yes. The new objects and the touched files got a different group ownership
after git push. I had to manually fix them at the server.

 In summary, for now, I think that the better is to post all patches to
 v4l-utils at ML
 and ask Hans to merge them.

 
 Yes and no, if you've a few patches, sure. If you are doing regular
 development you should
 get commit access. In my experience in various projects multiple people
 pushing to the
 same git tree will work fine.

We need to see how they're fixing the permissions. I suspect that they have
some post-update script that redo the proper file permissions. Do you know
what they use?

-- 

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: Analog (PAL) PCI or PCIe with MPEG HW encoder

2010-03-12 Thread RoboSK
i need only two analog input = one (dual) or two (single) card :( - 
but i hope that TBS find market for this card...


thanks
Robo


On 12. 3. 2010 20:00, Konstantin Dimitrov wrote:

hello Robo,

i know TurboSight (TBS) have PCI-Express MPEG-2 HW encoder card (with RCA
Composite Video Input and RCA Right and Left stereo audio inputs) that works
in Linux, because i made the Linux driver for it.however, it's just a
prototype and if you need only one such card their sales department won't be
interested to produce a single piece, but if you need many you have a change
and you can speak with them on: sa...@tbsdtv.com they don't produce the card
right now exactly, because there is no market for such cards, but it's ready
product that was design especially for use in Linux.

regards,
konstantin

2010/3/12 RoboSKucet.na.disku...@gmail.com


Hi, exist Analog (PAL) PCI or PCIe with MPEG HW encoder card that is
supported into linux and is still possible purchase this card into shop (as
new)?

thanks

Robo
--
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





--
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


[GIT PATCHES FOR 2.6.34] sn9c20x patches

2010-03-12 Thread Brian Johnson
The following changes since commit 9178a7c062ff0c43e95d826419f9e9454c52ef15:
  Mauro Carvalho Chehab (1):
V4L/DVB: Fix bad whitespacing

are available in the git repository at:

  git://gitorious.org/v4l-dvb/v4l-dvb.git devel

Brian Johnson (5):
  gspca - sn9c20x: use gspca's input device handling
  gspca - sn9c20x: Add support for camera LEDs
  gspca - sn9c20x: Add upside down detection
  gspca - sn9c20x: Add support for cameras using the MT9M112 sensor
  gspca - sn9c20x: Fix bug with OV9655 code

 Documentation/video4linux/gspca.txt |4 +
 drivers/media/video/gspca/Kconfig   |6 -
 drivers/media/video/gspca/sn9c20x.c |  311 +--
 3 files changed, 155 insertions(+), 166 deletions(-)

Brian Johnson
--
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


Remaining drivers that aren't V4L2?

2010-03-12 Thread Devin Heitmueller
Hello,

I know some months ago, there was some discussion about a few drivers
which were stragglers and had not been converted from V4L to V4L2.

Do we have a current list of driver which still haven't been converted?

I started doing some more tvtime work last night, and I would *love*
to drop V4L support (and *only* support V4L2 devices), since it would
make the code much cleaner, more reliable, and easier to test.

If there are only a few obscure webcams remaining, then I'm willing to
tell those users that they have to stick with whatever old version of
tvtime they've been using since the last release four years ago.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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


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

2010-03-12 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:Fri Mar 12 19:00:11 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14420:0d06fd6b500e
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

linux-2.6.32.6-armv5: OK
linux-2.6.33-armv5: OK
linux-2.6.34-rc1-armv5: OK
linux-2.6.32.6-armv5-davinci: OK
linux-2.6.33-armv5-davinci: OK
linux-2.6.34-rc1-armv5-davinci: OK
linux-2.6.32.6-armv5-ixp: OK
linux-2.6.33-armv5-ixp: OK
linux-2.6.34-rc1-armv5-ixp: OK
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-armv5-omap2: OK
linux-2.6.34-rc1-armv5-omap2: OK
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.17-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.20-i686: WARNINGS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-rc1-i686: WARNINGS
linux-2.6.32.6-m32r: OK
linux-2.6.33-m32r: OK
linux-2.6.34-rc1-m32r: OK
linux-2.6.32.6-mips: OK
linux-2.6.33-mips: OK
linux-2.6.34-rc1-mips: OK
linux-2.6.32.6-powerpc64: WARNINGS
linux-2.6.33-powerpc64: WARNINGS
linux-2.6.34-rc1-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.17-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.20-x86_64: WARNINGS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-rc1-x86_64: WARNINGS
linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
spec: ERRORS
spec-git: OK
sparse: ERRORS
linux-2.6.16.62-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.7-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: OK
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.7-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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: [linux-dvb] Twinhan dtv 3030 mantis

2010-03-12 Thread Manu Abraham
On Fri, Mar 12, 2010 at 9:27 PM, Niklas Claesson
nicke.claes...@gmail.com wrote:
 I saw that there has been som recent development on the
 mantis-v4l-dvb-tree. Unfortunately it still doesn't work for my 3030.
 Is there anyway I can help? Is it normal that the IRQ 23 is used with
 more then one card?

That shouldn't be a problem. A shared handler is requested.

 Mar 12 18:19:03 niklas-desktop kernel: [  254.410969] Mantis
 :05:02.0: PCI INT A - GSI 23 (level, low) - IRQ 23
 Mar 12 18:19:03 niklas-desktop kernel: [  254.411971] DVB: registering
 new adapter (Mantis DVB adapter)
 Mar 12 18:19:04 niklas-desktop kernel: [  255.084297] Mantis: probe of
 :05:02.0 failed with error -1


Can you please load the mantis driver with module option verbose=5 and
post the details ?

Regards,
Manu
--
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: [linux-dvb] Twinhan dtv 3030 mantis

2010-03-12 Thread Niklas Claesson
2010/3/12 Manu Abraham abraham.m...@gmail.com:

 Can you please load the mantis driver with module option verbose=5 and
 post the details ?

 Regards,
 Manu


Here you go:

Mar 12 21:49:29 niklas-desktop kernel: [   70.660177] found a VP-3030
PCI DVB-T device on (05:02.0),
Mar 12 21:49:29 niklas-desktop kernel: [   70.660188] Mantis
:05:02.0: PCI INT A - GSI 23 (level, low) - IRQ 23
Mar 12 21:49:29 niklas-desktop kernel: [   70.660207] Mantis Rev 1
[1822:0024], irq: 23, latency: 64
Mar 12 21:49:29 niklas-desktop kernel: [   70.660210] memory: 0x0,
mmio: 0xf86ce000
Mar 12 21:49:29 niklas-desktop kernel: [   70.660218]
mantis_stream_control (0): Set stream to HIF
Mar 12 21:49:29 niklas-desktop kernel: [   70.660245] mantis_i2c_init
(0): Initializing I2C ..
Mar 12 21:49:29 niklas-desktop kernel: [   70.660248] mantis_i2c_init
(0): Disabling I2C interrupt
Mar 12 21:49:29 niklas-desktop kernel: [   70.660252] mantis_i2c_xfer
(0): Messages:2
Mar 12 21:49:29 niklas-desktop kernel: [   70.660254]
mantis_i2c_write: Address=[0x50] W[ 08 ]
Mar 12 21:49:29 niklas-desktop kernel: [   70.660474]
mantis_i2c_read:  Address=[0x50] R[ 00 08 ca 1a 4d f6 ]
Mar 12 21:49:29 niklas-desktop kernel: [   70.661200] MAC
Address=[00:08:ca:1a:4d:f6]
Mar 12 21:49:29 niklas-desktop kernel: [   70.661202] mantis_dma_init
(0): Mantis DMA init
Mar 12 21:49:29 niklas-desktop kernel: [   70.661219]
mantis_alloc_buffers (0): DMA=0x3630 cpu=0xf630 size=65536
Mar 12 21:49:29 niklas-desktop kernel: [   70.661223]
mantis_alloc_buffers (0): RISC=0x34d99000 cpu=0xf4d99000 size=1000
Mar 12 21:49:29 niklas-desktop kernel: [   70.661226]
mantis_calc_lines (0): Mantis RISC block bytes=[4096], line
bytes=[2048], line count=[32]
Mar 12 21:49:29 niklas-desktop kernel: [   70.661228] mantis_dvb_init
(0): dvb_register_adapter
Mar 12 21:49:29 niklas-desktop kernel: [   70.661230] DVB: registering
new adapter (Mantis DVB adapter)
Mar 12 21:49:29 niklas-desktop kernel: [   70.661232] mantis_dvb_init
(0): dvb_dmx_init
Mar 12 21:49:29 niklas-desktop kernel: [   70.661304] mantis_dvb_init
(0): dvb_dmxdev_init
Mar 12 21:49:29 niklas-desktop kernel: [   70.661434] gpio_set_bits
(0): Set Bit 13 to 0
Mar 12 21:49:29 niklas-desktop kernel: [   70.661437] gpio_set_bits
(0): GPIO Value 00
Mar 12 21:49:29 niklas-desktop kernel: [   70.764121]
mantis_frontend_power (0): Power ON
Mar 12 21:49:29 niklas-desktop kernel: [   70.764127] gpio_set_bits
(0): Set Bit 12 to 1
Mar 12 21:49:29 niklas-desktop kernel: [   70.764131] gpio_set_bits
(0): GPIO Value 1000
Mar 12 21:49:29 niklas-desktop kernel: [   70.868076] gpio_set_bits
(0): Set Bit 12 to 1
Mar 12 21:49:29 niklas-desktop kernel: [   70.868081] gpio_set_bits
(0): GPIO Value 1000
Mar 12 21:49:29 niklas-desktop kernel: [   71.076032] gpio_set_bits
(0): Set Bit 13 to 1
Mar 12 21:49:29 niklas-desktop kernel: [   71.076037] gpio_set_bits
(0): GPIO Value 3000
Mar 12 21:49:29 niklas-desktop kernel: [   71.332045]
vp3030_frontend_init (0): Probing for 10353 (DVB-T)
Mar 12 21:49:29 niklas-desktop kernel: [   71.332051] mantis_i2c_xfer
(0): Messages:2
Mar 12 21:49:29 niklas-desktop kernel: [   71.332053] Byte MODE:
Mar 12 21:49:29 niklas-desktop kernel: [   71.332056] Byte 0
RXD=0x1f7f0080  [00]
Mar 12 21:49:29 niklas-desktop kernel: [   71.332059] mantis_dvb_init
(0): !!! NO Frontends found !!!
Mar 12 21:49:29 niklas-desktop kernel: [   71.334430] mantis_dvb_init
(0): ERROR! Adapter unregistered
Mar 12 21:49:29 niklas-desktop kernel: [   71.334433] mantis_pci_probe
(0): ERROR: Mantis DVB initialization failed -1
Mar 12 21:49:29 niklas-desktop kernel: [   71.334448] Mantis: probe of
:05:02.0 failed with error -1

Regards,
Niklas Claesson
--
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: pushes at v4l-utils tree

2010-03-12 Thread Antonio Ospite
On Fri, 12 Mar 2010 16:29:46 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:

 Hans de Goede wrote:
  Hi,
  
  On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
  Hi Hans,
 
  As we've agreed that the idea is to allow multiple people to commit at
  v4l-utils,
  today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1
  is .gitignore
  stuff). One of the reasons were to test the viability for such commits.
 
  I've temporarily enabled the same script that we use for upstream
  patches to
  generate patches against linuxtv-commits ML.
 
   From my experiences, I have some notes:
  1) git won't work fine if more than one is committing at the same
  tree.
  The reason is simple: it won't preserve the same group as the previous
  commits. So,
  the next committer will have troubles if we allow multiple committers;
 
  
  I assume you are talking about some issues with permissions on the
  server side here ?
 
 Yes. The new objects and the touched files got a different group ownership
 after git push. I had to manually fix them at the server.
 

The following might be inappropriate, as I didn't follow the discussion
about the linuxtv git infrastructure.

Using gitosis[1,2] these permission issues shouldn't occur, because only
one user (usually git) actually writes to the filesystem while commit
rights are still handled with ssh pubkeys, and this doesn't even
require creating users on the server.

As I said I don't know if you are using gitosis already, if so then
sorry for the noise.

Regards,
   Antonio

[1] http://eagain.net/gitweb/?p=gitosis.git
[2] http://ao2.it/wiki/How_to_setup_a_GIT_server_with_gitosis_and_gitweb

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


pgpguaTYsTJka.pgp
Description: PGP signature


Re: Remaining drivers that aren't V4L2?

2010-03-12 Thread Hans Verkuil
On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:
 Hello,
 
 I know some months ago, there was some discussion about a few drivers
 which were stragglers and had not been converted from V4L to V4L2.
 
 Do we have a current list of driver which still haven't been converted?

These drivers are still v4l1:

arv
bw-qcam
c-qcam
cpia_pp
cpia_usb
ov511
se401
stradis
stv680
usbvideo
w9966

Some of these have counterparts in gspca these days so possibly some drivers
can be removed by now. Hans, can you point those out?

arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
and if no one steps up then they can be dropped altogether.

According to my notes I should be able to test cpia_usb. I would have to
verify that, though. I think it is only used in a USB microscope. It is
effectively a webcam. I can also test usbvideo (USB 1 TV capture device).
The latter is probably the most important driver that needs converting,
because I think these are not uncommon.

However, I have no time to work on such a driver conversion. But if someone
is seriously willing to put time and effort in that, then I am willing to
mail the hardware.

 I started doing some more tvtime work last night, and I would *love*
 to drop V4L support (and *only* support V4L2 devices), since it would
 make the code much cleaner, more reliable, and easier to test.
 
 If there are only a few obscure webcams remaining, then I'm willing to
 tell those users that they have to stick with whatever old version of
 tvtime they've been using since the last release four years ago.

To my knowledge the usbvideo driver is probably the least obscure device
that is still using V4L1.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: Analog (PAL) PCI or PCIe with MPEG HW encoder

2010-03-12 Thread Hans Verkuil
On Friday 12 March 2010 18:57:39 RoboSK wrote:
 Hi, exist Analog (PAL) PCI or PCIe with MPEG HW encoder card that is 
 supported into linux and is still possible purchase this card into shop 
 (as new)?

I see that the Hauppauge PVR-150 is still available (ivtv driver).

These cards certainly work. There are also newer HVR cards from Hauppauge,
but I'm not 100% certain which are fully supported by linux with respect to
MPEG encoding.

Regards,

Hans

 
 thanks
 
 Robo
 --
 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
 
 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: Remaining drivers that aren't V4L2?

2010-03-12 Thread Devin Heitmueller
On Fri, Mar 12, 2010 at 5:20 PM, Michael Akey ak...@onid.orst.edu wrote:
 Hans Verkuil wrote:
 These drivers are still v4l1:

 arv
 bw-qcam
 c-qcam
 cpia_pp
 cpia_usb
 ov511
 se401
 stradis
 stv680
 usbvideo
 w9966

 Some of these have counterparts in gspca these days so possibly some
 drivers
 can be removed by now. Hans, can you point those out?

 arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
 and if no one steps up then they can be dropped altogether.


 Does this mean that the bw-qcam driver will be removed in future revisions
 or does this mean it will just never be updated to v4l2?

Hans is suggesting that support for those devices would be dropped
entirely if no developer steps up to convert them to v4l2.

The problem is that supporting the long deprecated API is a burden
that makes it much harder to extend certain aspects of the internal
code.  If we were able to drop those devices, it would be much easier
to improve all the other drivers (of which the *vast* majority have
been converted to v4l2).

It's been over ten years since v4l2 came out.  If nobody has converted
those drivers to v4l2, then it's safe to say it's probably never going
to happen.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: Remaining drivers that aren't V4L2?

2010-03-12 Thread Michael Akey

Hans Verkuil wrote:

On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:
  

Hello,

I know some months ago, there was some discussion about a few drivers
which were stragglers and had not been converted from V4L to V4L2.

Do we have a current list of driver which still haven't been converted?



These drivers are still v4l1:

arv
bw-qcam
c-qcam
cpia_pp
cpia_usb
ov511
se401
stradis
stv680
usbvideo
w9966

Some of these have counterparts in gspca these days so possibly some drivers
can be removed by now. Hans, can you point those out?

arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
and if no one steps up then they can be dropped altogether.
  


Does this mean that the bw-qcam driver will be removed in future 
revisions or does this mean it will just never be updated to v4l2?



According to my notes I should be able to test cpia_usb. I would have to
verify that, though. I think it is only used in a USB microscope. It is
effectively a webcam. I can also test usbvideo (USB 1 TV capture device).
The latter is probably the most important driver that needs converting,
because I think these are not uncommon.

However, I have no time to work on such a driver conversion. But if someone
is seriously willing to put time and effort in that, then I am willing to
mail the hardware.

  

I started doing some more tvtime work last night, and I would *love*
to drop V4L support (and *only* support V4L2 devices), since it would
make the code much cleaner, more reliable, and easier to test.

If there are only a few obscure webcams remaining, then I'm willing to
tell those users that they have to stick with whatever old version of
tvtime they've been using since the last release four years ago.



To my knowledge the usbvideo driver is probably the least obscure device
that is still using V4L1.

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: Remaining drivers that aren't V4L2?

2010-03-12 Thread Hans Verkuil
On Friday 12 March 2010 23:20:44 Michael Akey wrote:
 Hans Verkuil wrote:
  On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:

  Hello,
 
  I know some months ago, there was some discussion about a few drivers
  which were stragglers and had not been converted from V4L to V4L2.
 
  Do we have a current list of driver which still haven't been converted?
  
 
  These drivers are still v4l1:
 
  arv
  bw-qcam
  c-qcam
  cpia_pp
  cpia_usb
  ov511
  se401
  stradis
  stv680
  usbvideo
  w9966
 
  Some of these have counterparts in gspca these days so possibly some drivers
  can be removed by now. Hans, can you point those out?
 
  arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
  and if no one steps up then they can be dropped altogether.

 
 Does this mean that the bw-qcam driver will be removed in future 
 revisions or does this mean it will just never be updated to v4l2?

Removal. At least, that is what I would propose. Greg KH has proposed some time
ago to use the staging tree not only for incoming but also for outgoing drivers.

And drivers that have not seen any development for years and that nobody seems
to be using and where the hardware is obsolete are definitely candidates for
this removal process.

I suspect that the only two drivers that we might need to keep are usbvideo and
cpia_usb. The latter is still used in hardware you can buy today, the same may
also be true of the first, and products supported by the usbvideo driver are
certainly still out there.

If we are indeed left with just two V4L1 drivers that cannot easily be removed,
then we should perhaps try to convert them after all, even though it is hard to
be motivated to do that work.

I definitely agree with Devin that it would be really great to finally remove
the V4L1 support completely from the kernel.

Regards,

Hans

 
  According to my notes I should be able to test cpia_usb. I would have to
  verify that, though. I think it is only used in a USB microscope. It is
  effectively a webcam. I can also test usbvideo (USB 1 TV capture device).
  The latter is probably the most important driver that needs converting,
  because I think these are not uncommon.
 
  However, I have no time to work on such a driver conversion. But if someone
  is seriously willing to put time and effort in that, then I am willing to
  mail the hardware.
 

  I started doing some more tvtime work last night, and I would *love*
  to drop V4L support (and *only* support V4L2 devices), since it would
  make the code much cleaner, more reliable, and easier to test.
 
  If there are only a few obscure webcams remaining, then I'm willing to
  tell those users that they have to stick with whatever old version of
  tvtime they've been using since the last release four years ago.
  
 
  To my knowledge the usbvideo driver is probably the least obscure device
  that is still using V4L1.
 
  Regards,
 
  Hans
 

 
 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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 2/5] drivers/media/video: move dereference after NULL test

2010-03-12 Thread Karicheri, Muralidharan
For drivers/media/video/davinci/vpif_display.c

Acked-by: Muralidharan Karicheri m-kariche...@ti.com

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

-Original Message-
From: Julia Lawall [mailto:ju...@diku.dk]
Sent: Friday, March 12, 2010 4:16 AM
To: Karicheri, Muralidharan
Cc: a...@linux-foundation.org; mche...@infradead.org; linux-
me...@vger.kernel.org
Subject: RE: [patch 2/5] drivers/media/video: move dereference after NULL
test

From: Julia Lawall ju...@diku.dk

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.  Test std_info-stdid instead.

In saa7134-alsa.c, the function is only called from one place, where the
chip argument has already been dereferenced.  On the other hand, if it
should be kept, then card should be initialized after it.

A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):

// smpl
@match exists@
expression x, E;
identifier fld;
@@

* x-fld
  ... when != \(x = E\|x\)
* x == NULL
// /smpl

Signed-off-by: Julia Lawall ju...@diku.dk

---
 drivers/media/video/davinci/vpif_display.c|2 +-
 drivers/media/video/saa7134/saa7134-alsa.c|2 --
 drivers/media/video/usbvideo/quickcam_messenger.c |3 ++-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/usbvideo/quickcam_messenger.c
b/drivers/media/video/usbvideo/quickcam_messenger.c
index 803d3e4..f0043d0 100644
--- a/drivers/media/video/usbvideo/quickcam_messenger.c
+++ b/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -692,12 +692,13 @@ static int qcm_start_data(struct uvd *uvd)

 static void qcm_stop_data(struct uvd *uvd)
 {
-  struct qcm *cam = (struct qcm *) uvd-user_data;
+  struct qcm *cam;
   int i, j;
   int ret;

   if ((uvd == NULL) || (!uvd-streaming) || (uvd-dev == NULL))
   return;
+  cam = (struct qcm *) uvd-user_data;

   ret = qcm_camera_off(uvd);
   if (ret)
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
index d48c450..d3bd82a 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -1011,8 +1011,6 @@ static int
snd_card_saa7134_new_mixer(snd_card_saa7134_t * chip)
   unsigned int idx;
   int err, addr;

-  if (snd_BUG_ON(!chip))
-  return -EINVAL;
   strcpy(card-mixername, SAA7134 Mixer);

   for (idx = 0; idx  ARRAY_SIZE(snd_saa7134_volume_controls); idx++) {
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index dfddef7..b2dce78 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -383,7 +383,7 @@ static int vpif_get_std_info(struct channel_obj *ch)
   int index;

   std_info-stdid = vid_ch-stdid;
-  if (!std_info)
+  if (!std_info-stdid)
   return -1;

   for (index = 0; index  ARRAY_SIZE(ch_params); index++) {
--
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: Remaining drivers that aren't V4L2?

2010-03-12 Thread Mauro Carvalho Chehab
Hans Verkuil wrote:
 On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:
 Hello,

 I know some months ago, there was some discussion about a few drivers
 which were stragglers and had not been converted from V4L to V4L2.

 Do we have a current list of driver which still haven't been converted?
 
 These drivers are still v4l1:
 
 arv
 bw-qcam
 c-qcam
 cpia_pp
 cpia_usb
 ov511
 se401
 stradis
 stv680
 usbvideo
 w9966

All the above are webcam drivers. I doubt that those drivers would work
with tvtime: this software were meant to test the Vector's deinterlacing
algorithms, so it requires some specific video formats/resolutions found on TV
and require 25 or 30 fps, as far as I remember. For example, It doesn't support
QCIF/QVGA cameras.

If you want to extend tvtime to use webcams, some work is needed. Probably the 
easiest
way would be to use libv4l, that also does the V4L1 conversion, if needed. This 
may
actually make sense even for a few TV cards like em28xx, where you could use a 
bayer
format with a lower color depth and/or lower resolution, in order to allow 
viewing two 
simultaneous streams.

So, I suggest you to just drop V4L1 from tvtime and convert it to use libv4l 
(the conversion
is trivial: just replace open/close/ioctl from the V4L2 driver to the libv4l 
ones). This will
allow you to drop the old V4L1 driver from it, and, if you decide later to 
accept other
resolutions and make it more webcam friendly, you'll just need to allow tvtime 
to accept
other video resolutions and disable the de-interlacing setup if a webcam is 
detected.

-- 

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: Remaining drivers that aren't V4L2?

2010-03-12 Thread Devin Heitmueller
On Fri, Mar 12, 2010 at 5:52 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 All the above are webcam drivers. I doubt that those drivers would work
 with tvtime: this software were meant to test the Vector's deinterlacing
 algorithms, so it requires some specific video formats/resolutions found on TV
 and require 25 or 30 fps, as far as I remember. For example, It doesn't 
 support
 QCIF/QVGA cameras.

Yup, I was indeed aware that tvtime doesn't really work with webcams.
I wanted to see the list of remaining drivers, and now that I see the
list (and also came to the conclusion that they were all webcams), I
feel much more comfortable just dropping V4L1 support.

 If you want to extend tvtime to use webcams, some work is needed. Probably 
 the easiest
 way would be to use libv4l, that also does the V4L1 conversion, if needed. 
 This may
 actually make sense even for a few TV cards like em28xx, where you could use 
 a bayer
 format with a lower color depth and/or lower resolution, in order to allow 
 viewing two
 simultaneous streams.

 So, I suggest you to just drop V4L1 from tvtime and convert it to use libv4l 
 (the conversion
 is trivial: just replace open/close/ioctl from the V4L2 driver to the libv4l 
 ones). This will
 allow you to drop the old V4L1 driver from it, and, if you decide later to 
 accept other
 resolutions and make it more webcam friendly, you'll just need to allow 
 tvtime to accept
 other video resolutions and disable the de-interlacing setup if a webcam is 
 detected.

I have actually been considering converting tvtime to using libv4l for
a while now, as I need it to support cards that use the HM12
pixelformat (such as the HVR-1600).  I wanted to rip out the V4L1
support first to make the conversion more straightforward.

It really isn't my goal to make tvtime support webcams, although they
might just start to work as an unintended side-effect.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: Remaining drivers that aren't V4L2?

2010-03-12 Thread Mauro Carvalho Chehab
Devin Heitmueller wrote:
 On Fri, Mar 12, 2010 at 5:52 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:

 Yup, I was indeed aware that tvtime doesn't really work with webcams.
 I wanted to see the list of remaining drivers, and now that I see the
 list (and also came to the conclusion that they were all webcams), I
 feel much more comfortable just dropping V4L1 support.

Yep. For its target, V4L1 is not needed anymore.

 I have actually been considering converting tvtime to using libv4l for
 a while now, as I need it to support cards that use the HM12
 pixelformat (such as the HVR-1600).  I wanted to rip out the V4L1
 support first to make the conversion more straightforward.
 
 It really isn't my goal to make tvtime support webcams, although they
 might just start to work as an unintended side-effect.

If you take the right decisions with tvtime, you'll end to have it allowing
webcams, even unintentionally.

For example, on a quick brainstorming, I see some interesting features for
the tvtime todo list (just my $0,01 cents):

1) alsa support (undergoing/finished work?);

2) allow adjusting frame rate, to better support environments where the bus 
bandwidth is limited;

3) support for other video formats;

4) a generic control interface (a qv4l2 like interface);

5) support to adjust the resolution based on the screen size (as xawtv does);

6) allow tvtime to record programs;

7) direct access to IR event interface, in order to better work with IR's 
without
needing any extra software like lirc;

8) allow changing video standard without needing to restart tvtime. It is very 
common
on some Countries the usage of two or more simultaneous standard - For example, 
almost
all DVD/STB devices in Brazil outputs in NTSC, while TV is broadcasted in 
PAL-M. As far
as I know, the other Countries where Analog TV is still the main/only broadcast 
standard
have similar issues.

For sure the top priority is Alsa, but, at the end of the day, by handling 
(some) of the
above requirements, its usage with webcams will make more sense, and you won't 
need to
spend any time specifically devoted to webcam support.

Also, assuming that analog TV will end broadcasting some day in the world, the 
usage for
a tvtime-like application will likely be for video surveillance and other 
webcam usages.

So, in brief, I think a webcam support side-effect is a good thing.

-- 

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


[PATCH 3/4] V4L/DVB: ir-core: Export IR name via uevent

2010-03-12 Thread Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index c9c0a54..31f22ba 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -418,6 +418,7 @@ int ir_input_register(struct input_dev *input_dev,
 
spin_lock_init(ir_dev-rc_tab.lock);
 
+   ir_dev-rc_tab.name = rc_tab-name;
ir_dev-rc_tab.size = ir_roundup_tablesize(rc_tab-size);
ir_dev-rc_tab.scan = kzalloc(ir_dev-rc_tab.size *
sizeof(struct ir_scancode), GFP_KERNEL);
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index 1bb011a..0f4da05 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -125,6 +125,24 @@ static ssize_t store_protocol(struct device *d,
return len;
 }
 
+
+#define ADD_HOTPLUG_VAR(fmt, val...)   \
+   do {\
+   int err = add_uevent_var(env, fmt, val);\
+   if (err)\
+   return err; \
+   } while (0)
+
+static int ir_dev_uevent(struct device *device, struct kobj_uevent_env *env)
+{
+   struct ir_input_dev *ir_dev = dev_get_drvdata(device);
+
+   if (ir_dev-rc_tab.name)
+   ADD_HOTPLUG_VAR(NAME=\%s\, ir_dev-rc_tab.name);
+
+   return 0;
+}
+
 /*
  * Static device attribute struct with the sysfs attributes for IR's
  */
@@ -137,7 +155,7 @@ static struct attribute *ir_dev_attrs[] = {
 };
 
 static struct attribute_group ir_dev_attr_grp = {
-   .attrs  =ir_dev_attrs,
+   .attrs  = ir_dev_attrs,
 };
 
 static const struct attribute_group *ir_dev_attr_groups[] = {
@@ -147,9 +165,9 @@ static const struct attribute_group *ir_dev_attr_groups[] = 
{
 
 static struct device_type ir_dev_type = {
.groups = ir_dev_attr_groups,
+   .uevent = ir_dev_uevent,
 };
 
-
 /**
  * ir_register_class() - creates the sysfs for /sys/class/irrcv/irrcv?
  * @input_dev: the struct input_dev descriptor of the device
@@ -172,6 +190,7 @@ int ir_register_class(struct input_dev *input_dev)
ir_dev-dev.class = ir_input_class;
ir_dev-dev.parent = input_dev-dev.parent;
dev_set_name(ir_dev-dev, irrcv%d, devno);
+   dev_set_drvdata(ir_dev-dev, ir_dev);
rc = device_register(ir_dev-dev);
if (rc)
return rc;
@@ -186,8 +205,8 @@ int ir_register_class(struct input_dev *input_dev)
 
__module_get(THIS_MODULE);
 
-   path = kobject_get_path(input_dev-dev.kobj, GFP_KERNEL);
-   printk(KERN_INFO %s: %s associated with sysfs %s\n,
+   path = kobject_get_path(ir_dev-dev.kobj, GFP_KERNEL);
+   printk(KERN_INFO %s: %s as %s\n,
dev_name(ir_dev-dev),
input_dev-name ? input_dev-name : Unspecified device,
path ? path : N/A);
-- 
1.6.6.1


--
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


[PATCH 2/4] Add a macro to properly create IR tables

2010-03-12 Thread Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/IR/ir-keymaps.c b/drivers/media/IR/ir-keymaps.c
index 0efdefe..dfc777b 100644
--- a/drivers/media/IR/ir-keymaps.c
+++ b/drivers/media/IR/ir-keymaps.c
@@ -28,16 +28,28 @@
 #include linux/input.h
 #include media/ir-common.h
 
+
+/*
+ * The usage of tables with just the command part is deprecated.
+ * All new IR keytables should contain address+command and need
+ * to define the proper IR_TYPE (IR_TYPE_RC5/IR_TYPE_NEC).
+ * The deprecated tables should use IR_TYPE_UNKNOWN
+ */
+#define IR_TABLE(irname, type, tabname)\
+struct ir_scancode_table tabname ## _table = { \
+   .scan = tabname,\
+   .size = ARRAY_SIZE(tabname),\
+   .ir_type = type,\
+   .name = #irname,\
+}; \
+EXPORT_SYMBOL_GPL(tabname ## _table)
+
+
 /* empty keytable, can be used as placeholder for not-yet created keytables */
 static struct ir_scancode ir_codes_empty[] = {
{ 0x2a, KEY_COFFEE },
 };
-
-struct ir_scancode_table ir_codes_empty_table = {
-   .scan = ir_codes_empty,
-   .size = ARRAY_SIZE(ir_codes_empty),
-};
-EXPORT_SYMBOL_GPL(ir_codes_empty_table);
+IR_TABLE(empty, IR_TYPE_UNKNOWN, ir_codes_empty);
 
 /* Michal Majchrowicz mmajchrow...@gmail.com */
 static struct ir_scancode ir_codes_proteus_2309[] = {
@@ -68,12 +80,7 @@ static struct ir_scancode ir_codes_proteus_2309[] = {
{ 0x1e, KEY_VOLUMEUP }, /* volume +*/
{ 0x14, KEY_F1 },
 };
-
-struct ir_scancode_table ir_codes_proteus_2309_table = {
-   .scan = ir_codes_proteus_2309,
-   .size = ARRAY_SIZE(ir_codes_proteus_2309),
-};
-EXPORT_SYMBOL_GPL(ir_codes_proteus_2309_table);
+IR_TABLE(proteus_2309, IR_TYPE_UNKNOWN, ir_codes_proteus_2309);
 
 /* Matt Jesson d...@jesson.eclipse.co.uk */
 static struct ir_scancode ir_codes_avermedia_dvbt[] = {
@@ -113,12 +120,7 @@ static struct ir_scancode ir_codes_avermedia_dvbt[] = {
{ 0x1e, KEY_VOLUMEDOWN },   /* 'volume -' */
{ 0x3e, KEY_VOLUMEUP }, /* 'volume +' */
 };
-
-struct ir_scancode_table ir_codes_avermedia_dvbt_table = {
-   .scan = ir_codes_avermedia_dvbt,
-   .size = ARRAY_SIZE(ir_codes_avermedia_dvbt),
-};
-EXPORT_SYMBOL_GPL(ir_codes_avermedia_dvbt_table);
+IR_TABLE(avermedia_dvbt, IR_TYPE_UNKNOWN, ir_codes_avermedia_dvbt);
 
 /* Mauro Carvalho Chehab mche...@infradead.org */
 static struct ir_scancode ir_codes_avermedia_m135a[] = {
@@ -168,12 +170,7 @@ static struct ir_scancode ir_codes_avermedia_m135a[] = {
{ 0x18, KEY_PLAY },
{ 0x1b, KEY_STOP },
 };
-
-struct ir_scancode_table ir_codes_avermedia_m135a_table = {
-   .scan = ir_codes_avermedia_m135a,
-   .size = ARRAY_SIZE(ir_codes_avermedia_m135a),
-};
-EXPORT_SYMBOL_GPL(ir_codes_avermedia_m135a_table);
+IR_TABLE(avermedia_m135a, IR_TYPE_UNKNOWN, ir_codes_avermedia_m135a);
 
 /* Oldrich Jedlicka oldium@seznam.cz */
 static struct ir_scancode ir_codes_avermedia_cardbus[] = {
@@ -232,12 +229,7 @@ static struct ir_scancode ir_codes_avermedia_cardbus[] = {
{ 0x42, KEY_CHANNELDOWN },  /* Channel down */
{ 0x43, KEY_CHANNELUP },/* Channel up */
 };
-
-struct ir_scancode_table ir_codes_avermedia_cardbus_table = {
-   .scan = ir_codes_avermedia_cardbus,
-   .size = ARRAY_SIZE(ir_codes_avermedia_cardbus),
-};
-EXPORT_SYMBOL_GPL(ir_codes_avermedia_cardbus_table);
+IR_TABLE(avermedia_cardbus, IR_TYPE_UNKNOWN, ir_codes_avermedia_cardbus);
 
 /* Attila Kondoros attila.kondo...@chello.hu */
 static struct ir_scancode ir_codes_apac_viewcomp[] = {
@@ -279,12 +271,7 @@ static struct ir_scancode ir_codes_apac_viewcomp[] = {
{ 0x0c, KEY_KPPLUS },   /* fine tune  */
{ 0x18, KEY_KPMINUS },  /* fine tune  */
 };
-
-struct ir_scancode_table ir_codes_apac_viewcomp_table = {
-   .scan = ir_codes_apac_viewcomp,
-   .size = ARRAY_SIZE(ir_codes_apac_viewcomp),
-};
-EXPORT_SYMBOL_GPL(ir_codes_apac_viewcomp_table);
+IR_TABLE(apac_viewcomp, IR_TYPE_UNKNOWN, ir_codes_apac_viewcomp);
 
 /* -- */
 
@@ -331,12 +318,7 @@ static struct ir_scancode ir_codes_pixelview[] = {
{ 0x1d, KEY_REFRESH },  /* reset */
{ 0x18, KEY_MUTE }, /* mute/unmute */
 };
-
-struct ir_scancode_table ir_codes_pixelview_table = {
-   .scan = ir_codes_pixelview,
-   .size = ARRAY_SIZE(ir_codes_pixelview),
-};
-EXPORT_SYMBOL_GPL(ir_codes_pixelview_table);
+IR_TABLE(pixelview, IR_TYPE_UNKNOWN, ir_codes_pixelview);
 
 /*
Mauro Carvalho Chehab mche...@infradead.org
@@ -381,12 +363,7 @@ static struct ir_scancode ir_codes_pixelview_new[] = {
{ 0x31, KEY_TV },
{ 0x34, KEY_RADIO },
 };

[PATCH 1/4] V4L/DVB: ir: use a real device instead of a virtual class

2010-03-12 Thread Mauro Carvalho Chehab
Change the ir-sysfs approach to create irrcv0 as a device, instead of
using class_dev. Also, change the way input is registered, in order
to make its parent to be the irrcv device.

Due to this change, now the event device is created under
/sys/class/ir/irrcv class:

/sys/class/irrcv/irrcv0/
|-- current_protocol
|-- device - ../../../1-3
|-- input9
|   |-- capabilities
|   |   |-- abs
...

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 0903f53..c9c0a54 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -448,22 +448,15 @@ int ir_input_register(struct input_dev *input_dev,
input_dev-setkeycode = ir_setkeycode;
input_set_drvdata(input_dev, ir_dev);
 
-   rc = input_register_device(input_dev);
-   if (rc  0)
-   goto err;
-
rc = ir_register_class(input_dev);
-   if (rc  0) {
-   input_unregister_device(input_dev);
+   if (rc  0)
goto err;
-   }
 
return 0;
 
 err:
kfree(rc_tab-scan);
kfree(ir_dev);
-   input_set_drvdata(input_dev, NULL);
return rc;
 }
 EXPORT_SYMBOL_GPL(ir_input_register);
@@ -492,7 +485,6 @@ void ir_input_unregister(struct input_dev *dev)
ir_unregister_class(dev);
 
kfree(ir_dev);
-   input_unregister_device(dev);
 }
 EXPORT_SYMBOL_GPL(ir_input_unregister);
 
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index bf5fbcd..1bb011a 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -22,7 +22,15 @@
 static unsigned long ir_core_dev_number;
 
 /* class for /sys/class/irrcv */
-static struct class *ir_input_class;
+static char *ir_devnode(struct device *dev, mode_t *mode)
+{
+   return kasprintf(GFP_KERNEL, irrcv/%s, dev_name(dev));
+}
+
+struct class ir_input_class = {
+   .name   = irrcv,
+   .devnode= ir_devnode,
+};
 
 /**
  * show_protocol() - shows the current IR protocol
@@ -128,6 +136,20 @@ static struct attribute *ir_dev_attrs[] = {
NULL,
 };
 
+static struct attribute_group ir_dev_attr_grp = {
+   .attrs  =ir_dev_attrs,
+};
+
+static const struct attribute_group *ir_dev_attr_groups[] = {
+   ir_dev_attr_grp,
+   NULL
+};
+
+static struct device_type ir_dev_type = {
+   .groups = ir_dev_attr_groups,
+};
+
+
 /**
  * ir_register_class() - creates the sysfs for /sys/class/irrcv/irrcv?
  * @input_dev: the struct input_dev descriptor of the device
@@ -137,7 +159,7 @@ static struct attribute *ir_dev_attrs[] = {
 int ir_register_class(struct input_dev *input_dev)
 {
int rc;
-   struct kobject *kobj;
+   const char *path;
 
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
int devno = find_first_zero_bit(ir_core_dev_number,
@@ -146,19 +168,31 @@ int ir_register_class(struct input_dev *input_dev)
if (unlikely(devno  0))
return devno;
 
-   ir_dev-attr.attrs = ir_dev_attrs;
-   ir_dev-class_dev = device_create(ir_input_class, NULL,
- input_dev-dev.devt, ir_dev,
- irrcv%d, devno);
-   kobj = ir_dev-class_dev-kobj;
+   ir_dev-dev.type = ir_dev_type;
+   ir_dev-dev.class = ir_input_class;
+   ir_dev-dev.parent = input_dev-dev.parent;
+   dev_set_name(ir_dev-dev, irrcv%d, devno);
+   rc = device_register(ir_dev-dev);
+   if (rc)
+   return rc;
 
-   printk(KERN_WARNING Creating IR device %s\n, kobject_name(kobj));
-   rc = sysfs_create_group(kobj, ir_dev-attr);
-   if (unlikely(rc  0)) {
-   device_destroy(ir_input_class, input_dev-dev.devt);
-   return -ENOMEM;
+
+   input_dev-dev.parent = ir_dev-dev;
+   rc = input_register_device(input_dev);
+   if (rc  0) {
+   device_del(ir_dev-dev);
+   return rc;
}
 
+   __module_get(THIS_MODULE);
+
+   path = kobject_get_path(input_dev-dev.kobj, GFP_KERNEL);
+   printk(KERN_INFO %s: %s associated with sysfs %s\n,
+   dev_name(ir_dev-dev),
+   input_dev-name ? input_dev-name : Unspecified device,
+   path ? path : N/A);
+   kfree(path);
+
ir_dev-devno = devno;
set_bit(devno, ir_core_dev_number);
 
@@ -175,16 +209,12 @@ int ir_register_class(struct input_dev *input_dev)
 void ir_unregister_class(struct input_dev *input_dev)
 {
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
-   struct kobject *kobj;
 
clear_bit(ir_dev-devno, ir_core_dev_number);
+   input_unregister_device(input_dev);
+   device_del(ir_dev-dev);
 
-   kobj = ir_dev-class_dev-kobj;
-
-   sysfs_remove_group(kobj, ir_dev-attr);
-   device_destroy(ir_input_class, input_dev-dev.devt);
-
-   kfree(ir_dev-attr.name);
+   

Re: pushes at v4l-utils tree

2010-03-12 Thread Mauro Carvalho Chehab
Mauro Carvalho Chehab wrote:
 Hans de Goede wrote:
 Hi,

 On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
 Hi Hans,

 As we've agreed that the idea is to allow multiple people to commit at
 v4l-utils,
 today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1
 is .gitignore
 stuff). One of the reasons were to test the viability for such commits.

 I've temporarily enabled the same script that we use for upstream
 patches to
 generate patches against linuxtv-commits ML.

  From my experiences, I have some notes:
 1) git won't work fine if more than one is committing at the same
 tree.
 The reason is simple: it won't preserve the same group as the previous
 commits. So,
 the next committer will have troubles if we allow multiple committers;

 I assume you are talking about some issues with permissions on the
 server side here ?
 
 Yes. The new objects and the touched files got a different group ownership
 after git push. I had to manually fix them at the server.

I added a hook that will likely fix it. As I have a few more changes to 
ir-keytable,
I'll be sending it directly and see if the permissions are properly fixed.

Please, don't upgrade the version yet just due to keytable, as I'm still 
working on
more keytable patches, to handle the new uevent attributes (to match the IR 
core patches
I posted earlier today).

-- 

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


Capturing raw JPEG stream from webcam

2010-03-12 Thread Basil Mohamed Gohar
I originally posted this to the video4linux mailing list, but I've since
discovered that this is the appropriate place (or so I understand) for
video4linux questions.  My question is how can I capture the raw JPEG
image stream (e.g., MJPEG) from my webcam, which reports through v4l2
that it is capable of.  I am using the gst-launch cli to gstreamer,
which confirms that my webcam has this capability:
 image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
 30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }
And, indeed, I can capture using this capability, but the framerate is
not at the specified rate, but at a much lower value (half or less). 
So, even if I specify 30fps, I get something less.  I can capture the
full 30fps when I use one of the yuv modes, though, so it's clearly
capable of delivering that framerate.

My webcam is a Logitech QuickCam Pro 5000.  The lsusb output is:
 046d:08ce Logitech, Inc. QuickCam Pro 5000
An example command line I try is as follows:
 gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
 height=480, framerate=30/1' ! jpegdec ! xvimagesink
Thank you in advance for any help!

-- 
  Basil Mohamed Gohar
abu_huray...@hidayahonline.org
http://www.basilgohar.com/blog
basilgohar on irc.freenode.net
GPG Key Fingerprint:  5AF4B362

--
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: pushes at v4l-utils tree

2010-03-12 Thread Mauro Carvalho Chehab
Mauro Carvalho Chehab wrote:
 Mauro Carvalho Chehab wrote:
 Hans de Goede wrote:

 Yes. The new objects and the touched files got a different group ownership
 after git push. I had to manually fix them at the server.
 
 I added a hook that will likely fix it. As I have a few more changes to 
 ir-keytable,
 I'll be sending it directly and see if the permissions are properly fixed.

After some work, it is now working properly. So, it is safe for the others to 
update
on it without breaking the permissions.

 Please, don't upgrade the version yet just due to keytable, as I'm still 
 working on
 more keytable patches, to handle the new uevent attributes (to match the IR 
 core patches
 I posted earlier today).

Added what I have for now. The ir-keytable is now doing a nice job reading the 
new
sysfs stuff from /sys/class/irrcv, with the new IR patches I posted. I'll add 
tomorrow
the ir-core patches at v4l-dvb tree, if no comments received.

The next item on keytable TODO list is to add ir-keytable at Makefile install 
target
and to put it to work together with udev. After those changes, it will be 
possible to
replace an IR table when a device is detected by udev. 

I'll probably write an example script to do a very basic udev setup,but a more 
sophisticated userspace tool would be needed to allow someone to do it
via some gui.

-- 

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: Remaining drivers that aren't V4L2?

2010-03-12 Thread Hans de Goede

Hi,

On 03/12/2010 10:42 PM, Hans Verkuil wrote:

On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:

Hello,

I know some months ago, there was some discussion about a few drivers
which were stragglers and had not been converted from V4L to V4L2.

Do we have a current list of driver which still haven't been converted?




As Hans Verkuil already said I've been working on steadily converting
v4l1 usb device drivers to gspca sub drivers, removing a lot of
redundant code and making them v4l2.


These drivers are still v4l1:

arv
bw-qcam
c-qcam
cpia_pp



cpia_usb


This one has a gspca subdriver now, and has been marked as
deprecated in 2.6.34, and scheduled for removal.


ov511


This one has a gspca subdriver now, and has been marked as
deprecated in 2.6.34, and scheduled for removal.


se401


Hans Verkuil gave me a camera with such a chip, I've been
meaning to work on this for a while. Note that the v4l1 driver
is completely broken (hanhs the machine) which complicates writing
a v4l2 driver, as I either need to first fix the v4l1 driver,
or just copy do a v4l2 driver based on the info in the v4l1 driver,
without having a driver to compare with.


stradis



stv680


This one has a gspca subdriver now, and has been marked as
deprecated in 2.6.34, and scheduled for removal.


usbvideo


This actually is a framework for usb video devices a bit like
gspca one could say. It supports the following devices:

USB 3com HomeConnect (aka vicam)
USB IBM (Xirlink) C-it Camera
USB Konica Webcam support
USB Logitech Quickcam Messenger

Of which the Logitech Quickcam Messenger has a gspca subdriver
now, and is scheduled for removal.


w9966

Some of these have counterparts in gspca these days so possibly some drivers
can be removed by now. Hans, can you point those out?



See above. Note in order to finish the conversion of drivers to
v4l1 besides time (which can be made every now and then) I really
really need hardware access, so if anyone has one of the usbvideo supported
devices lying around, and is willing to ship it to me, please drop
me a private mail!



arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
and if no one steps up then they can be dropped altogether.



Ack!


According to my notes I should be able to test cpia_usb. I would have to
verify that, though. I think it is only used in a USB microscope. It is
effectively a webcam. I can also test usbvideo (USB 1 TV capture device).
The latter is probably the most important driver that needs converting,
because I think these are not uncommon.



You gave your cpia1 camera to me, so now I have 2 to test with, 1 from
creative and the brandless one from you. Also note that this indeed is
used in microscopes, but also in regular webcams, Either way the cpia1
is supported in gspca now (for the usb version).


However, I have no time to work on such a driver conversion. But if someone
is seriously willing to put time and effort in that, then I am willing to
mail the hardware.



You already did that, you gave me a cpia1, stv0680 and an se401 camera :)


I started doing some more tvtime work last night, and I would *love*
to drop V4L support (and *only* support V4L2 devices), since it would
make the code much cleaner, more reliable, and easier to test.

If there are only a few obscure webcams remaining, then I'm willing to
tell those users that they have to stick with whatever old version of
tvtime they've been using since the last release four years ago.


To my knowledge the usbvideo driver is probably the least obscure device
that is still using V4L1.


I think you are confusing the usbvideo driver with the v4l2 usbvision
driver, which indeed gets used a lot in usb tv devices.

I think it is ok to drop v4l1 support from tvtime.

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: pushes at v4l-utils tree

2010-03-12 Thread Hans de Goede

Hi,

On 03/12/2010 08:29 PM, Mauro Carvalho Chehab wrote:

Hans de Goede wrote:

Hi,

On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:

Hi Hans,

As we've agreed that the idea is to allow multiple people to commit at
v4l-utils,
today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1
is .gitignore
stuff). One of the reasons were to test the viability for such commits.

I've temporarily enabled the same script that we use for upstream
patches to
generate patches against linuxtv-commits ML.

  From my experiences, I have some notes:
 1) git won't work fine if more than one is committing at the same
tree.
The reason is simple: it won't preserve the same group as the previous
commits. So,
the next committer will have troubles if we allow multiple committers;



I assume you are talking about some issues with permissions on the
server side here ?


Yes. The new objects and the touched files got a different group ownership
after git push. I had to manually fix them at the server.



I'll get you in touch with one of the Fedora infrastructure admins.

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: pushes at v4l-utils tree

2010-03-12 Thread Hans de Goede

Hi,

On 03/13/2010 02:24 AM, Mauro Carvalho Chehab wrote:

Please, don't upgrade the version yet just due to keytable, as I'm still 
working on
more keytable patches, to handle the new uevent attributes (to match the IR 
core patches
I posted earlier today).



Ok,

Note the main reason for the 0.7.91 release was a small libv4l fix which I 
wanted to get out there.

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: v4l-utils, dvb-utils, xawtv and alevt

2010-03-12 Thread Hans de Goede

Hi,

On 03/12/2010 08:10 PM, Chicken Shack wrote:

1. Alevt 1.7.0 is not just another tool, but it is instead a
self-contained videotext application consisting of three parts:
a. alevt, b. alevt-date c. alevt-cap

While the packed size of alevt is 78770 the complete size of the
dvb-apps as a whole ranges around 35.

I am not against hosting this program at linuxtv.org, but if this
decision is made the decision should be an intelligent one: alevt is a
separate tree, and any other choice is simply a dumb one.
Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
only need the libc6.



Seems we agree here, becoming a new upstream for alevt is good, merging
it into another package is not good :)


2. Xawtv-4.0 pre is not usable as a whole. Thus you cannot treat it as a
whole. And that's exactly why you cannot discuss it as a whole!



Actually when I was talking about doing a tree to collect distro packages
and serve as a new upstream for xawtv I was talking about xawtv version
3.95, is that the same as which you call xawtv-4.0 pre ?




The usable parts are:

a. mtt: a slave videotext application which is running independently
from the master application tuning the channels.
Its packed size amounts to 107744.

b. dvbrowse: a slave EPG application which is running independently from
the master application tuning the channels.
Packed Size: 101267.

c. dvbradio: a fast and rather stable running application for watching
DVB radio streams.
Packed Size: 119957.
Problem: dvbradio would need investigation to understand channel lists
in vdr channels.conf format.
As long as this is not the case, the insane slow homebrew scanner called
alexplore is necessary to produce a channels list.
Gerd implied some vdr modules into thew package, but they are
ca. unfinished work
cb. for debug purposes only


The unusable parts are:

a. xawtv itself, the main program.
It never ran stable and it is unfinished work.
Its graphical capabilities are pure rubbish compared to todays
standards.



??

Its UI is not a brilliant piece of work but it is usable and certainly
is stable. Actually it still is my preffered app for tvcard testing / usage.


b. Lots of aged tools like scantv or radio who just have survived
somehow but weren't modified.



If these are really useless we could certainly drop them, as we could
drop say v4l-ctl once we've got rid of the last v4l1 drivers.

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