from:"Devin Heitmueller"

On Tue, Aug 10, 2010 at 7:22 AM, folkert folk...@vanheusden.com wrote:
 Teletext support is completely different that digital (DVB) support.
 VBI support (including teletext) was added to the in-kernel em28xx
 driver back in January.

 That'll be the analogue interface probably? e.g. /dev/vbi0
 Because a.f.a.i.k. the dvb interface is /dev/dvb/adapter0/demux0 ?

Yes, VBI is an analog interface, and the teletext is provided via /dev/vbi0.

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: [linux-dvb] Pinnacle Systems, Inc. PCTV 330e 2.6.34 /dev/dvb

2010/8/10 folkert folk...@vanheusden.com:
 Fyi: since I upgraded the modules by the mercurial tree you mentioned a
 few mails ago, my 18b4:1689 e3C Technologies DUTV009 significally has
 more signal locks. Coincidence?

I don't know.  The tree I pointed you to is several months old, but
may be newer than whatever version of the drivers you had in your base
Linux distribution.

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: [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[ffffffffa004fbc5] [ffffffffa004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]

Hello Sander,

Which application were you using, and specifically which em28xx based
product do you have?

Devin

On Tue, Aug 10, 2010 at 6:12 PM, Sander Eikelenboom
li...@eikelenboom.it wrote:
 Hi,

 While trying to test try and report about some other bugs,  i ran into this 
 kernel panic when trying to grab video from my usb 2.0 em28xx videgrabber 
 connected to a usb 2.0 port.
 Complete serial log attachted.


 [  279.680018] general protection fault:  [#1] SMP
 [  279.683901] last sysfs file: 
 /sys/devices/pci:00/:00:12.2/usb1/1-5/i2c-0/name
 [  279.683901] CPU 5
 [  279.683901] Modules linked in: xt_multiport ipt_REJECT xt_recent xt_limit 
 xt_tcpudp powernow_k8 mperf xt_state ipt_MA
 SQUERADE ipt_LOG iptable_mangle iptable_filter iptable_nat ip_tables nf_nat 
 x_tables nf_conntrack_ipv4 nf_conntrack nf_d
 efrag_ipv4 fuse hwmon_vid loop saa7115 snd_cmipci gameport snd_opl3_lib 
 snd_hwdep snd_mpu401_uart snd_rawmidi em28xx v4l
 2_common snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm 
 snd_seq_device videodev snd_timer snd v4l1_compat v4l
 2_compat_ioctl32 videobuf_vmalloc videobuf_core psmouse tpm_tis joydev evdev 
 tveeprom serio_raw shpchp edac_core i2c_pii
 x4 soundcore pcspkr i2c_core pci_hotplug wmi snd_page_alloc processor button 
 sd_mod r8169 thermal fan thermal_sys [last
 unloaded: scsi_wait_scan]
 [  279.683901]
 [  279.683901] Pid: 0, comm: swapper Not tainted 
 2.6.352.6.35-vanilla-xhci-isoc+ #6 890FXA-GD70 (MS-7640)  /MS-7640
 [  279.683901] RIP: 0010:[a004fbc5]  [a004fbc5] 
 em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]
 [  279.683901] RSP: 0018:880001b43c68  EFLAGS: 00010082
 [  279.683901] RAX: dead00200200 RBX: 0804 RCX: 
 880229625818
 [  279.683901] RDX: dead00100100 RSI: 0003 RDI: 
 880229625868
 [  279.683901] RBP: 880001b43d08 R08:  R09: 
 0804
 [  279.683901] R10: 880229597000 R11:  R12: 
 
 [  279.683901] R13: 88022f158820 R14: 880229597000 R15: 
 0344
 [  279.683901] FS:  7fa4bd3706e0() GS:880001b4() 
 knlGS:
 [  279.683901] CS:  0010 DS:  ES:  CR0: 8005003b
 [  279.683901] CR2: 7fa4bd35f000 CR3: 00022a9ad000 CR4: 
 06e0
 [  279.683901] DR0:  DR1:  DR2: 
 
 [  279.683901] DR3:  DR6: 0ff0 DR7: 
 0400
 [  279.683901] Process swapper (pid: 0, threadinfo 880237d4a000, task 
 880237d2f7a0)
 [  279.683901] Stack:
 [  279.683901]  8103d7a3 880001b43cb0 0082 
 8802375e2188
 [  279.683901] 0 0804 880229625818 880229597a40 
 880229597a90
 [  279.683901] 0 c90010b72000  002237d2 
 880229597000
 [  279.683901] Call Trace:
 [  279.683901]  IRQ
 [  279.683901]  [8103d7a3] ? enqueue_task+0x77/0x87
 [  279.683901]  [a0053398] em28xx_irq_callback+0x7e/0xfe [em28xx]
 [  279.683901]  [81359415] usb_hcd_giveback_urb+0x84/0xb8
 [  279.683901]  [8136b51b] ehci_urb_done+0xcf/0xe4
 [  279.683901]  [8136cd15] ehci_work+0x504/0x8da
 [  279.683901]  [81370fda] ehci_irq+0x19c/0x1ce
 [  279.683901]  [81358bd1] usb_hcd_irq+0x3e/0x83
 [  279.683901]  [8108782c] handle_IRQ_event+0x58/0x136
 [  279.683901]  [81089414] handle_fasteoi_irq+0x92/0xd2
 [  279.683901]  [8100b241] handle_irq+0x1f/0x2a
 [  279.683901]  [8100a884] do_IRQ+0x5a/0xc1
 [  279.683901]  [8146c953] ret_from_intr+0x0/0x11
 [  279.683901]  EOI
 [  279.683901]  [a0044740] ? acpi_idle_enter_simple+0x130/0x168 
 [processor]
 [  279.683901]  [a004473c] ? acpi_idle_enter_simple+0x12c/0x168 
 [processor]
 [  279.683901]  [813ad822] cpuidle_idle_call+0x9b/0xfd
 [  279.683901]  [81007868] cpu_idle+0x51/0x84
 [  279.683901]  [81466d1b] start_secondary+0x1c0/0x1c5
 [  279.683901] Code: 83 ef 80 e8 69 39 01 e1 48 8b 4d 88 49 c7 86 18 0b 00 00 
 00 00 00 00 be 03 00 00 00 48 8b 51 40 48
 8b 41 48 48 89 cf 48 83 c7 50 48 89 42 08 48 89 10 48 b8 00 01 10 00 00 00 
 ad de 48 89 41 40
 [  279.683901] RIP  [a004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 
 [em28xx]
 [  279.683901]  RSP 880001b43c68
 [  279.683901] ---[ end trace 0f55a03076b067cf ]---
 [  279.683901] Kernel panic - not syncing: Fatal exception in interrupt
 [  279.683901] Pid: 0, comm: swapper Tainted: G      D     
 2.6.352.6.35-vanilla-xhci-isoc+ #6
 [  279.683901] Call Trace:
 [  279.683901]  IRQ  [81469cf9] panic+0xb1/0x12a
 [  279.683901]  [81043b90] ? kmsg_dump+0x126/0x140
 [  279.683901]  [8100c354] oops_end+0x89/0x96
 [  279.683901]  [8100c534] die+0x55/0x5e
 [  279.683901]  [8100a26f] do_general_protection+0x130/0x138
 [  279.683901]  [8146cc05] general_protection+0x25/0x30
 [

Re: [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[ffffffffa004fbc5] [ffffffffa004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]

On Tue, Aug 10, 2010 at 6:57 PM, Sander Eikelenboom
li...@eikelenboom.it wrote:
 Hello Devin,

 It's a k-world, which used to work fine (altough with another program, but I 
 can't use that since it seems at least 2 other bugs prevent me from using my 
 VM's :-)
 It's this model  
 http://global.kworld-global.com/main/prod_in.aspx?mnuid=1248modid=6pcid=47ifid=17prodid=104

 Tried to grab with ffmpeg.

Is it reproducible?  Or did it just happen once?  If you have a
sequence to reproduce, can you provide the command line you used, etc?

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: [linux-dvb] Pinnacle Systems, Inc. PCTV 330e 2.6.34 /dev/dvb

2010-08-11 Thread Devin Heitmueller

On Wed, Aug 11, 2010 at 5:07 AM, folkert folk...@vanheusden.com wrote:
  Fyi: since I upgraded the modules by the mercurial tree you mentioned a
  few mails ago, my 18b4:1689 e3C Technologies DUTV009 significally has
  more signal locks. Coincidence?

 I don't know.  The tree I pointed you to is several months old, but
 may be newer than whatever version of the drivers you had in your base
 Linux distribution.

 teletext with that version of the driver with the pinnacle pctv 330e
 works perfect by the way

I'm sorry, but which version of the driver are you referring to?  It
works perfectly with the tree I pointed you to?  Or it works perfectly
with whatever you had in your base distribution?

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: Error Building the V4L-DVB drivers from source

2010-08-11 Thread Devin Heitmueller

On Wed, Aug 11, 2010 at 5:10 AM, Sicoe Alexandru Dan
sicoe_a...@yahoo.com wrote:
 Hi,
  My name is Alex and I recently tried to install the v4l drivers on my 
 machine.
  Environment:
    Ubuntu release 10.04(lucid)
    Kernel Linux 2.6.32-24-generic
    GNOME 2.30.2

Ubuntu has a bug in their packaging of the kernel headers, which
results in the firedtv driver not building.  Just edit v4l/.config
and change the line that says firedtv=m to firedtv=n

Cheers,

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: [2.6.35] usb 2.0 em28xx kernel panic general protection fault: 0000 [#1] SMP RIP: 0010:[ffffffffa004fbc5] [ffffffffa004fbc5] em28xx_isoc_copy_vbi+0x62e/0x812 [em28xx]

2010-08-11 Thread Devin Heitmueller

On Wed, Aug 11, 2010 at 12:46 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Em 11-08-2010 12:58, Pete Eberlein escreveu:
 On Wed, 2010-08-11 at 09:25 +0200, Sander Eikelenboom wrote:
 Hello Devin,

 Yes it's completely reproducible for a change:

 ffmpeg -f video4linux -r 25 -s 720x576 -i /dev/video0 out.flv
 gave an error:

 Use -f video4linux2.

 The -f video4linux option uses the old video4linux1 API.  I have seen
 similar strange behavior when I used that ffmpeg option with a v4l2
 driver I am developing.  Also, ffmpeg does not use libv4l.

 Still, we have a bug to fix. The driver shouldn't generating a PANIC if 
 accessed
 via V4L1 API.

I agree with Mauro completely.  There is nothing userland should be
able to do which results in a panic (and I have no reason to believe
Pete was suggesting otherwise).  That said, it's really useful to know
that this is some sort of v4l1 backward compatibility problem.

I'll see if I can reproduce this here.

Thanks,

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: hvr950q stopped working: read of drv0 never returns

2010-08-23 Thread Devin Heitmueller

On Mon, Aug 23, 2010 at 12:32 AM, Brian J. Murrell
br...@interlinx.bc.ca wrote:
 Hi,

 I have an HVR 950Q on my Ubuntu 2.6.32 kernel.  I have in fact tried
 several kernel versions on a couple of different machines with the same
 behaviour.

 What seems to be happening is that /dev/dvb/adapter0/dvr0 can be opened:

 open(/dev/dvb/adapter0/dvr0, O_RDONLY|O_LARGEFILE) = 0

 but a read from it never seems to return any data:

 read(0,
 [ process blocks waiting ]

Hi Brian,

What command are you using to control the frontend?  If it's azap,
did you remember to specify the -r argument?

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: Gigabyte 8300

2010-09-03 Thread Devin Heitmueller

On Fri, Sep 3, 2010 at 12:01 PM, Andy Walls awa...@md.metrocast.net wrote:
 On Fri, 2010-09-03 at 10:55 +, Dagur Ammendrup wrote:
 I tried it on a windows machine where it's identified as Conextant
 Polaris Video Capture  or
 oem17.inf:Conexant.NTx86:POLARIS.DVBTX.x86:6.113.1125.1210:usb\vid_1b80pid_d416mi_01
 if that tells you anything.


 Polaris refers to the series of CX2310[012] chips IIRC.

 Support would need changes to the cx231xx driver, and possibly changes
 to the cx25480 module, depending on how far the board differs from
 Conexant reference designs.

I've been working with Conexant on this, and have their current tree here:

https://www.kernellabs.com/hg/~dheitmueller/polaris4/

So if you feel the urge to do any new device support, I would suggest
using this as a starting point.

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: some question about

2010-09-05 Thread Devin Heitmueller

On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote:
 WinTV-HVR-1950 high performance USB TV tuner
 WinTV-HVR-950Q for laptop and notebooks

Both these devices are supported under Linux, and in fact are unlikely
to work properly with only Full Speed USB.  At least the 950q
definitely requires High speed (I put a check in there to specifically
not load the driver otherwise).

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: some question about

2010-09-05 Thread Devin Heitmueller

On Sun, Sep 5, 2010 at 11:48 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote:
 WinTV-HVR-1950 high performance USB TV tuner
 WinTV-HVR-950Q for laptop and notebooks

 Both these devices are supported under Linux, and in fact are unlikely
 to work properly with only Full Speed USB.  At least the 950q
 definitely requires High speed (I put a check in there to specifically
 not load the driver otherwise).

I perhaps misread your original email.  While the 950q does present
itself as a USB audio class device, the 1950 does not.  It only
provides MPEG encoded output (containing both the audio and video),
and is not a USB audio class device.

So while both these devices will work under Linux on a high speed
interface, if you specifically require the device to identify itself
as a USB audio class device, only the 950q does this.

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: some question about

2010-09-05 Thread Devin Heitmueller

On Sun, Sep 5, 2010 at 12:06 PM, loody milo...@gmail.com wrote:
 hi:

 2010/9/5 Devin Heitmueller dheitmuel...@kernellabs.com:
 On Sun, Sep 5, 2010 at 11:48 AM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 On Sun, Sep 5, 2010 at 11:36 AM, loody milo...@gmail.com wrote:
 WinTV-HVR-1950 high performance USB TV tuner
 WinTV-HVR-950Q for laptop and notebooks

 Both these devices are supported under Linux, and in fact are unlikely
 to work properly with only Full Speed USB.  At least the 950q
 definitely requires High speed (I put a check in there to specifically
 not load the driver otherwise).

 I perhaps misread your original email.  While the 950q does present
 itself as a USB audio class device, the 1950 does not.  It only
 provides MPEG encoded output (containing both the audio and video),
 and is not a USB audio class device.

 So while both these devices will work under Linux on a high speed
 interface, if you specifically require the device to identify itself
 as a USB audio class device, only the 950q does this.

 Devin
 would you mind to send me the device descriptors for me?
 I want to check whether the input/output unit and audio/video format
 does meet the spec.
 BTW, will the device support mp3 output?
 since the spec define mp3 as one of input/output format.
 that means if I put the raw data of mp3 to that device, it should
 play/record well.

The device descriptors can be found here:

http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Identification

The device does not support MP3 output (virtually no devices do as far
as I know).  It only provides raw 16-bit two channel PCM.

The video format would not be in the spec you mentioned.  It does work
as a standard V4L2 device though, providing raw YUYV video frames.

Perhaps if I better understood your intended application, I might be
able to give better advice.

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: [PATCH/RFC v1 0/7] Videobuf2 framework

2010-09-10 Thread Devin Heitmueller

On Fri, Sep 10, 2010 at 4:22 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 It's been a long standing wish to convert the ivtv and cx18 drivers to 
 videobuf,
 but it's always been too complex. With a new vb2 implementation it may become
 actually possible.

FYI:  KernelLabs has done a port of cx18 to videobuf.  We just haven't
submitted it upstream yet.  I'm just mentioning this so nobody else
feels the urge to take a crack at it.

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: pwc driver breakage in recent(ish) kernels (for old hardware)

2010-09-15 Thread Devin Heitmueller

On Wed, Sep 15, 2010 at 11:59 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 You're in luck. I fixed this last weekend. It turns out that the
 /dev/videoX device is created too soon and the HAL daemon starts to use it
 immediately causing some initialization to go wrong or something like
 that. Moving the creation of /dev/videoX to the end fixed this issue.

 This bug has been there probably for a long time, but it is only triggered
 if some other process opens the device node immediately.

The HAL daemon opening devices immediately problem a pretty common
bug with bridges (especially for hybrid devices) and I've fixed it for
the ones I've seen.  I'm surprised we don't get reports of this more
often.

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: Hauppauge WinTV-HVR1800 dual tuner help needed

2010-09-16 Thread Devin Heitmueller

On Thu, Sep 16, 2010 at 10:23 AM, Jack Snodgrass
jacksnodgr...@mylinuxguy.net wrote:
 I can use  1 input on the card with mythtv
 using /dev/dvb/adapter0/frontend0
 but I can't figure out how to use the 2nd tuner I'm not sure if the
 2nd tuner is getting
 detected correctly... or if the 2nd tuner is just an analog tuner and
 not a digital tuner
 or what exactly...

The HVR-1800 doesn't have two digital tuners.  It has an analog tuner
and a digital tuner.  If you need dual ClearQAM, you need a card like
the HVR-2250.

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: Trouble building v4l-dvb

2010-09-17 Thread Devin Heitmueller

On Fri, Sep 17, 2010 at 10:49 AM, Mauro Carvalho Chehab
mauroche...@gmail.com wrote:
 While you're there, the better is to also disable CONFIG_ALSA on Ubuntu, as 
 the drivers
 won't work anyway.

Note: while building ALSA modules did fail in some versions for
Ubuntu, it has been over a years since I've seen that problem.
Blindly disabling ALSA for all Ubuntu users would be a huge regression
for users.

 As we don't want to have complains from users about why driver foo is not 
 compiling for me,
 IMO, it should be printing a warning message saying that compilation of 
 ALSA/FIREWIRE drivers with
 that specific kernel version is not possible, due to the back packaging of 
 kernel headers,
 recommending to the user to get a vanilla upstream kernel, if he needs one of 
 the disabled
 drivers.

I agree with this premise for firedtv, but see my comment above about ALSA.

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: HVR 1600 Distortion

2010-09-18 Thread Devin Heitmueller

On Sat, Sep 18, 2010 at 8:42 PM, Josh Borke joshbo...@gmail.com wrote:
 On Sat, Sep 18, 2010 at 8:20 AM, Andy Walls awa...@md.metrocast.net wrote:
 On Fri, 2010-09-17 at 18:23 -0400, Josh Borke wrote:
 Thanks for the response!  Replies are in line.

 On Thu, Sep 16, 2010 at 6:48 PM, Andy Walls awa...@md.metrocast.net wrote:
  On Wed, 2010-09-15 at 22:54 -0400, Josh Borke wrote:
  I've recently noticed some distortion coming from my hvr1600 when
  viewing analog channels.  It happens to all analog channels with some
  slightly better than others.  I am running Fedora 12 linux with kernel
  version 2.6.32.21-166.
 
 
  I know I need to include more information but I'm not sure what to
  include.  Any help would be appreciated.
 
  1. Would you say the distortion is something you would possibly
  encounter on an analog television set, or does it look uniquely
  digital?  On systems with a long uptime and lots of usage, MPEG encoder
  firmware could wind up in a screwed up state giving weird output image.
  Simple solution in this case is to reboot.

 I'm not sure if I would classify it as uniquely digital.  The
 distortion happens across most of the screen with it being
 concentrated in the top third.  Additionally shows that include black
 bars the top black bar is seemingly stretched and the image seems like
 the colors are over-saturated where they colors are brighter.
 Rebooting had no effect :(

 OK.

  2. Have you ensured your cable plant isn't affecting signal integrity?
  http://ivtvdriver.org/index.php/Howto:Improve_signal_quality

 The cable plant hasn't changed the signal strength or integrity as far
 as I know.

 OK.  Keep it in the back of your mind though.

  3. Does this happen with only the RF tuner or only CVBS or only SVideo
  or more than one of them?  If the problem is only with RF, then it could
  be an incoming signal distortion problem.  Do you have cable or an over
  the air antenna for analog RF?

 I only have input for the RF tuner.  I have cable for analog RF.

 Please try and test the output of a VCR or DVD play plugged into the
 HVR-1600.  (We don't need sound, just the video.)

 This will tell us if the problem happens before the CX23418 chip's
 analog front end (i.e. in the RF and analog tuner) or not.


 $ v4l2-ctl -d /dev/video0 -n
 (List of possible inputs displayed)

 $ v4l2-ctl -d /dev/video0 -i 2
 Video input set to 2 (Composite 1)

 # v4l2-ctl -d /dev/video0 -s ntsc-m
 Standard set to 1000

 $ cat /dev/video0  foo.mpg
 ^C


 I only have S-Video but doing this produced a perfect picture.

Before debugging any further, it might make sense to install the tuner
into a Windows box and make sure it's not just a hardware failure in
the can tuner.

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: HVR 1600 Distortion

2010-09-18 Thread Devin Heitmueller

On Sat, Sep 18, 2010 at 9:09 PM, Josh Borke joshbo...@gmail.com wrote:
 It could be the tuner card, it is over 2 years old...Why would the
 analog tuner stop functioning while the digital tuner continues to
 work?  Is it because the analog portion goes through a different set
 of chips?

Yes, the analog portion of the card has a completely separate tuner
and demodulator.

Don't get me wrong, it's possible that this is a driver issue, but
given Andy has the exact same can tuner on his board it probably makes
sense for you to do a sanity test of the hardware before any more time
is spent investigating the software.

Cheers,

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: RFC: BKL, locking and ioctls

2010-09-19 Thread Devin Heitmueller

On Sun, Sep 19, 2010 at 5:17 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 On Sunday, September 19, 2010 23:02:31 Andy Walls wrote:
 Hans,

 On an somewhat related note, but off-topic: what is the proper way to
 implement VIDIOC_QUERYCAP for a driver that implements read()
 on /dev/video0 (MPEG) and mmap() streaming on /dev/video32 (YUV)?

 I'm assuming the right way is for VIDIOC_QUERYCAP to return different
 caps based on which device node was queried.

 The spec is not really clear about this. It would be the right thing to do
 IMHO, but the spec would need a change.

 The caps that are allowed to change between device nodes would have to be
 clearly documented. Basically only the last three in the list, and the phrase
 'The device supports the...' should be replaced with 'The device node supports
 the...'.

This would be great to straighten out.  One of the common problems new
users have setting up MythTV is trying to figure out what type of
device they should be choosing (e.g. V4L2 capture device versus
IVTV MPEG capture device).  The problem is that the application
cannot limit the list of /dev/videoX entries for a given type because
some devices report both for all device nodes (even though, for
example, the cx18 can only do MPEG on /dev/video1 and raw video on
/dev/video0).

This results in all sorts of confusion when people wonder why they
cannot watch TV because they picked IVTV MPEG capture device, and
then picked /dev/video0 as the device node.

And of course the real fun comes around when they cannot figure out
why they cannot capture video on /dev/video24 and /dev/video32 because
those aren't actually video capture devices *at all*.

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: [PATCH 08/10] V4L/DVB: tda18271: allow restricting max out to 4 bytes

2010-09-29 Thread Devin Heitmueller

On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 By default, tda18271 tries to optimize I2C bus by updating all registers
 at the same time. Unfortunately, some devices doesn't support it.

 The current logic has a problem when small_i2c is equal to 8, since there
 are some transfers using 11 + 1 bytes.

 Fix the problem by enforcing the max size at the right place, and allows
 reducing it to max = 3 + 1.

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

 diff --git a/drivers/media/common/tuners/tda18271-common.c 
 b/drivers/media/common/tuners/tda18271-common.c
 index e1f6782..195b30e 100644
 --- a/drivers/media/common/tuners/tda18271-common.c
 +++ b/drivers/media/common/tuners/tda18271-common.c
 @@ -193,20 +193,46 @@ int tda18271_write_regs(struct dvb_frontend *fe, int 
 idx, int len)
        unsigned char *regs = priv-tda18271_regs;
        unsigned char buf[TDA18271_NUM_REGS + 1];
        struct i2c_msg msg = { .addr = priv-i2c_props.addr, .flags = 0,
 -                              .buf = buf, .len = len + 1 };
 -       int i, ret;
 +                              .buf = buf };
 +       int i, ret = 1, max;

        BUG_ON((len == 0) || (idx + len  sizeof(buf)));

 -       buf[0] = idx;
 -       for (i = 1; i = len; i++)
 -               buf[i] = regs[idx - 1 + i];
 +
 +       switch (priv-small_i2c) {
 +       case TDA18271_03_BYTE_CHUNK_INIT:
 +               max = 3;
 +               break;
 +       case TDA18271_08_BYTE_CHUNK_INIT:
 +               max = 8;
 +               break;
 +       case TDA18271_16_BYTE_CHUNK_INIT:
 +               max = 16;
 +               break;
 +       case TDA18271_39_BYTE_CHUNK_INIT:
 +       default:
 +               max = 39;
 +       }

        tda18271_i2c_gate_ctrl(fe, 1);
 +       while (len) {
 +               if (max  len)
 +                       max = len;

 -       /* write registers */
 -       ret = i2c_transfer(priv-i2c_props.adap, msg, 1);
 +               buf[0] = idx;
 +               for (i = 1; i = max; i++)
 +                       buf[i] = regs[idx - 1 + i];

 +               msg.len = max + 1;
 +
 +               /* write registers */
 +               ret = i2c_transfer(priv-i2c_props.adap, msg, 1);
 +               if (ret != 1)
 +                       break;
 +
 +               idx += max;
 +               len -= max;
 +       }
        tda18271_i2c_gate_ctrl(fe, 0);

        if (ret != 1)
 @@ -326,24 +352,7 @@ int tda18271_init_regs(struct dvb_frontend *fe)
        regs[R_EB22] = 0x48;
        regs[R_EB23] = 0xb0;

 -       switch (priv-small_i2c) {
 -       case TDA18271_08_BYTE_CHUNK_INIT:
 -               tda18271_write_regs(fe, 0x00, 0x08);
 -               tda18271_write_regs(fe, 0x08, 0x08);
 -               tda18271_write_regs(fe, 0x10, 0x08);
 -               tda18271_write_regs(fe, 0x18, 0x08);
 -               tda18271_write_regs(fe, 0x20, 0x07);
 -               break;
 -       case TDA18271_16_BYTE_CHUNK_INIT:
 -               tda18271_write_regs(fe, 0x00, 0x10);
 -               tda18271_write_regs(fe, 0x10, 0x10);
 -               tda18271_write_regs(fe, 0x20, 0x07);
 -               break;
 -       case TDA18271_39_BYTE_CHUNK_INIT:
 -       default:
 -               tda18271_write_regs(fe, 0x00, TDA18271_NUM_REGS);
 -               break;
 -       }
 +       tda18271_write_regs(fe, 0x00, TDA18271_NUM_REGS);

        /* setup agc1 gain */
        regs[R_EB17] = 0x00;
 diff --git a/drivers/media/common/tuners/tda18271.h 
 b/drivers/media/common/tuners/tda18271.h
 index d7fcc36..3abb221 100644
 --- a/drivers/media/common/tuners/tda18271.h
 +++ b/drivers/media/common/tuners/tda18271.h
 @@ -80,8 +80,9 @@ enum tda18271_output_options {

  enum tda18271_small_i2c {
        TDA18271_39_BYTE_CHUNK_INIT = 0,
 -       TDA18271_16_BYTE_CHUNK_INIT = 1,
 -       TDA18271_08_BYTE_CHUNK_INIT = 2,
 +       TDA18271_16_BYTE_CHUNK_INIT = 16,
 +       TDA18271_08_BYTE_CHUNK_INIT = 8,
 +       TDA18271_03_BYTE_CHUNK_INIT = 3,
  };

  struct tda18271_config {
 diff --git a/drivers/media/video/tuner-core.c 
 b/drivers/media/video/tuner-core.c
 index fa406b9..1a047c5 100644
 --- a/drivers/media/video/tuner-core.c
 +++ b/drivers/media/video/tuner-core.c
 @@ -428,7 +428,7 @@ static void set_type(struct i2c_client *c, unsigned int 
 type,
        {
                struct tda18271_config cfg = {
                        .config = t-config,
 -                       .small_i2c = TDA18271_08_BYTE_CHUNK_INIT,
 +                       .small_i2c = TDA18271_03_BYTE_CHUNK_INIT,
                };

                if (!dvb_attach(tda18271_attach, t-fe, t-i2c-addr,
 --
 1.7.1




Adding the maintainer for the 18271 driver to the CC.

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: [PATCH 03/10] V4L/DVB: tda18271: Add some hint about what tda18217 reg ID returned

2010-09-29 Thread Devin Heitmueller

On Tue, Sep 28, 2010 at 2:46 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Instead of doing:

 [   82.581639] tda18271 4-0060: creating new instance
 [   82.588411] Unknown device detected @ 4-0060, device not supported.
 [   82.594695] tda18271_attach: [4-0060|M] error -22 on line 1272
 [   82.600530] tda18271 4-0060: destroying instance

 Print:
 [  468.740392] Unknown device (0) detected @ 4-0060, device not supported.

 for the error message, to help detecting what's going wrong with the
 device.

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

 diff --git a/drivers/media/common/tuners/tda18271-fe.c 
 b/drivers/media/common/tuners/tda18271-fe.c
 index 7955e49..77e3642 100644
 --- a/drivers/media/common/tuners/tda18271-fe.c
 +++ b/drivers/media/common/tuners/tda18271-fe.c
 @@ -1177,7 +1177,7 @@ static int tda18271_get_id(struct dvb_frontend *fe)
                break;
        }

 -       tda_info(%s detected @ %d-%04x%s\n, name,
 +       tda_info(%s (%i) detected @ %d-%04x%s\n, name, regs[R_ID]  0x7f,
                 i2c_adapter_id(priv-i2c_props.adap),
                 priv-i2c_props.addr,
                 (0 == ret) ?  : , device not supported.);
 --
 1.7.1




Adding the maintainer for the 18271 driver to the CC.

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: [PATCH 09/10] V4L/DVB: tda18271: Add debug message with frequency divisor

2010-09-29 Thread Devin Heitmueller

On Tue, Sep 28, 2010 at 2:47 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 diff --git a/drivers/media/common/tuners/tda18271-common.c 
 b/drivers/media/common/tuners/tda18271-common.c
 index 195b30e..7ba3ba3 100644
 --- a/drivers/media/common/tuners/tda18271-common.c
 +++ b/drivers/media/common/tuners/tda18271-common.c
 @@ -549,6 +549,13 @@ int tda18271_calc_main_pll(struct dvb_frontend *fe, u32 
 freq)
        regs[R_MD1]   = 0x7f  (div  16);
        regs[R_MD2]   = 0xff  (div  8);
        regs[R_MD3]   = 0xff  div;
 +
 +       if (tda18271_debug  DBG_REG) {
 +               tda_reg(MAIN_DIV_BYTE_1    = 0x%02x\n, 0xff  regs[R_MD1]);
 +               tda_reg(MAIN_DIV_BYTE_2    = 0x%02x\n, 0xff  regs[R_MD2]);
 +               tda_reg(MAIN_DIV_BYTE_3    = 0x%02x\n, 0xff  regs[R_MD3]);
 +       }
 +
  fail:
        return ret;
  }
 --
 1.7.1




Adding the maintainer for the 18271 driver to the CC.

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: [linux-dvb] Asus MyCinema P7131 Dual support

2010-10-04 Thread Devin Heitmueller

On Mon, Oct 4, 2010 at 7:21 PM, hermann pitton hermann-pit...@arcor.de wrote:
 thanks for the report and pointing to the details again.

 We can see, that my testings on four different machines and Dmitri's
 tests have not been enough. Mauro had the Dual card=78 version from me
 too at least for analog TV testing.

 And, that was on hg with most backward compat as possible.

 How good are our chances, to run in such and similar troubles in the
 future, in fact staying only on latest -rc, rc-git and in best case on
 -next stuff previously?

 It will all come down to the distros and such a bug fix might take just
 a year in the future regularly ...

 So, if the quality control was not even sufficient on hg, what will
 happen on latest -rc git stuff for that?

 Obviously zillions of people do much more prefer to crash around there
 than on hg ... ;)

I think it's been made pretty clear:  we don't give a crap about
whether users' PCs crash.  Getting the code into the bleeding edge
kernel is the most important thing.  Reducing maintainership overhead
is clearly more important than whether the code actually works.

Forget about the hg backport system.  We would rather get crap code
into the bleeding edge kernel where almost zero users will test it
than to put it into HG where there is actually a chance for users to
see the problems before it goes into the mainline kernel (except for
the 0.1% of users who are willing to install the latest bleeding edge
kernel and make it work with all their other hardware).

Yes, we should all be prepared for lots of regressions being
introduced, and nobody notices them until the code is already in the
distros and has reached the masses.  And then maybe if the users are
lucky the distro maintainers will backport fixes.

It's been made pretty clear that reducing merge overhead is more
important than delivering a quality product.

I'll stop hijacking the thread now.

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: Help adding support for Hauppauge HVR-850 (latest version w/ USB ID 2040:b140)

2010-10-04 Thread Devin Heitmueller

On Mon, Oct 4, 2010 at 8:07 PM, Seth Jennings spartacu...@gmail.com wrote:
 Hi,

 The most recent version of the Hauppauge WinTV HVR-850 is currently
 not supported.  The previous two hardware versions with USB ID
 2040:651f and 2040:7240 are supported but the most recent version with
 USB ID 2040:b140 is not.

I've got a tree here with support for the device.  More info can be found here:

Hauppauge USBLive2 and new HVR-850 support
http://www.kernellabs.com/blog/?p=1445

Cheers,

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: [PATCH 01/10] V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417

2010-10-07 Thread Devin Heitmueller

On Thu, Oct 7, 2010 at 5:48 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em 28-09-2010 15:46, Mauro Carvalho Chehab escreveu:
 drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ 
 expects type ‘int’, but argument 3 has type ‘long unsigned int’
 drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects 
 type ‘int’, but argument 3 has type ‘size_t’

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

 OK, I just updated my tree with the patches that Mkrufky acked.
 It basically contains the same patches from my previous post, plus
 the patches that Palash sent, and Devin/Mkrufky patches from polaris4
 tree, rebased over the top of kernel v2.6.36-rc7 (this makes easier
 for me to test and to merge).

 The patches are at:
        http://git.linuxtv.org/mchehab/cx231xx.git

 Sri already sent his ack for the first series of the patches.

 The tree contains two extra patches:

 1) a cx231xx large CodingStyle fix patch:
        
 http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=eacd1a7749ae45d1f2f5782c013b863ff480746d

 It basically solves the issues that checkpatch.pl complained on this series 
 of patches;

 2) a cx231xx-417 gcc warning fix:
        
 http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=ca3a6a8c2a4819702e93b9612c4a6d90474ea9b5

 Devin,

 Would it be ok for you if I merge them on my main tree? They're needed for one
 board I'm working with (a Pixelview SBTVD Hybrid - that supports both analog
 and full-seg ISDB-T).

Yeah, I've got additional fixes which aren't on that tree yet, but I
don't see any reason why what's there cannot be merged.

It would be helpful if you could get Douglas to merge both sets of
patches (mine and yours) to the hg backport tree as well, so I can
continue development without requiring the bleeding edge kernel (all
the work going on is for an embedded target which is running a
relatively old kernel).

I've got another couple dozen patches and I'm willing to continue
pushing this stuff upstream, but you need to meet me halfway here by
not making the bleeding edge kernel a requirement for this work.

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: [PATCH] V4L/DVB: tvp5150: COMPOSITE0 input should not force-enable TV mode

2010-10-09 Thread Devin Heitmueller

On Sat, Oct 9, 2010 at 12:31 AM, Paul Walmsley p...@booyaka.com wrote:

 When digitizing composite video from a analog videotape source using the
 TVP5150's first composite input channel, the captured stream exhibits
 tearing and synchronization problems[1].

 It turns out that commit c0477ad9feca01bd8eff95d7482c33753d05c700 caused
 TV mode (as opposed to VCR mode or auto-detect) to be forcibly
 enabled for both composite inputs.  According to the chip
 documentation[2], TV mode disables a chrominance trap input filter,
 which appears to be necessary for high-quality video capture from an
 analog videotape source.  [ Commit
 c7c0b34c27bbf0671807e902fbfea6270c8f138d subsequently restricted the
 problem to the first composite input, apparently inadvertently. ]

FYI:  This isn't a newly discovered issue:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg13869.html

Cheers,

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/DVB: cx231xx: Colibri carrier offset was wrong for PAL/M

2010-10-09 Thread Devin Heitmueller

On Sat, Oct 9, 2010 at 11:23 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 cx231xx: Colibri carrier offset was wrong for PAL/M

 The carrier offset check at cx231xx is incomplete. I got here one concrete 
 case
 where it is broken: if PAL/M is used (and this is the default for Pixelview 
 SBTVD),
 the routine will return zero, and the device will be programmed incorrectly,
 producing a bad image. A workaround were to change to NTSC and back to PAL/M,
 but the better is to just fix the code ;)

Thanks for spotting this.  I've been focusing entirely on NTSC, so any
such fixes for other standards are very welcome.

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

[PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final

2010-10-09 Thread Devin Heitmueller

Hello,

Please pull from the following for some basic fixes related to
applications such as tvtime hanging when no video is present, as well
as some quality improvements for analog.

http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final

Please let me know if there are any questions/problems.

Thanks,

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: [PATCH] xc5000 and switch RF input

2010-10-13 Thread Devin Heitmueller

On Wed, Oct 13, 2010 at 5:30 PM, Dmitri Belimov d.beli...@gmail.com wrote:
 Hi

 Our TV card Behold X7 has two different RF input. This RF inputs can switch 
 between
 different RF sources.

 ANT 1 for analog and digital TV
 ANT 2 for FM radio

 The switch controlled by zl10353.

 I add some defines for the tuner xc5000 and use tuner callback to saa7134 
 part.
 All works well. But my patch can touch other TV cards with xc5000.

 Devin can you check my changes on the other TV cards.

 With my best regards, Dmitry.

Hello Dmitri,

I've looked at the patch.  I really don't think this is the right
approach.  The tuner driver should not have any of this logic - it
should be in the bridge driver.  You can also look at Michael Krufky's
frontend override patches, which allow the bridge to intervene when
DVB frontend commands are made (for example, to toggle the antenna
before the tune is performed).

I understand the problem you are trying to solve, but jamming the
logic into the tuner driver really is a bad idea.

NACK.

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: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input

2010-10-14 Thread Devin Heitmueller

On Thu, Oct 14, 2010 at 4:33 AM, Antti Palosaari cr...@iki.fi wrote:
 I haven't examined this yet enough, but for the background information I can
 say I have one device which needs this. There is tuner behind demodulator,
 but instead of normal I2C-gate switch, it is rather much likely repeater.
 All tuner commands are send to the demod which then writes those to the
 tuner.

 DD = demod I2C addr
 TT = tuner I2C addr
 Bn = payload data

 traditional I2C send to the tuner:
 TT  B0 B1 B2 ...

 demod as repeater send to the tuner:
 DD  TT B0 B1 B2 ...

You can accomplish this by having the demod create an i2c adapter
instance, which generates i2c commands to the bridge.  Then when
instantiating the tuner subdev, pass a pointer to the demod's i2c
adapter instead of the i2c adapter provided by the bridge.

No changes required to the core framework.

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: rtl2832u support

2010-10-19 Thread Devin Heitmueller

On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 Bullshit.

Not exactly the level of mutual respect for your peers that I would
expect of you, Hans.

 First of all these rules are those of the kernel community
 as a whole and *not* linuxtv as such, and secondly you can upstream such
 drivers in the staging tree. If you want to move it out of staging, then
 it will take indeed more work since the quality requirements are higher
 there.

You are correct - while I indeed say it was the position of the
LinuxTV developers, I didn't intend to single them out from the rest
of the Linux kernel community.  The problem I described is systemic to
working with the Linux kernel community in general.

 Them's the rules for kernel development.

 I've done my share of coding style cleanups. I never understand why people
 dislike doing that. In my experience it always greatly improves the code
 (i.e. I can actually understand it) and it tends to highlight the remaining
 problematic areas in the driver.

Because it's additional work.  I agree that *sometimes* it can be
useful.  And yet many times it's a bunch of changes that provide
little actual value and only make it harder to keep the Linux driver
in sync with the upstream source (in many cases, the GPL driver is
derived from some Windows driver or other source).

Alex makes a point that I think it's worth expanding on a bit:

The Linux kernel developers' goals are different than those of the
product/chipset vendor.  The product/chipset vendor typically wants
consistency across operating systems.  This usually involves some sort
of OS portability layer to abstract out the OS specific parts (which
is usually done as a combination of OS specific header files and C
macros).  This reduces the maintenance cost for the author as it makes
it easier to be confident that changes to the core will basically
just work on other operating systems.

The Linux kernel developer wants consistency across Linux drivers
regardless of who wrote them.  This makes sense for the Linux kernel
community in that it makes it easier to work on drivers that you
didn't necessarily write.  However it also means that all of the
portability code and macros are seen as crap which has to be stripped
out.  The net effect is a driver that looks little like the original
platform independent driver, making it easier for the Linux kernel
community to maintain but harder for the original author to provide
updates to.

I can appreciate why the Linux development community chose this route,
but let's not pretend that it doesn't come at a significant cost.
Kind of like how the Git move has resulted in developers who want to
build drivers on a known-stable kernel (as opposed to the bleeding
edge) being treated as second class citizens.

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: [PATCH 7/8] v4l: Add EBUSY error description for VIDIOC_STREAMON

2010-10-24 Thread Devin Heitmueller

On Sun, Oct 24, 2010 at 3:50 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 I think the patch makes sense. As you mention many drivers already implement
 this behaviour, so this mostly clarifies the API. Calling VIDIOC_STREAMON on
 an already streaming file handle isn't something applications should do in the
 first place anyway.

I don't disagree with this behavior in principle, but Pawel should
really try this out with some of the common applications to ensure it
doesn't cause breakage (e.g. tvtime, xawtv, mythtv).

Despite the fact that some drivers already do this, that doesn't mean
that those drivers are necessarily the ones commonly used with these
applications.

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: [PATCH 1/4] V4L: cx231xx, fix lock imbalance

2010-10-27 Thread Devin Heitmueller

On Wed, Oct 27, 2010 at 7:47 AM, Jiri Slaby jsl...@suse.cz wrote:
 Stanse found that there is mutex_lock in a fail path of
 cx231xx_i2c_xfer instead of mutex_unlock (i.e. double lock + leaving a
 function in locked state). So fix that.

 Signed-off-by: Jiri Slaby jsl...@suse.cz
 Cc: Mauro Carvalho Chehab mche...@redhat.com
 Cc: Devin Heitmueller dheitmuel...@hauppauge.com

This was already reported and a patch was submitted by Dan Carpenter
on October 21.  See mail on that day with subject line:  [patch]
V4L/DVB: cx231xx: fix double lock typo.

Cheers,

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: [GIT PULL for 2.6.37-rc1] V4L/DVB updates

2010-10-27 Thread Devin Heitmueller

On Wed, Oct 27, 2010 at 12:46 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 The original code is broken, as it doesn't properly honour a max size of 8.
 Even if we do some optimization at cx231xx, we still need to fix the tda18271
 code, as it is trying to use more than 8 bytes on some writes.

 Also, as you noticed, the way cx231xx sends large firmwares to xc5000 is a 
 hack:
 it requires to identify that the I2C device is a xc5000 and do an special
 treatment for it.

Yes, it does currently only get run if it's an xc5000, but I believe
that code path could be used for *all* devices.  There is no reason
that it needs to be a hack as that behavior should be the default case
(presumably Conexant just didn't want to retest against other
devices).

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: Kworld usb 2800D audio

2010-10-28 Thread Devin Heitmueller

On Thu, Oct 28, 2010 at 10:18 AM, Tim Stowell stowe...@gmail.com wrote:
 Hi,

 I'm able to capture video just fine with my  Kworld usb 2800D usb
 device and the recent (I've installed the April v4l-dvb em28xx
 driver), but I can't get any audio. I tried modprobe em28xx-alsa, and
 the module loads, but alsa can't find any sound cards. Do I need the
 snd-usb-audio driver? the usb device is based on the em2860 chip. Any
 help would be greatly appreciated, thanks.

Hello Tim,

If I recall, the KWorld 2800D doesn't actually capture audio directly
via the USB.  The device has a 2.5mm cable that you are required to
connect to our sound card's line-in.

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: Kworld usb 2800D audio

2010-10-28 Thread Devin Heitmueller

On Thu, Oct 28, 2010 at 10:36 AM, Tim Stowell stowe...@gmail.com wrote:
 Thanks for the response! That makes sense about the 2.5 mm cable. Not
 to be obstinate or anything but I found this link
 http://video4linux-list.1448896.n2.nabble.com/SUCCESS-KWorld-VS-USB2800D-recognized-as-PointNix-Intra-Oral-Camera-No-Composite-Input-td3069455.html
 where the users claims they were able to get a new capture device that
 didn't require using the 2.5mm cable, although I'm not sure how they
 did it. I guess I'm hoping to not have to buy a sound card for capture
 if at all possible as I'm using an embedded pc that doesn't have any
 sound cards, thanks

Read my response in the second message in that thread you provided a
link for.  :-)

The fact that the ALSA device was being created was actually a bug in
the em28xx driver.  The hardware does not support capture over the
USB.

There are other devices which do support audio over the USB - the
limitation is specific to this particular product.

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: Kworld usb 2800D audio

2010-10-28 Thread Devin Heitmueller

On Thu, Oct 28, 2010 at 10:48 AM, Tim Stowell stowe...@gmail.com wrote:
 Ah my bad, I need to read a little deeper it seems :) Thanks for the
 info, now I'll stop pulling my hair out trying to get non-existent
 audio.

If it's any consolation, I had to rip one of the units apart and break
out a scope to come to that conclusion.

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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final

2010-11-02 Thread Devin Heitmueller

On Sat, Oct 9, 2010 at 2:40 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 Hello,

 Please pull from the following for some basic fixes related to
 applications such as tvtime hanging when no video is present, as well
 as some quality improvements for analog.

 http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final

 Please let me know if there are any questions/problems.

ping


-- 
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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final

2010-11-03 Thread Devin Heitmueller

On Wed, Nov 3, 2010 at 7:10 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Hi Devin,

 I didn't start to pull any fixes yet. I might eventually have some time
 during this week, but it is more likely that I'll handle after my
 return back.

That's fine.  It's been pending for almost a month so I just wanted to
be sure it didn't get lost.

Regards,

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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final

2010-11-09 Thread Devin Heitmueller

On Tue, Nov 9, 2010 at 11:03 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em 02-11-2010 16:47, Devin Heitmueller escreveu:
 On Sat, Oct 9, 2010 at 2:40 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 Hello,

 Please pull from the following for some basic fixes related to
 applications such as tvtime hanging when no video is present, as well
 as some quality improvements for analog.

 http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-950q-final

 Please let me know if there are any questions/problems.

 I'm still importing your patches, but, at the very first one, you
 forgot to send your Signed-off-by:

 Generating hg_15168_djh_merge_vbi_changes.patch
 WARNING: please, no space before tabs
 #39: FILE: drivers/media/video/au0828/au0828.h:155:
 +^Istruct au0828_buffer    ^I*vbi_buf;$

 ERROR: Missing Signed-off-by: line(s)

 Cheers,
 Mauro


djh - merge vbi changes was just a rebase against the latest code.
The very first patch in the series is one earlier (047a8c9fa9d5).

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: HVR900H : IR Remote Control

2010-11-18 Thread Devin Heitmueller

On Thu, Nov 18, 2010 at 2:59 PM, Massis Sirapian msirap...@free.fr wrote:
 Does it mean that the IR isn't wired in the case of HVR900H ? When you said
 that your Terratec equals the HVR900H, does it imply that if IR works on
 cinergy xe, it should on the HVR900H?

One thing you may wish to consider is that if I recall the Terratec
remotes are typically NEC and the Hauppauge remotes are typically RC5.
 So it's possible that only the NEC support is working in the current
tm6010 driver, which is why the Hauppauge remote doesn't work.

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: gnutv: What causes DVR overflow?

2010-11-29 Thread Devin Heitmueller

On Mon, Nov 29, 2010 at 2:54 AM, David Liontooth lionte...@cogweb.net wrote:

 I'm seeing great results with gnutv on HVR-1850 cards, but each recording
 triggers the message

  DVR overflow

 What is this, and what are the typical causes? What can I do to prevent it
 from happening?

I don't know about gnutv specifically, but I do know that -EOVERFLOW
is returned when an application fails to read the
/dev/dvb/adapterX/dvr0 device fast enough.  It's the driver signaling
to the application that it did not read the file handle often/fast
enough and that the driver is going to drop packets to keep up.

The driver has a limited amount of buffering, so if you have a delay
that is too long between read() calls (or your read buffer is too
small to accommodate the data rate) you will encounter this condition.

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: gnutv: What causes DVR overflow?

2010-12-01 Thread Devin Heitmueller

On Thu, Dec 2, 2010 at 12:46 AM, David Liontooth lionte...@cogweb.net wrote:
 Thanks, Devin! On my end, it looks like the DVR overflow was caused by the
 -out file being on a mirrored OS drive; I've moved output to a separate
 drive and don't see the error any more. If I run into this again, are there
 ways to make this more robust -- for instance, increase the cache size,
 either as a parameter to the kernel module, or in gnutv?

Hi David,

There is an ioctl you can call against the demux filehandle to
increase the size of the in-kernel buffer.  However I have no idea
whether the gnutv application currently plays with this value.  I
suspect you would probably have to add an ioctl() call to the gnutv
source code.

http://linuxtv.org/downloads/v4l-dvb-apis/dmx_fcalls.html#dms_set_buffer_size

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: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885

2010-12-05 Thread Devin Heitmueller

On Sun, Dec 5, 2010 at 12:09 PM, Alexey Chernov 4er...@gmail.com wrote:
 Hello, Steve,
 thank you very much for your comments!

 As for DVB maybe I'm not correct. The initialization itself, which the DVB
 part of patch is about, is fully tested by me and works successfully on my
 everyday PC. The thing I meant saying 'untested' concerned receiving DVB
 signal through the initialized device.

 So I think I was mistaken that the code itself is untested. I hope it's
 possible to add full of this patch.

Hello Alexey,

What I believe Steven is trying to say is the device successfully
initializing is not enough to consider the DVB part of the driver to
be working.  If you have not seen the device receiving digital
television, the DVB parts of this patch should not be committed.

There are a variety of other reasons why DVB streaming would not work
even if the device properly initializes.  These can include an
improperly configured IF, wrong GPIOs, missing power management code,
etc.

It is far worse for a user to be led to believe the driver should be
working but doesn't then it is for the driver claim to not work with
DVB at all.  This is how we end up with users wasting hours wondering
what is wrong with their MythTV setup when in fact the driver never
actually worked in the first place.

Find someone to test the DVB parts of the board that it shows DVB
streaming.  If you cannot do that, remove those parts from the patch
until someone can be found who is able to test the functionality.

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: Hauppauge USB Live 2

2010-12-14 Thread Devin Heitmueller

On Tue, Dec 14, 2010 at 4:57 AM, Gerd Hoffmann kra...@redhat.com wrote:
  Hi folks,

 Got a Hauppauge USB Live 2 after google found me that there is a linux
 driver for it.  Unfortunaly linux doesn't manage to initialize the device.

 I've connected the device to a Thinkpad T60.  It runs a 2.6.37-rc5 kernel
 with the linuxtv/staging/for_v2.6.38 branch merged in.

 Kernel log and lsusb output are attached.

 Ideas anyone?

Looks like a regression got introduced since I submitted the original
support for the device.

Mauro?

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: PCTV 290e nanostick and remote control support

2011-08-13 Thread Devin Heitmueller

On Sat, Aug 13, 2011 at 9:43 PM, Chris Rankin ranki...@yahoo.com wrote:
 Hi,

 The rc-pinnacle-pctv-hd keymap is missing the definition of the OK key:

 --- linux-3.0/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c.orig       
 2011-08-14 02:42:01.0 +0100
 +++ linux-3.0/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c    2011-08-14 
 02:12:45.0 +0100
 @@ -20,6 +20,7 @@
        { 0x0701, KEY_MENU }, /* Pinnacle logo */
        { 0x0739, KEY_POWER },
        { 0x0703, KEY_VOLUMEUP },
 +       { 0x0705, KEY_OK },
        { 0x0709, KEY_VOLUMEDOWN },
        { 0x0706, KEY_CHANNELUP },
        { 0x070c, KEY_CHANNELDOWN },

 Cheers,
 Chris

Wow, how the hell did I miss that?  I did numerous remotes for em28xx
based devices that use that RC profile, and never noticed that issue.

Will have to check the merge logs.  Maybe the key got lost when they
refactored the IR support.

Chris, you should add a signed-off-by tag and submit this as a patch
so it can be included upstream.

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: Hauppauge Aero-M Driver Problem

2011-08-14 Thread Devin Heitmueller

On Sun, Aug 14, 2011 at 2:33 AM, Trip Ericson webmas...@rabbitears.info wrote:
 Hello, all:

 Since my previous e-mail, I was able to get a Linux driver for the tuner
 from Hauppauge.  It came in the form of a v4l tree with the driver included.
  I adjusted the v4l/.config file to only build the necessary driver.  Once
 it built and I invoked depmod -a, I hooked in my tuner, it detected the
 tuner, but then dmesg gave me:

 [31537.360109] dvb_usb_mxl111sf: probe of 2-1.4:1.0 failed with error -22

 Does anyone have any idea what this could be?  I can't find anything helpful
 about error -22 when I go looking.  I can provide the link to the driver or
 output from any command requested, I just need to know what to provide and
 how best to share it.

 There was also a driver for the Mobile DTV half of the tuner included, but I
 could not get that part to build successfully, so I abandoned it for the
 time being in favor of getting the regular ATSC part to work.

 Thanks for any thoughts or assistance.  It is greatly appreciated. =)

 - Trip

Hello Trip,

If Hauppauge provided you a driver, you need to direct all support
questions to them.  We aren't going to know the first thing about what
is wrong with such a driver since we've never seen it.

If they've made available a driver in source form under the GPL,
that's a great first step.  However it doesn't mean that the open
source community all of a sudden becomes responsible for the burden
associated with supporting such a driver (in particular when no
datasheets have been made available).

Cheers,

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: How to git and build HVR-2200 drivers from Kernel labs ?

2011-08-14 Thread Devin Heitmueller

On Sun, Aug 14, 2011 at 5:21 AM, Declan Mullen
declan.mul...@bigpond.com wrote:
 Hi

 I've got a 8940 edition of a Hauppauge HVR-2200. The driver is called saa7164.
 The versions included in my OS (mythbuntu 10.10 x86 32bit, kernel 2.6.35-30)
 and from linuxtv.org are too old to recognise the 8940 edition. Posts #124 to
 #128 in the Hauppauge HVR-2200 Tuner Install Guide topic
 (http://www.pcmediacenter.com.au/forum/topic/37541-hauppauge-hvr-2200-tuner-
 install-guide/page__view__findpost__p__321195) document my efforts with those
 versions.

 So I wish to use the latest stable drivers from the driver maintainers, ie
 http://kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=summary

 Problem is, I don't know git and I don't know how I'm suppose to git, build
 and install it.

 Taking a guess I've tried:
  git clone git://kernellabs.com/stoth/saa7164-stable.git
  cd saa7164-stable
  make menuconfig
  make

 However I suspect these are not the optimum steps, as it seems to have
 downloaded and built much more than just the saa7164 drivers. The git pulled
 down nearly 1GB (which seems a lot) and the resultant menuconfig produced a
 very big .config.

 Am I doing the right steps or should I be doing something else to git, build
 and install  the latest drivers ?

 Thanks,
 Declan

Hello Declan,

Blame Mauro and the other LinuxTV developers for moving to Git.  When
we had HG you could do just the v4l-dvb stack and apply it to your
existing kernel.  Now you have to suck down the *entire* kernel, and
there's no easy way to separate out just the v4l-dvb stuff (like the
saa7164 driver).  The net effect is it's that much harder for
end-users to try out new drivers, and even harder still for developers
to maintain drivers out-of-tree.

All that said, Ubuntu 10.10 deviates very little in terms of the
saa7164 driver.  What you have is probably already identical to what's
in the kernellabs.com tree.

And yes, PAL support is broken even in the kernellabs tree, so if that
was your motivation then updating to the current KL stable tree won't
help you.

Cheers,

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: How to git and build HVR-2200 drivers from Kernel labs ?

2011-08-14 Thread Devin Heitmueller

Only Steven can look at the schematic and know for sure what prompted
them to update to a new PCI ID.  However, you can definitely try doing
card=4 and see if it works.

Card=9 won't work since that card number is not valid given the card
list in your driver.

Devin

On Sun, Aug 14, 2011 at 7:23 PM, Declan Mullen
declan.mul...@bigpond.com wrote:
 On Sunday 14 August 2011 22:14:48 you wrote:
 On Sun, Aug 14, 2011 at 5:21 AM, Declan Mullen

 declan.mul...@bigpond.com wrote:
  Hi
 
  I've got a 8940 edition of a Hauppauge HVR-2200. The driver is called
  saa7164. The versions included in my OS (mythbuntu 10.10 x86 32bit,
  kernel 2.6.35-30) and from linuxtv.org are too old to recognise the 8940
  edition. Posts #124 to #128 in the Hauppauge HVR-2200 Tuner Install
  Guide topic
  (http://www.pcmediacenter.com.au/forum/topic/37541-hauppauge-hvr-2200-tun
  er- install-guide/page__view__findpost__p__321195) document my efforts
  with those versions.
 
  So I wish to use the latest stable drivers from the driver maintainers,
  ie http://kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=summary
 
  Problem is, I don't know git and I don't know how I'm suppose to git,
  build and install it.
 
  Taking a guess I've tried:
   git clone git://kernellabs.com/stoth/saa7164-stable.git
   cd saa7164-stable
   make menuconfig
   make
 
  However I suspect these are not the optimum steps, as it seems to have
  downloaded and built much more than just the saa7164 drivers. The git
  pulled down nearly 1GB (which seems a lot) and the resultant menuconfig
  produced a very big .config.
 
  Am I doing the right steps or should I be doing something else to git,
  build and install  the latest drivers ?
 
  Thanks,
  Declan

 Hello Declan,

 Blame Mauro and the other LinuxTV developers for moving to Git.  When
 we had HG you could do just the v4l-dvb stack and apply it to your
 existing kernel.  Now you have to suck down the *entire* kernel, and
 there's no easy way to separate out just the v4l-dvb stuff (like the
 saa7164 driver).  The net effect is it's that much harder for
 end-users to try out new drivers, and even harder still for developers
 to maintain drivers out-of-tree.

 All that said, Ubuntu 10.10 deviates very little in terms of the
 saa7164 driver.  What you have is probably already identical to what's
 in the kernellabs.com tree.

 And yes, PAL support is broken even in the kernellabs tree, so if that
 was your motivation then updating to the current KL stable tree won't
 help you.

 Cheers,

 Devin

 Many thanks for the clarification about git.

 The only reason why I'm attempting to use a newer saa7164 driver is
 because the driver in my ubuntu 10.10 (2.6.35-30, x86 32bit) doesn't
 recognise the 8940 edition of my HVR-2200  (and doesn't support the
  card=9 option that I believe is specifically for the 8940 edition).

 Example dmesg output:
  $ dmesg | grep saa7
  [   18.367431] saa7164 driver loaded
  [   18.367467] saa7164 :02:00.0: PCI INT A - GSI 16 (level, low) - IRQ 
 16
  [   18.367472] saa7164[0]: Your board isn't known (yet) to the driver.
  [   18.367473] saa7164[0]: Try to pick one of the existing card configs via
  [   18.367474] saa7164[0]: card=n insmod option.  Updating to the latest
  [   18.367475] saa7164[0]: version might help as well.
  [   18.367684] saa7164[0]: Here are valid choices for the card=n insmod 
 option:
  [   18.367739] saa7164[0]:    card=0 - Unknown
  [   18.367789] saa7164[0]:    card=1 - Generic Rev2
  [   18.367840] saa7164[0]:    card=2 - Generic Rev3
  [   18.367891] saa7164[0]:    card=3 - Hauppauge WinTV-HVR2250
  [   18.367943] saa7164[0]:    card=4 - Hauppauge WinTV-HVR2200
  [   18.367995] saa7164[0]:    card=5 - Hauppauge WinTV-HVR2200
  [   18.368059] saa7164[0]:    card=6 - Hauppauge WinTV-HVR2200
  [   18.368112] saa7164[0]:    card=7 - Hauppauge WinTV-HVR2250
  [   18.368164] saa7164[0]:    card=8 - Hauppauge WinTV-HVR2250
  [   18.369142] CORE saa7164[0]: subsystem: 0070:8940, board: Unknown 
 [card=0,autodetected]
  [   18.369147] saa7164[0]/0: found at :02:00.0, rev: 129, irq: 16, 
 latency: 0, mmio: 0xfd40
  [   18.369152] saa7164 :02:00.0: setting latency timer to 64
  [   18.369162] saa7164_initdev() Unsupported board detected, registering 
 without firmware

 To get this 8940 card working with my ubuntu 10.10 system,
 what would you recommend I try ?

 Should I be trying to extract the new driver from what the above
 git and makes, ie just copy into place the new saa7164.ko file ?
 Or should my existing driver work if i use the card=4 option ?

 Thanks,
 Declan
 --
 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




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

Re: [PATCH] Latest version of em28xx / em28xx-dvb patch for PCTV 290e

2011-08-18 Thread Devin Heitmueller

On Thu, Aug 18, 2011 at 1:52 PM, Chris Rankin ranki...@yahoo.com wrote:
 Hi,

 Here's my latest patch for the em28xx / em28xx-dvb modules, which addresses
 the following problems:

 a) Locking problem when unplugging and then replugging USB adapter.
 b) Race conditions between adding/removing devices from the devlist, while
 simultaneously loading/unloading extension modules.
 c) Resource leaks on error paths.
 d) Preventing the DVB framework from trying to put the adapter into sleep
 mode when the adapter has been physically unplugged. (This results in
 occasional -19 errors from I2C functions when disconnecting.)
 e) Use atomic bit operations to manage device in use slots, and enforce
 upper limit of EM28XX_MAXBOARDS slots.

Hi Chris,

You would be well served to break this into a patch series, as it
tends to be difficult to review a whole series of changes in a single
patch.

You seem to be mixed in a bunch of useless changes alongside
functional changes.  For example, if you're trying to add in a missing
goto inside an exception block, doing that at the same time as
renaming instances of errCode to retval just creates confusion.

And finally, the mutex structure used for the modules is somewhat
complicated due to to the need to keep the analog side of the board
locked while initializing the digital side.  This code was added
specifically to prevent race conditions that were seen during
initialization as things like udev and dbus attempted to connect to
the newly created V4L device while the em28xx-dvb module was still
coming up.

In other words, I don't doubt there are bugs, and I cannot say whether
your fixes are appropriate without giving a hard look at the logic.
But you should be aware of the thinking behind the way it was done and
it would be very worthwhile if you could test with at least one hybrid
product to ensure the changes you are making don't break anything (the
em2874 used in the 290e is a poor test case since it doesn't have
analog support).

 BTW, was there a reason why the em28xx-dvb module doesn't use dvb-usb?

This is largely a product of the history of the devices using the
framework.  The em28xx driver was originally analog only, and DVB
support was added later as new chips came out which needed it.  The
dvb-usb driver came from dedicated DVB devices that had no analog
support.  In fact, even today the lack of analog support is a huge
deficiency in that framework which is why we don't support the analog
side of any hybrid devices that use dvb-usb.

In other words, if we were reinventing this stuff today, there would
probably be only a single framework shared by dvb-usb and em28xx.  But
at this point it's too much cost and too little benefit to go through
the work to attempt to merge them.

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: [PATCH] Latest version of em28xx / em28xx-dvb patch for PCTV 290e

2011-08-18 Thread Devin Heitmueller

On Thu, Aug 18, 2011 at 2:43 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Thu, Aug 18, 2011 at 1:52 PM, Chris Rankin ranki...@yahoo.com wrote:
 Hi,

 Here's my latest patch for the em28xx / em28xx-dvb modules, which addresses
 the following problems:

 a) Locking problem when unplugging and then replugging USB adapter.
 b) Race conditions between adding/removing devices from the devlist, while
 simultaneously loading/unloading extension modules.
 c) Resource leaks on error paths.
 d) Preventing the DVB framework from trying to put the adapter into sleep
 mode when the adapter has been physically unplugged. (This results in
 occasional -19 errors from I2C functions when disconnecting.)
 e) Use atomic bit operations to manage device in use slots, and enforce
 upper limit of EM28XX_MAXBOARDS slots.

 Hi Chris,

 You would be well served to break this into a patch series, as it
 tends to be difficult to review a whole series of changes in a single
 patch.

 You seem to be mixed in a bunch of useless changes alongside
 functional changes.  For example, if you're trying to add in a missing
 goto inside an exception block, doing that at the same time as
 renaming instances of errCode to retval just creates confusion.

 And finally, the mutex structure used for the modules is somewhat
 complicated due to to the need to keep the analog side of the board
 locked while initializing the digital side.  This code was added
 specifically to prevent race conditions that were seen during
 initialization as things like udev and dbus attempted to connect to
 the newly created V4L device while the em28xx-dvb module was still
 coming up.

 In other words, I don't doubt there are bugs, and I cannot say whether
 your fixes are appropriate without giving a hard look at the logic.
 But you should be aware of the thinking behind the way it was done and
 it would be very worthwhile if you could test with at least one hybrid
 product to ensure the changes you are making don't break anything (the
 em2874 used in the 290e is a poor test case since it doesn't have
 analog support).

 BTW, was there a reason why the em28xx-dvb module doesn't use dvb-usb?

 This is largely a product of the history of the devices using the
 framework.  The em28xx driver was originally analog only, and DVB
 support was added later as new chips came out which needed it.  The
 dvb-usb driver came from dedicated DVB devices that had no analog
 support.  In fact, even today the lack of analog support is a huge
 deficiency in that framework which is why we don't support the analog
 side of any hybrid devices that use dvb-usb.

 In other words, if we were reinventing this stuff today, there would
 probably be only a single framework shared by dvb-usb and em28xx.  But
 at this point it's too much cost and too little benefit to go through
 the work to attempt to merge them.

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com


Probably one more point worth making:  I definitely appreciate that
you've take the time to focus on these particular problems.  I've been
complaining about them for months but just never got around to rolling
up my sleeves to debug them myself.

In other words, don't interpret anything in my previous email as discouragement.

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: [PATCH 1/2] DVB: dvb_frontend: convert semaphore to mutex

2011-08-24 Thread Devin Heitmueller

On Wed, Aug 24, 2011 at 1:33 PM, Andreas Oberritter o...@linuxtv.org wrote:
 Signed-off-by: Andreas Oberritter o...@linuxtv.org

This may seem like a silly question, but *why* are you making this
change?  There is no explanation for what prompted it.  Is it in
response to some issue you encountered?

I'm asking because in general dvb_frontend has a fairly complicated
locking model, and unless there is a compelling reason to make changes
I would be against it.

In other words, this is a bad place for arbitrary cleanup patches.

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: [PATCH 1/2] DVB: dvb_frontend: convert semaphore to mutex

2011-08-24 Thread Devin Heitmueller

On Wed, Aug 24, 2011 at 2:02 PM, Andreas Oberritter o...@linuxtv.org wrote:
 It's impossible to clean up dvb_frontend.c, which looks quite
 unmaintained, without touching it.

It is quite unmaintained.  In fact, it was broken for numerous cards
for almost two years before I finally got someone in the Hauppauge UK
office to mail me a couple of affected boards to test with.

Now that it works, I'm very hesitant to see any chances made unless
there is a *very* good reason. It's just too damn easy to introduce
subtle bugs in there that work for your card but cause breakage for
others.

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: [PATCH 1/2] DVB: dvb_frontend: convert semaphore to mutex

2011-08-24 Thread Devin Heitmueller

On Wed, Aug 24, 2011 at 2:08 PM, Andreas Oberritter o...@linuxtv.org wrote:
 Instead of wasting your time with theory, you could have easily reviewed
 my patch. It's really *very* simple any anyone having used semphores or
 mutexes in the kernel should be able to see that.

There's no need to resort to belittlement.  Both of us have a
non-trivial number of commits to the Linux kernel.

My concern is that in the kernel a semaphore with a unit of one is
*not* necessarily the same as a mutex.  In particular you need to take
into account the calling context since mutexes do more enforcement of
certain conditions that may have been acceptable for a semaphore.

From http://www.kernel.org/doc/Documentation/mutex-design.txt :

===
 - 'struct mutex' semantics are well-defined and are enforced if
   CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have
   virtually no debugging code or instrumentation. The mutex subsystem
   checks and enforces the following rules:

   * - only one task can hold the mutex at a time
   * - only the owner can unlock the mutex
   * - multiple unlocks are not permitted
   * - recursive locking is not permitted
   * - a mutex object must be initialized via the API
   * - a mutex object must not be initialized via memset or copying
   * - task may not exit with mutex held
   * - memory areas where held locks reside must not be freed
   * - held mutexes must not be reinitialized
   * - mutexes may not be used in hardware or software interrupt
   *   contexts such as tasklets and timers
===

and:

===
Disadvantages
-

The stricter mutex API means you cannot use mutexes the same way you
can use semaphores: e.g. they cannot be used from an interrupt context,
nor can they be unlocked from a different context that which acquired
it. [ I'm not aware of any other (e.g. performance) disadvantages from
using mutexes at the moment, please let me know if you find any. ]
===

In short, you cannot just arbitrarily replace one with the other.  You
need to look at all the possible call paths and ensure that there
aren't any cases for example where the mutex is set in one but cleared
in the other.  Did you evaluate your change in the context of each of
the differences described in the list above?

Without any documentation in the patch, we have absolutely no idea
what level of due diligence you exercised in ensuring this didn't
cause breakage.

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: AVerTV Hybrid Volar MAX (H826) wiki entry

2011-08-30 Thread Devin Heitmueller

On Tue, Aug 30, 2011 at 7:44 AM, Brian J. Murrell br...@interlinx.bc.ca wrote:
 Hi,

 I was looking at the wiki for the supported status of the AVerMedia
 AVerTV Hybrid Volar MAX (H826).  The wiki says it's not supported.  But
 the wiki also says it's a PCIe card, which it's clearly not:
 http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431

 Additionally in the AP  Driver tab of that page
 (http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431tab=APDriver)
 there is a Linux driver which appears to have (granted, non-GPL) source
 included with it.  But surely given source to a working driver, a
 cleanroom GPL driver could be developed and supported, yes?  Maybe that
 source is just supporting source for a binary blob.  I didn't look
 that closely.

 In any case, I am just wondering what the real supported status of that
 device is given that the wiki is incorrect about at least some details
 of the device.

 Even if it's not supported, somebody with more understanding of this
 device than I (I've just read a product page) ought to fix the wiki.  In
 fixing it, I think it's only fair to point to the vendor supplied
 driver, even if it's not open source and/or not a compatible open source
 license.

They've got a history of violating the GPL by shipping closed source
binary drivers which link against GPL'd DVB drivers (thereby
leveraging the hard work of the developers who GPL'd drivers, while
not giving any of their stuff back).

I cannot speak for the other developers but I wont' go near this crap
with a ten foot pole.

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: [PATCH 01/10] alsa_stream: port changes made on xawtv3

On Tue, Sep 6, 2011 at 11:40 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Hi Devin,

 Em 06-09-2011 12:29, Mauro Carvalho Chehab escreveu:
 There are several issues with the original alsa_stream code that got
 fixed on xawtv3, made by me and by Hans de Goede. Basically, the
 code were re-written, in order to follow the alsa best practises.

 Backport the changes from xawtv, in order to make it to work on a
 wider range of V4L and sound adapters.

 FYI, just flooded your mailbox with 10 patches for tvtime. ;)

 I'm wanting to test some things with tvtime on one of my testboxes, but some
 of my cards weren't working with the alsa streaming, due to a few bugs that
 were solved on xawtv fork.

 So, I decided to backport it to tvtime and recompile the Fedora package for 
 it.
 That's where the other 9 patches come ;)

 Basically, after applying this series of 10 patches, we can just remove all
 patches from Fedora, making life easier for distro maintainers (as the same
 thing is probably true on other distros - at least one of the Fedora patches
 came from Debian, from the fedora git logs).

 One important thing for distros is to have a tarball with the latest version
 hosted on a public site, so I've increased the version to 1.0.3 and I'm
 thinking on storing a copy of it at linuxtv, just like we do with xawtv3.

 If you prefer, all patches are also on my tvtime git tree, at:
        http://git.linuxtv.org/mchehab/tvtime.git

 Thanks,
 Mauro

Hi Mauro,

Funny you should send these along today.  Last Friday I was actually
poking around at the Fedora tvtime repo because I was curious how they
had dealt with the V4L1 support issue (whether they were using my
patch removing v4l1 or some variant).

I've actually pulled in Fedora patches in the past (as you can see
from the hg repo), and it has always been my intention to do it for
the other distros as well (e.g. debian/Ubuntu).  So I appreciate your
having sent these along.

I'll pull these in this week, do some testing to make sure nothing
serious got broken, and work to spin a 1.0.3 toward the end of the
week.  Given the number of features/changes, and how long it's been
since the last formal release, I was considering calling it 1.1.0
instead though.

I've been thinking for a while that perhaps the project should be
renamed (or I considered prepending kl onto the front resulting in
it being called kl-tvtime).  This isn't out of vanity but rather my
concern that the fork will get confused with the original project (for
example, I believe Ubuntu actually already calls their modified tree
tvtime 1.0.3).  I'm open to suggestions in this regards.

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: [PATCH 01/10] alsa_stream: port changes made on xawtv3

On Tue, Sep 6, 2011 at 2:19 PM, Hans de Goede hdego...@redhat.com wrote:
 I think that what should be done is contact the debian / ubuntu maintainers,
 get any interesting fixes they have which the kl version misses merged,
 and then just declare the kl version as being the new official upstream
 (with the blessing of the debian / ubuntu guys, and if possible also
 with the blessing of the original authors).

It has always been my intention to get the Debian/Ubuntu patches
merged (as well as other distros).  My thoughts behind renaming were
oriented around the notion that that there are more distros out there
than just Fedora/Ubuntu/Debian, but that may be something that isn't
really a concern.  Also, I had no idea whether the distros would
actually switch over to the Kernel Labs version as the official
upstream source, so providing it under a different name would in
theory allow both packages to be available in parallel.

From a practical standpoint, the Ubuntu folks have the original tvtime
tarball and all their changes in one patch, which is clearly a bunch
of patches that are mashed together probably in their build system.  I
need to reach out to them to find where they have an actual SCM tree
or the individual patches.  They've got a bunch of patches which would
be good to get into a single tree (autobuild fixes, cross-compilation,
locale updates, etc).

 This would require kl git to be open to others for pushing, or we
 could move the tree to git.linuxtv.org (which I assume may be
 easier then for you to make the necessary changes to give
 others push rights on kl.org).

Kernel Labs has never really had any real interest in owning tvtime.
 I just setup the hg tree in an effort to get all the distro patches
in one place and have something that builds against current kernels
(and on which I can add improvements/fixes without users having to
deal with patches).  At the time there was also nobody who clearly had
the desire to serve as an official maintainer.

In the long term I have no real issue with the LinuxTV group being the
official maintainer of record.  I've got lots of ideas and things I
would like to do to improve tvtime, but in practice I've done a pretty
crappy job of maintaining the source (merging patches, etc) at this
point.

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: [PATCH 01/10] alsa_stream: port changes made on xawtv3

On Tue, Sep 6, 2011 at 3:12 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 From a practical standpoint, the Ubuntu folks have the original tvtime
 tarball and all their changes in one patch, which is clearly a bunch
 of patches that are mashed together probably in their build system. I
 need to reach out to them to find where they have an actual SCM tree
 or the individual patches.  They've got a bunch of patches which would
 be good to get into a single tree (autobuild fixes, cross-compilation,
 locale updates, etc).

 Yeah, it seems interesting. Maybe we can get something from this place:
        http://packages.qa.debian.org/t/tvtime.html

 The maintainer there seems to be:
        http://qa.debian.org/developer.php?login=ba...@debian.org

I reached out to the Ubuntu maintainer; we'll see if he gets back to
me.  From what I can tell it seems like Debian is actually taking the
patches from Ubuntu (yes, I realize this is backwards from their
typical process where Ubuntu bases their stuff on Debian).

 In the long term I have no real issue with the LinuxTV group being the
 official maintainer of record.  I've got lots of ideas and things I
 would like to do to improve tvtime, but in practice I've done a pretty
 crappy job of maintaining the source (merging patches, etc) at this
 point.

 Putting it on a common place and giving permissions to a group of people
 is interesting, as none of us are focused on userspace, so we all
 have a very limited amount of time for dealing with userspace applications.

 By giving commit rights to a group of developers, it ends that more
 developers will contribute, speeding up the development.

 That was what happened with v4l-utils and, on a minor scale, with xawtv3.

 If you're ok with that, I can set a tvtime git repository at LinuxTV,
 cloning the tree I've created there already (it is a pure conversion
 of your tree from mercurial into git, if I remove the patches I've
 done so far from your clone), giving you the ownership of the new tree,
 and marking it as a shared repository.

I have no problem with this.  Let's set it up.

 I have already all set there to allow shared access to the repository
 (in opposite to -hg, git works really cool with shared repositories).

I actually haven't hosted any git repos on linuxtv.org before.  I'm
assuming my ssh public key got copied over from when I was hosting hg
repos there?

 We can later add permissions to the developers interested on helping
 the tvtime maintenance that you agree to add.

Sounds good.

As said earlier, Kernel Labs never really wanted to be the maintainer
for tvtime - we did it because nobody else wanted to (and vektor never
responded to emails I sent him offering to help).  That said, a
community oriented approach is probably the best for everybody
involved.

I'll probably be looking in the next couple of weeks to write some
fresh content for a tvtime website.  The stuff on
tvtime.sourceforge.net is so dated almost none of it still applies.

Thanks,

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: [PATCH 01/10] alsa_stream: port changes made on xawtv3

On Tue, Sep 6, 2011 at 11:29 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 There are several issues with the original alsa_stream code that got
 fixed on xawtv3, made by me and by Hans de Goede. Basically, the
 code were re-written, in order to follow the alsa best practises.

 Backport the changes from xawtv, in order to make it to work on a
 wider range of V4L and sound adapters.

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

Mauro,

What tuners did you test this patch with?  I went ahead and did a git
pull of your patch series into my local git tree, and now my DVC-90
(an em28xx device) is capturing at 32 KHz instead of 48 (this is one
of the snd-usb-audio based devices, not em28xx-alsa).

Note I tested immediately before pulling your patch series and the
audio capture was working fine.

I think this patch series is going in the right direction in general,
but this patch in particular seems to cause a regression.  Is this
something you want to investigate?  I think we need to hold off on
pulling this series into the new tvtime master until this problem is
resolved.

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: [PATCH 01/10] alsa_stream: port changes made on xawtv3

On Tue, Sep 6, 2011 at 10:58 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Tue, Sep 6, 2011 at 11:29 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 There are several issues with the original alsa_stream code that got
 fixed on xawtv3, made by me and by Hans de Goede. Basically, the
 code were re-written, in order to follow the alsa best practises.

 Backport the changes from xawtv, in order to make it to work on a
 wider range of V4L and sound adapters.

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

 Mauro,

 What tuners did you test this patch with?  I went ahead and did a git
 pull of your patch series into my local git tree, and now my DVC-90
 (an em28xx device) is capturing at 32 KHz instead of 48 (this is one
 of the snd-usb-audio based devices, not em28xx-alsa).

 Note I tested immediately before pulling your patch series and the
 audio capture was working fine.

 I think this patch series is going in the right direction in general,
 but this patch in particular seems to cause a regression.  Is this
 something you want to investigate?  I think we need to hold off on
 pulling this series into the new tvtime master until this problem is
 resolved.

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com


Spent a few minutes digging into this.  Looks like the snd-usb-audio
driver advertises 8-48KHz.  However, it seems that it only captures
successfully at 48 KHz.

I made the following hack and it started working:

diff --git a/src/alsa_stream.c b/src/alsa_stream.c
index b6a41a5..57e3c3d 100644
--- a/src/alsa_stream.c
+++ b/src/alsa_stream.c
@@ -261,7 +261,7 @@ static int setparams(snd_pcm_t *phandle, snd_pcm_t *chandle,
fprintf(error_fp, alsa: Will search a common rate between %u and %u\n,
ratemin, ratemax);

-for (i = ratemin; i = ratemax; i+= 100) {
+for (i = ratemax; i = ratemin; i-= 100) {
err = snd_pcm_hw_params_set_rate_near(chandle, c_hwparams, i, 0);
if (err)
continue;

Basically the above starts at the *maximum* capture resolution and
works its way down.  One might argue that this heuristic makes more
sense anyway - why *wouldn't* you want the highest quality audio
possible by default (rather than the lowest)?

Even with that patch though, I hit severe underrun/overrun conditions
at 30ms of latency (to the point where the audio is interrupted dozens
of times per second).  Turned it up to 50ms and it's much better.
That said, of course such a change would impact lipsync, so perhaps we
need to be adjusting the periods instead.

ALSA has never been my area of expertise, so I look to you and Hans to
offer some suggestions.

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: [PATCH 01/10] alsa_stream: port changes made on xawtv3

On Tue, Sep 6, 2011 at 11:29 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Basically the above starts at the *maximum* capture resolution and
 works its way down.  One might argue that this heuristic makes more
 sense anyway - why *wouldn't* you want the highest quality audio
 possible by default (rather than the lowest)?

 That change makes sense to me. Yet, you should try to disable pulseaudio
 and see what's the _real_ speed that the audio announces. On Fedora,
 just removing pulsaudio-oss-plugin (or something like that) is enough.

 It seems doubtful that my em2820 WinTV USB2 is different than yours.
 I suspect that pulseaudio is passing the extra range, offering to
 interpolate the data.

I disabled pulseaudio and the capture device is advertising the exact
same range (8-48 KHz).  Seems to be behaving the same way as well.

So while I'm usually willing to blame things on Pulse, this doesn't
look like the case here.

 Even with that patch though, I hit severe underrun/overrun conditions
 at 30ms of latency (to the point where the audio is interrupted dozens
 of times per second).

 Yes, it is the same here: 30ms on my notebook is not enough for WinTV
 USB2 (it is OK with HVR-950).

 Turned it up to 50ms and it's much better.
 That said, of course such a change would impact lipsync, so perhaps we
 need to be adjusting the periods instead.

 We've added a parameter for that on xawtv3 (--alsa-latency). We've 
 parametrized
 it at the alsa stream function call. So, all it needs is to add a new 
 parameter
 at tvtime config file.

Ugh.  We really need some sort of heuristic to do this.  It's
unreasonable to expect users to know about some magic parameter buried
in a config file which causes it to start working.  Perhaps a counter
that increments whenever an underrun is hit, and after a certain
number it automatically restarts the stream with a higher latency.  Or
perhaps we're just making some poor choice in terms of the
buffers/periods for a given rate.

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: [PATCH 01/10] alsa_stream: port changes made on xawtv3

On Tue, Sep 6, 2011 at 11:37 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Tue, Sep 6, 2011 at 11:29 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Basically the above starts at the *maximum* capture resolution and
 works its way down.  One might argue that this heuristic makes more
 sense anyway - why *wouldn't* you want the highest quality audio
 possible by default (rather than the lowest)?

 That change makes sense to me. Yet, you should try to disable pulseaudio
 and see what's the _real_ speed that the audio announces. On Fedora,
 just removing pulsaudio-oss-plugin (or something like that) is enough.

 It seems doubtful that my em2820 WinTV USB2 is different than yours.
 I suspect that pulseaudio is passing the extra range, offering to
 interpolate the data.

 I disabled pulseaudio and the capture device is advertising the exact
 same range (8-48 KHz).  Seems to be behaving the same way as well.

 So while I'm usually willing to blame things on Pulse, this doesn't
 look like the case here.

 Even with that patch though, I hit severe underrun/overrun conditions
 at 30ms of latency (to the point where the audio is interrupted dozens
 of times per second).

 Yes, it is the same here: 30ms on my notebook is not enough for WinTV
 USB2 (it is OK with HVR-950).

 Turned it up to 50ms and it's much better.
 That said, of course such a change would impact lipsync, so perhaps we
 need to be adjusting the periods instead.

 We've added a parameter for that on xawtv3 (--alsa-latency). We've 
 parametrized
 it at the alsa stream function call. So, all it needs is to add a new 
 parameter
 at tvtime config file.

 Ugh.  We really need some sort of heuristic to do this.  It's
 unreasonable to expect users to know about some magic parameter buried
 in a config file which causes it to start working.  Perhaps a counter
 that increments whenever an underrun is hit, and after a certain
 number it automatically restarts the stream with a higher latency.  Or
 perhaps we're just making some poor choice in terms of the
 buffers/periods for a given rate.

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com


One more thing worth noting before I quit for the night:

What audio processor is on your WinTV USB 2 device?  The DVC-90 has an
emp202.  Perhaps the WInTV uses a different audio processor (while
still using an em2820 as the bridge)?  That might explain why your
device advertises effectively only one capture rate (32), while mine
advertises a whole range (8-48).

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: [PATCH 01/10] alsa_stream: port changes made on xawtv3

On Tue, Sep 6, 2011 at 11:42 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 One more thing worth noting before I quit for the night:

 What audio processor is on your WinTV USB 2 device?  The DVC-90 has an
 emp202.  Perhaps the WInTV uses a different audio processor (while
 still using an em2820 as the bridge)?  That might explain why your
 device advertises effectively only one capture rate (32), while mine
 advertises a whole range (8-48).

Just took a look at the driver code.  Seems we are calling
em28xx_analog_audio_set() even if it's not using vendor audio.  And
that function actually hard-codes the rate to 48KHz.

So here's the question:  if using snd-usb-audio, should we really be
poking at the AC97 registers at all?  It seems that doing such can
just get the audio processor state out of sync with however
snd-usb-audio set it up.  For example, the snd-usb-audio driver may
very well be configuring the audio to 32 KHz, and then we reset the
chip's state to 48Khz when we start streaming without the
snd-usb-audio driver's knowledge.

It seems like we should only be setting up the AC97 registers if it's
an AC97 audio processor *and* it's using vendor audio.

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: recursive locking problem

2011-09-13 Thread Devin Heitmueller

On Tue, Sep 13, 2011 at 5:34 PM, Steve Kerrison st...@stevekerrison.com wrote:
 At the risk of sounding silly, why do we rely on i2c gating so much? The
 whole point of i2c is that you can sit a bunch of devices on the same
 pair of wires and talk to one at a time.

Steve,

There are essentially two issues here.  To address the general
question, many tuner chips require an i2c gate because their onboard
i2c controller is implemented using interrupts, and servicing the
interrupts to even check if the traffic is intended for the tuner can
interfere with the core tuning function.  In other words, the cost of
the chip watching for traffic can adversely effect tuning quality.
As a result, most hardware designs are such that the demodulator gates
the i2c traffic such that the tuner only *ever* sees traffic intended
for it.

The second issue is that within the LinuxTV drivers there is
inconsistency regarding whether the i2c gate is opened/closed by the
tuner driver or whether it's done by the demod.  Some drivers have the
demod driver open the gate, issue the tuning request, and then close
the gate, while in other drivers the tuner driver opens/closes the
gate whenever there are register reads/writes to the tuner.  It's all
about the granularity of implementation (the demod approach only
involves one open/close but it's for potentially a longer period of
time, versus the tuner approach which opens/closes the gate repeatedly
as needed, which means more open/closes but the gate is open for the
bare minimum of time required).

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: recursive locking problem

2011-09-13 Thread Devin Heitmueller

On Tue, Sep 13, 2011 at 5:58 PM, Steven Toth st...@kernellabs.com wrote:
 Can any one shed some light on this? I appreciate it's not a linux or
 indeed linux-media specific issue as the hardware itself is designed
 this way.

 i2c gates exist to isolate the downstream components from any spurious
 RF noise generated by noisy components on the i2c bus. You don't want
 to couple demod noise into the tuner by default.

Steve (Kerrison),

I would take Steven Toth's explanation as more authoritative than mine
any day of the week.  It's possible that I may have been misinformed
regarding the rationale for why the gate is required.

Regards,

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: cx231xx: DMA problem on ARM

2011-09-21 Thread Devin Heitmueller

On Wed, Sep 21, 2011 at 7:56 AM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
 Hello,

 On an x86 platform, we have managed to use a Hauppauge USB Live 2
 capture device with the cx231xx on a 3.0 kernel with the patch at [1].
 Things work nicely.

 However, using a similar 3.0 kernel with the exact same device on an
 ARM platform (BeagleBoard-XM), starting a V4L application to capture
 the video immediately triggers the following BUG_ON in
 arch/arm/mm/dma-mapping.c:

 429 void ___dma_single_cpu_to_dev(const void *kaddr, size_t size,
 430         enum dma_data_direction dir)
 431 {
 432         unsigned long paddr;
 433
 434         BUG_ON(!virt_addr_valid(kaddr) || !virt_addr_valid(kaddr + size - 
 1));

 This problem looks similar to the problem fixed on the gspca driver by:

 commit 882787ff8fdeb0be790547ee9b22b281095e95da
 Author: Jason Wang jason77.w...@gmail.com
 Date:   Fri Sep 3 06:57:19 2010 -0300

    V4L/DVB: gspca - main: Fix a crash of some webcams on ARM arch

    When plugging some webcams on ARM, the system crashes.
    This is because we alloc buffer for an urb through usb_buffer_alloc,
    the alloced buffer is already in DMA coherent region, so we should
    set the flag of this urb to URB_NO_TRANSFER_DMA_MAP, otherwise when
    we submit this urb, the hcd core will handle this address as an
    non-DMA address and call dma_map_single/sg to map it. On arm
    architecture, dma_map_single a DMA coherent address will be catched
    by a BUG_ON().

    Signed-off-by: Jason Wang jason77.w...@gmail.com
    Signed-off-by: Jean-François Moine moin...@free.fr
    Cc: sta...@kernel.org
    Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 I guess the cx231xx driver is trying to DMA-map buffers whose location
 is not appropriate for DMA-mapping, because they are already in an DMA
 coherent region. Is the fix just to add the same
 URB_NO_TRANSFER_DMA_MAP to the urb-transfer_flags ? Or is it something
 completely different ?

Hi Thomas,

I ran into the same issue on em28xx in the past (which is what those
parts of cx231xx are based on).  Yes, just adding
URB_NO_TRANSFER_DMA_MAP should result in it starting to work.  Please
try that out, and assuming it works feel free to submit a patch which
can be included upstream.

Regards,

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: cx231xx: DMA problem on ARM

2011-09-22 Thread Devin Heitmueller

On Thu, Sep 22, 2011 at 10:45 AM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
 Hello,

 Le Wed, 21 Sep 2011 08:04:52 -0400,
 Devin Heitmueller dheitmuel...@kernellabs.com a écrit :

 I ran into the same issue on em28xx in the past (which is what those
 parts of cx231xx are based on).  Yes, just adding
 URB_NO_TRANSFER_DMA_MAP should result in it starting to work.  Please
 try that out, and assuming it works feel free to submit a patch which
 can be included upstream.

 So, we did try with URB_NO_TRANSFER_DMA_MAP, and now, we don't have the
 BUG_ON() assertion anymore, but instead a large set of error messages:

 [  325.856231] cx231xx #0:  setPowerMode::mode = 48, No Change req.
 [  325.858398] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8
 [  325.860656] cx231xx #0:  setPowerMode::mode = 48, No Change req.
 [  326.144073] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8
 [  326.151245] cx231xx #0: cx231xx_initialize_stream_xfer: set video registers
 [  326.151763] cx231xx #0: cx231xx_start_stream():: ep_mask = 8
 [  396.907318] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  396.912048] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  396.977355] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8
 [  396.987091] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71)
 [  456.665252] cx231xx #0:  setPowerMode::mode = 48, No Change req.
 [  456.675292] cx231xx #0: cannot change alt number to 3 (error=-71)
 [  456.714508] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.718811] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.719635] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8
 [  456.729522] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71)
 [  456.750427] cx231xx #0:  setPowerMode::mode = 48, No Change req.
 [  456.756317] cx231xx #0: cannot change alt number to 3 (error=-71)
 [  456.778625] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.782745] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.786987] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.791381] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.795501] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.795532] cx231xx #0: cx231xx_set_decoder_video_input: adjust_ref_count 
 :Failed to setAFE input mux - errCode [-71]!
 [  456.841491] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.845642] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.849792] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.854003] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.858123] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.862274] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.866394] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.870513] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.875030] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.879150] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.883239] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.887390] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.891632] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.895751] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.83] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.904174] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.914825] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.919036] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.924499] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.936920] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.941131] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.946655] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.960144] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.968658] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.984344] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  456.999572] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  457.004577] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  457.015014] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  457.019561] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  457.029083] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  457.033264] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  457.039031] cx231xx #0: UsbInterface::sendCommand, failed with status --71
 [  457.043121] cx231xx #0

Re: Problems cloning the git repostories

2011-09-25 Thread Devin Heitmueller

On Sun, Sep 25, 2011 at 8:33 AM, Patrick Dickey pdickeyb...@gmail.com wrote:
 Hello there,

 I tried to follow the steps for cloning both the media_tree.git and
 media_build.git repositories, and received errors for both.  The
 media_tree repository failed on the first line

 git clone 
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb

 which I'm assuming is because kernel.org is down.

 The media_build.git repository fails on the first line also

 git clone git://linuxtv.org/media_build.git

 with a fatal: read error: Connection reset by peer.

 Is it possible to clone either (or both) repositories at this time, or
 are they down?  And in the absence of cloning the kernel for the
 media_tree.git repository, is it possible to simply clone the
 git://linuxtv.org/media_tree.git repository and work from that?

 My interest in this is to install some patches created by Devin
 Heitmueller for the Pinnacle PCTV 80e USB tuner (at least the ATSC
 portion of the tuner). Once I'm able to determine exactly what changes
 are made, I would like to either submit the patches to the repository,
 or send them to someone who has more experience in patching the files
 for submission.

 One other question (totally unrelated to this post though): When I send
 emails, normally they are GPG signed. Should I disable that for this
 list, or is it acceptable?

 Thank you for any information, and have a great day:)
 Patrick.

Hi Patrick,

As I said on the blog, the issue isn't getting the driver to work
against current kernels.  Merging the driver against the current tree
is a trivial exercise (the patch series should apply trivially against
the current code, with only a few minor conflicts related to board
numbers, etc).

The bigger issue though is once you do that and have the driver
running, you now have a body of code  10,000 lines which doesn't meet
the coding standards.  Doing such a refactoring is a relatively
straightforward exercise but very time consuming (you already have a
working driver, so you just have to make sure you don't break
anything).

The more I think about this, the more it annoys me.  I did all the hard parts:

* I worked with the product vendor to get the details for the design
* I got Hauppauge/PCTV to compel the chipset vendor to release the
reference code under a GPL compatible license
* I worked out redistribution terms on the firmware
* I ported the driver to Linux
* I integrated the driver and debugged it to achieve signal lock

And why is it not in the mainline?  Because none of the above matters
if I didn't waste a bunch of my time removing a bunch of #ifdef
WINDOWS lines and converting whitespace from tabs to spaces.

It's crap like this that's the reason why some of the best LinuxTV
driver authors still have a bunch of stuff that isn't merged upstream.
 We just don't have time for this sort of bullshit that any monkey
could do if he/she was willing to invest the effort.  We're just too
busy doing *actual* driver work.

Five years ago the hard part was finding competent developers, getting
access to datasheets, getting access to reference driver code, and
getting access to the details for a hardware design.  Now most of
those problems are not the issue - we have access to all the data but
we want to waste the time of the few competent developers out there
making them do coding style cleanup before perfectly good code gets
merged upstream.  There has been more than one case where I've
considered doing a driver for a new board and decided against it
because the barrier to getting it upstream is not worth my time.

Want to see more device support upstream?  Optimize the process to
make it easy for the people who know the hardware and how to write the
drivers to get code upstream, and leave it to the janitors to work
out the codingstyle issues.

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: Problems cloning the git repostories

2011-09-26 Thread Devin Heitmueller

On Sun, Sep 25, 2011 at 11:25 PM, Mauro Carvalho Chehab
mauroche...@gmail.com wrote:
 I fail to see any trial from your side to send the patches upstream:
 no pull requests and no patches for this driver were _ever_ sent to
 the ML.

You and I have discussed this issue multiple times with these drivers,
including the drx-j (which is the basis for the 80e device in
question).  All the code is publicly available, and I in fact invited
you personally to pull whatever you want (as a policy we don't publish
public trees that have outstanding licensing issues).

Look how long it took to get xc4000 upstream.  Look how long it took
drx-d to get upstream.  Those trees sat there for *years* with your
full knowledge of their existence and that the only reason they
weren't merged was because of codingstyle issues.

Oh, and I did spend a bunch of hours doing cleanup work on the as102
driver, and it was still not good enough.  I decided it wasn't worth
the additional time.  That tree has only been rotting for 19 months.

 I can only guess that maybe submitting it upstream were not
 part of your contract with the vendor.

I don't even know what this means.  Commercial customers who I've done
work for almost never are willing to pay for me to merge code
upstream.  And yet code does get upstream.  Why?  Because I do it in
my free time as a courtesy to the community.

Probably also worth noting that the project in question - the 80e -
was not done for any customer.  I just did the work because I wanted
to see the device supported under Linux.

 Coding Style fixes are generally trivial, and they can be done very quickly
 with some scripting. I took only a few hours to convert drx-d and drx-k
 to the Linux Coding Style, on my spare time. The scripts I wrote for that
 are together with the commits (they're generally a few lines perl scripting
 doing some replacements). I usually do this with other drivers, when people
 submit me them with those troubles and I have some time, and never asked
 or earned a single penny for doing that.

Hey, feel free to grab the drx-j driver then.  This is like the fourth
time I'm invited you to pull the sources and do such a cleanup.  And
like I said above, I don't earn any money for such cleanups either.  I
just believe it's a colossal waste of my time that would be better
spent doing real driver development.

 Also, as I've told you several times before, code with broken coding styles
 can be submitted as-is, without any changes to drivers/staging, where they're
 fixed by kernel newbies with more time to work on that.

Last I checked you can't put demod or tuners drivers into staging
because they are a dependency of the bridge driver.  I guess maybe you
can accomplish that if you litter the bridge driver source and
makefiles with #ifdef lines.  If that situation has changed, then
great.

 So, please don't use weak arguments like that as an excuse for you to not
 submit your drivers.

Suggesting that the developers who are trying to give you working code
at zero cost is a pretty crappy way to treat them.

 Want to see more device support upstream?  Optimize the process to
 make it easy for the people who know the hardware and how to write the
 drivers to get code upstream, and leave it to the janitors to work
 out the codingstyle issues.

 The process you've just described exists already since Sept, 2008.
 It is called:
        /drivers/staging

 In summary, if you don't have a couple hours to make your driver to
 match Kernel Coding Style, just send it as is to /drivers/staging, c/c
 me and Greg KH, and that's it.

PULL http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/
PULL http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/

Have fun.

The harder you make it to get code upstream, the more developers who
will just say to hell with this.  And *that* is why there are
thousands of lines of working drivers which various developers have in
out-of-tree drivers.

You can sit in denial that there is a fundamental problem with the
management of this project and blame the developers for being lazy, or
you can take some concrete action to get the code merged upstream.

Your call.

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: Problems tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included

2011-09-28 Thread Devin Heitmueller

Hi Simon,

On Wed, Sep 28, 2011 at 8:50 AM, Simon Farnsworth
simon.farnswo...@onelan.com wrote:
 (note - the CC list is everyone over 50% certainty from get_maintainer.pl)

 I'm having problems getting a Hauppauge HVR-1110 card to successfully
 tune PAL-D at 85.250 MHz vision frequency; by experimentation, I've
 determined that the tda18271 is tuning to a frequency 1.25 MHz lower
 than the vision frequency I've requested, so the following workaround
 fixes it for me.

 diff --git a/drivers/media/common/tuners/tda18271-fe.c
 b/drivers/media/common/tuners/tda18271-fe.c
 index 63cc400..1a94e1a 100644
 --- a/drivers/media/common/tuners/tda18271-fe.c
 +++ b/drivers/media/common/tuners/tda18271-fe.c
 @@ -1031,6 +1031,7 @@ static int tda18271_set_analog_params(struct
 dvb_frontend *fe,
                mode = I;
        } else if (params-std  V4L2_STD_DK) {
                map = std_map-atv_dk;
 +                freq += 125;
                mode = DK;
        } else if (params-std  V4L2_STD_SECAM_L) {
                map = std_map-atv_l;

 I've checked with a signal analyser, and confirmed that my signal
 generator is getting the spectrum right - I am seeing vision peaking
 at 85.25 MHz, with one sideband going down to 84.5 MHz, and the other
 going up to 90.5MHz. I also see an audio carrier at 91.75 MHz.

 I'm going to run with this hack in place, but I'd appreciate it if
 someone who knew more about the TDA18271 looked at this, and either
 gave me a proper fix for testing, or confirmed that what I'm doing is
 right.

Hi Simon,

This is interesting.  I did some testing with an 18271 based device a
few months back (a Hauppauge cx231xx based tuner), and I believe
PAL-DK was working (although I did have unrelated issues with the DIF
configuration).

When you are doing the tuning request, are you explicitly stating
PAL-D in your calling application?  Or are you passing PAL to the
V4L layer and expecting it to work with a PAL-D feed?

I'm not doubting your findings, and clearly you've done a good bit of
research/analysis, but I did want to raise it as a data point to
consider

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: support for Elgato eyetv one

2011-09-28 Thread Devin Heitmueller

2011/9/28 Tim Bolder timbol...@gmail.com:
 Hi,

 I was wondering if the Elago eyetv one is on the list for (near) future 
 support.
 I've tried to make te device work with the settings of other eyetv
 devices but wit no luck.

 I have attached a lsusb log for mor info on the device.

To my knowledge nobody is working on it.  In general the Mac products
tend to be much more expensive than their Windows equivalents, and
thus very few developers own units to test/debug with.

For example, I added support for one of the original EyeTV products
which I added the driver support for, but it was a fluke that it fell
in my lap.  I wouldn't have gone out and spent $129.00 to buy one just
to add Linux support for it.

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: Problems tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included

2011-09-30 Thread Devin Heitmueller

On Fri, Sep 30, 2011 at 7:59 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Michael/Devin may be able to double check what tda18271 variants are used at 
 the
 hvr1100 supported models.

Mike could confirm definitively but I would be very surprised if it
was anything other than a C2.  I also don't think we've had multiple
revisions of that board (other than the ones in the list which were
all released at the same time and are just different population
options).

All that said, I also wonder if perhaps this is an issue with the
analog demod as opposed to the tuner.  It feels unlikely but that
might explain why I didn't see similar results when I did the testing
on the cx231xx/tda18271 combo back in February.

The big problem here really though is that somebody who is
knowledgeable of the driver internals needs to dig into the issue, and
I don't foresee that happening in the immediate future (I cannot speak
for Michael but I've been too tied up in other projects).  I'm
definitely not discounting Simon's skills or findings, but this needs
to be investigated in a context beyond the tuner/demod combination
found on a single product.

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: fm player for v4l2

2011-10-05 Thread Devin Heitmueller

On Wed, Oct 5, 2011 at 2:32 PM, Will Milspec will.mils...@gmail.com wrote:
 hi all,

 After recent-ish kernel updates, fmtools no longer works.  (I'm
 running gentoo currently on kernel 3.0.6)

 I believe the changes pertain to V4L1 vs L2 api changes. I am not a
 linux developer, however, and can't speak w/ authority.

 I've appended my v4l-info at the end of this email

 Example Failing Command
 ==
 $fm 91.5
 ioctl VIDIOCGAUDIO: Invalid argument

 Kernel V4L options
 ==
 Here's my kernel configuration:

 CONFIG_VIDEO_V4L2_COMMON=y
 CONFIG_VIDEO_V4L2=y
 CONFIG_V4L_USB_DRIVERS=y
 # CONFIG_V4L_MEM2MEM_DRIVERS is not set


 Can anyone recommend:
 - any fm software that works w/ V4L2?
 - any kernel tweaks I can make to keep the old fmtools app working?
 - any other next steps

Unfortunately, despite V4L1 having been deprecated almost a decade
ago, essentially every application out there was still depending on it
at the source code level.  Once the kernel finally dropped the support
entirely, changes were required to MythTV, tvtime, xawtv, for them to
start working again (pretty much every project I know of went oh
crap when it disappeared).

Somebody will probably have to fix the fmtools source code to no
longer depend on V4L1.

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: tvtime at linuxtv.org

2011-10-07 Thread Devin Heitmueller

On Thu, Oct 6, 2011 at 9:59 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Hi Devin,

 I had some discussions with Mikael today at the #linuxtv channel about
 tvtime. Mikael has write access to the tvtime site at sourceforge and he
 is doing some maintainance on it for some time, and worked on some bugs
 from Gentoo, and also imported some stuff from Ubuntu.

 I've merged his patches on my repository:
        http://git.linuxtv.org/mchehab/tvtime.git

 Tvtime is compiling, at least on Fedora 15. I also added your patch there,
 and changed the latency delay to 50ms. I didn't test it yet. I'll do it
 later
 today or tomorrow.

 Btw, Mikael updated the Related Sites there to point to the LinuxTV site:
        http://tvtime.sourceforge.net/links.html

 He will try to contact Vektor again, in order to get his ack about adding
 a note at the main page pointing to us.

 I think we should move those patches to the main repository after testing
 the
 merges, and give write rights to the ones that are interested on maintaining
 tvtime.

 I'm interested on it, and also Mikael.

 IMHO, after testing it and applying a few other patches that Mikael might
 have,
 it is time for us to rename the version to 1.10 and do a tvtime release.

 Would that work for you?

 Thank you!
 Mauro

Hi Mauro,

It's good to hear that patches are continuing to be merged, and of
course contributors are always welcome.

The more I think about this, the more I recognize that I'm not really
adding any value to this process.  While I would really like to put
more time/energy into tvtime, I just don't have the time and it
appears I'm actually slowing down a community of contributors who are
trying to move things forward.

At this point I would recommend the LinuxTV community just take over
the project, give yourself write access to the main repo, and spin a
release.  I would indeed recommend calling it 1.10, to prevent
confusion with the various vendor branches where I believe some of
which may actually already be calling themselves 1.03.

Regarding expanding the list of individuals with commit rights, I
might suggest keeping the list of write privileges for the main repo
to a minimum in the short term (starting with yourself), until
developers have demonstrated their ability to author coherent patches
which won't cause breakage as well as the ability to review the work
of others.

Cheers,

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: where is the cx23887 module in kernel-3.04 config?

2011-10-12 Thread Devin Heitmueller

On Wed, Oct 12, 2011 at 4:42 PM, James bjloc...@lockie.ca wrote:
 On 10/12/11 16:30, James wrote:

 Where is the cx23887 module in the kernel-3.04 config?
 I'm trying to get a Hauppauge WinTV-HVR-1250 working.
 --
 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

 Found it under video4lnux driver and not DVB/ATSC adapters (which seems more
 logical).

In general, everything that is a hybrid card is under media/video.
That's just a product of the way the two trees evolved (v4l vs.
dvb)...

Steven actually has a tree which I believe has support for pretty much
every 1250 variant.  It's not merged upstream though, so you will
likely have to do some tweaking of the code to make it work with
current kernels.

http://kernellabs.com/hg/~stoth/cx23888-encoder/

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: digital tuner

2011-10-12 Thread Devin Heitmueller

On Thu, May 12, 2011 at 3:49 PM, James bjloc...@lockie.ca wrote:

 I have an analog: Hauppauge WinTV-Go PLUS which has a lineout.

 I'm considering a digital card.
 The Hauppauge WinTV-HVR-1250 does NOT have a lineout so how does it do
 sound?
 Does PCIe pass through the sound to the OS sound system?
 I read on the linuxtv wiki that only the digital works on this card.

You've probably already figured this out by now, but the cx23885 does
have an ALSA driver, which isn't yet upstream.  Igor actually just
rebased Steven's tree with the support against the latest kernel, so
hopefully it will make it upstream soon (see the linux-media mailing
list for the last couple of days to find the thread).

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: recent cx23385?

On Thu, Oct 13, 2011 at 1:59 AM, James bjloc...@lockie.ca wrote:
 Is there a newer cx23385 driver than the one in kernel-3.0.4?
 I bought a http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250 and it
 shows video for about 5 seconds and then locks up the system.

You cannot install individual drivers (Linux doesn't work like Windows
in this regards).  You have to either install the latest kernel or you
can swap out the whole media subsystem with a later version.

http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

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: PCTV 520e on Linux

On Thu, Oct 13, 2011 at 10:49 AM, Claus Olesen ceole...@gmail.com wrote:
 I'm looking for a USB stick for DVB-C on Linux,
 have good experience with the PCTV nanoStick T2 290e for DVB-T on
 Linux (except for the replug issue)

I believe the replug issue is probably fixed if you're using the
current media_build tree.

 http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx
 and wonder if anyone know the status of support, if any, of the PCTV
 QuatroStick nano 520e for DVB-C on Linux?
 http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx

No support currently.  I have the stick, but haven't had any time to work on it.

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: PCTV 520e on Linux

On Thu, Oct 13, 2011 at 12:07 PM, Antti Palosaari cr...@iki.fi wrote:
 No support currently.  I have the stick, but haven't had any time to work
 on it.

 Is that EM28xx + DRX-K + TDA18217 ? And analog parts...

You were close:  em2884, drx-k, xc5000, and for analog it uses the afv4910b.

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: PCTV 520e on Linux

On Thu, Oct 13, 2011 at 12:19 PM, Antti Palosaari cr...@iki.fi wrote:
 You were close:  em2884, drx-k, xc5000, and for analog it uses the
 afv4910b.

 Then it should be peace of cake at least for digital side.

I don't think we've ever done xc5000 on an em28xx before, so it's
entirely possible that the xc5000 clock stretching will expose bugs in
the em28xx i2c implementation (it uncovered bugs in essentially every
other bridge driver I did work on).

That, and we don't know how much is hard-coded into the drx-k driver
making it specific to the couple of device it's currently being used
with.

But yeah, it shouldn't be rocket science.  I added support for the
board in my OSX driver and it only took me a couple of hours.

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: recent cx23385?

On Thu, Oct 13, 2011 at 12:31 PM, James bjloc...@lockie.ca wrote:
Where do I see the date/version of the media subsystem?

You can't. The media_build stuff is just a script which backports
part of the latest kernel tree and applies some patches to make it
work with older kernels. There is no real version for it.

It is not video related, w_scan works sometimes but freezes the kernel
sometimes.
This is booting right to a console.
Is there a program to do a stress test on the hardware and print lots of
messages as it's working?

Not really, you can add the debug=1 modprobe option, but in reality
you probably need to get to the bottom of what is causing the hardware
lockup.

I did:
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
/bin/sh: /sbin/lsmod: No such file or directory
Lot's of pr_fmt redefined errors.

lsmod is required. Go install whatever package provides it.

I put the build log at: lockie.ca/test/v4l_build.txt.bz2

Something is not right though. :-(
$ modprobe cx23885
WARNING: Deprecated config file /etc/modprobe.conf, all config files belong
into /etc/modprobe.d/.
WARNING: Error inserting altera_ci
(/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/altera-ci.ko):
Invalid module format
WARNING: Error inserting media
(/lib/modules/3.0.4/kernel/drivers/media/media.ko): Invalid module format
WARNING: Error inserting videodev
(/lib/modules/3.0.4/kernel/drivers/media/video/videodev.ko): Invalid module
format
WARNING: Error inserting v4l2_common
(/lib/modules/3.0.4/kernel/drivers/media/video/v4l2-common.ko): Invalid
module format
WARNING: Error inserting videobuf_core
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-core.ko): Invalid
module format
WARNING: Error inserting videobuf_dvb
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dvb.ko): Invalid
module format
WARNING: Error inserting videobuf_dma_sg
(/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dma-sg.ko): Invalid
module format
WARNING: Error inserting cx2341x
(/lib/modules/3.0.4/kernel/drivers/media/video/cx2341x.ko): Invalid module
format
WARNING: Error inserting altera_stapl
(/lib/modules/3.0.4/kernel/drivers/linux/drivers/misc/altera-stapl/altera-stapl.ko):
Invalid module format
WARNING: Error inserting rc_core
(/lib/modules/3.0.4/kernel/drivers/media/rc/rc-core.ko): Invalid module
format
FATAL: Error inserting cx23885
(/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/cx23885.ko): Invalid
module format

Your build is screwed up. Would recommend you do a make clean and
then make make install. Then reboot.

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: help with azap

On Thu, Oct 13, 2011 at 2:14 PM, James bjloc...@lockie.ca wrote:
 $ more channels.conf
 CIII-HD:8500:8VSB:49:52+53:1
 OTTAWA CBOFT-DT:18900:8VSB:49:53+52:3
 CJOH:21300:8VSB:49:51+52:1
 TVO    :53300:8VSB:49:52+53:1
 OTTAWA  CBOT-DT:53900:8VSB:49:52+53:3
 Télé-Québec_HD:56900:8VSB:49:52+53:3
 CHOT:62900:8VSB:49:52:3

 $ azap -c channels.conf CJOH
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 ERROR: error while parsing Audio PID (not a number)

 $ tzap -c channels.conf CJOH
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 reading channels from file 'channels.conf'
 ERROR: error while parsing inversion (syntax error)

 Why does tzap show what file it is reading the channel list from but azap
 doesn't?

If I recall, tzap and azap are actually from different codebases
(although I believe one was originally derived from the other).  That
is why the output is a little inconsistent.

That said, you should not be using tzap for ATSC/ClearQAM.  tzap is for DVB-T.

 What does ERROR: error while parsing Audio PID (not a number) mean?

I don't know where your channels.conf came from, but it appears to be
malformed.  You cannot have 52+53 as the audio PID.  If you just
want to get up and running, remove the +53 part.

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: PCTV 520e on Linux

On Thu, Oct 13, 2011 at 7:06 PM, Benjamin Larsson benja...@southpole.se wrote:
 On 10/13/2011 07:48 PM, Devin Heitmueller wrote:
 On Thu, Oct 13, 2011 at 12:19 PM, Antti Palosaari cr...@iki.fi wrote:
 You were close:  em2884, drx-k, xc5000, and for analog it uses the
 afv4910b.
 Then it should be peace of cake at least for digital side.
 I don't think we've ever done xc5000 on an em28xx before, so it's
 entirely possible that the xc5000 clock stretching will expose bugs in
 the em28xx i2c implementation (it uncovered bugs in essentially every
 other bridge driver I did work on).

 That, and we don't know how much is hard-coded into the drx-k driver
 making it specific to the couple of device it's currently being used
 with.

 But yeah, it shouldn't be rocket science.  I added support for the
 board in my OSX driver and it only took me a couple of hours.

 Devin


 Eddi De Pieri has patches for the HVR-930C that works somewhat. The
 hardware in that stick is the same.

 MvH
 Benjamin Larsson

While the basic chips used are different, they are completely
different hardware designs and likely have different GPIO
configurations as well as IF specs.

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: [PATCH] dvb/as102 nBox DVB-T dongle

On Fri, Oct 14, 2011 at 8:36 AM, Piotr Chmura chmoor...@poczta.onet.pl wrote:
 Hi,

 There's  licencing problem with as10x_cmd_cfg.c and as10x_cmd_stream.c files
 which are not GPL ( (c) Copyright Abilis Systems SARL 2005-2009 All rigths
 reserved \n
   www.abilis.com).

 Dunno if it's only Davin's Heitmueller oversight in changing licencing or a
 real problem.
 What about it Davin ?

Yeah, those were an oversight on the part of Abilis.  I already talked
to them about it and got permission to fix the text.

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: PCTV 520e on Linux

On Fri, Oct 14, 2011 at 9:19 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 While the basic chips used are different, they are completely
 different hardware designs and likely have different GPIO
 configurations as well as IF specs.

 The IF settings for xc5000 with DRX-K are solved with this patch:
        http://patchwork.linuxtv.org/patch/7932/

 Basically, DRX-K will use whatever IF the tuner uses.

While I fundamentally disagree with this change, I'm not going to nack
it.  That said, this wasn't the issue I was concerned with.  My
suggestion was simply that you cannot assume that all devices that
happen to have a particular demod and tuner combo will always use the
same IF configuration.  The PCB layout can effect the optimal IF.

This is one of those things that (like many tuners in the LinuxTV
tree) will probably work good enough to get a signal lock for whoever
added the board profile, but will result in poor tuning performance
(and a failure to work in less-than-ideal reception conditions).

All that said, if somebody actually intends to hack on it, I can look
up what the correct IF is for the 520e.

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: PCTV 520e on Linux

On Fri, Oct 14, 2011 at 10:01 AM, Sönke Brandt sbra...@pctvsystems.com wrote:
  Just a quick note: The 520e does use the TDA18271 tuner, not an XC5000.

  Soenke.

Wow, how the hell did I screw that up?  Of course Sönke is correct.  I
momentarily got the 520e confused with the HVR-930c (I've done work on
both in the past).

Regards,

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: PCTV 520e on Linux

On Fri, Oct 14, 2011 at 12:14 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 The tda18271-dd/drx-k/em28xx combination works fine, provided that the GPIO
 initialization enables both tuner and demod during probe time. Currently, the
 device I used to add support for it (a Terratec H5) has a hack to enable
 the devices: it just replies whatever initialization the original driver does.

 When I have some time, I'll fix that, but I'm not urging doing so, because it
 just works ;)

 In order to add support for PCTV 520e, it is probably a matter of just set the
 GPIO's.

Complements of our friends at PCTV:

520e:
GPIO02: Decoder Reset, active-low
GPIO04: Decoder Suspend, active-low
GPIO06: Demod Reset, active-low
GPIO07: LED on, active-high

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: PCTV 520e on Linux