Re: Is anybody working on TechniSat CableStar Combo HD CI USB device?

2010-06-10 Thread BOUWSMA Barry
On Tue (Tuesday) 08.Jun (June) 2010, 12:14,  Bjørn Mork wrote:

 Markus Rechberger mrechber...@gmail.com writes:
 
  Trident is also still improving the quality of their driver and
  firmware, it very much makes
  sense that they handle their driver especially since those DRX drivers
  are very complex
  (basically too complex for being handled by the community, the drivers
  would just
  end up somewhere unmaintained).
 
 Ouch.  That makes me wonder about the state of the Windows drivers for
 those devices...  Better stay away from them, I guess.

Just to throw this out there, the 'doze support for one such
Micronas-based device I have -- the Linux kernel support for which
either does not exist or cannot be publicly distributed -- is less
than optimal in my experience, which may have nothing to do with
reality.

While I was able to make a flawless test recording for a few
minutes of one medium-bitrate lower-resolution high-definition
programme to mislead me into thinking that I'd have success with
a full-length programme, for some reason it turned out that my use
of the device under 'doze for an extended time on a borrowed 'doze
box suffered fairly frequent problems manifested each as a short
dropout of the recording.

This could also be pilot error, as I remain willfully ignorant of
'doze and its details, but if a machine with CPU horsepower over
eight times that (neglecting other acceleration) of my workhorse
that routinely makes four simultaneous flawless recordings
including some at higher resolution/bitrate, is unable to keep up
with the bitstream, then something has got to be seriously wrong,
in my opinion.

A later recording of a higher bitrate (excellent quality standard-
definition video source) stream again exhibited the same problem.
Perhaps 'doze can't keep up writing to its own native filesystem
as it approaches being full, or if I can't keep my hands away from
configuring it to be user-hostile as I prefer.

And of course there's the factor of intermediate hardware to be
considered -- my device is connected via a USB interface which has
caused major filesystem corruption over time with the particular
Linux kernel I was using, despite of working flawlessly with a
different video card.  And 'doze...  *shiver*

Anyway, I'd be happy to learn that others have had success with
the same device, although for me it's no longer a priority to have
it working, to say nothing of working perfectly.  My testing of
the device has been relatively minimal, using it where other tuner
cards lack support.


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


[REGRESSION] saa7134 + ir

2010-06-10 Thread Dmitri Belimov
Hi

I have regression with our TV cards + I2C r/c and new IR subsystem.
modules crashed

[  148.461819] Linux video capture interface: v2.00
[  148.462768] IR NEC protocol handler initialized
[  148.482886] saa7130/34: v4l2 driver version 0.2.16 loaded
[  148.482925] saa7134 :04:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19
[  148.482931] saa7133[0]: found at :04:01.0, rev: 209, irq: 19, latency: 
32, mmio: 0xe510
[  148.482936] saa7133[0]: subsystem: 5ace:7595, board: Beholder BeholdTV X7 
[card=171,autodetected]
[  148.482949] saa7133[0]: board init: gpio is 20
[  148.482955] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[  148.483938] IR RC5(x) protocol handler initialized
[  148.491808] IR RC6 protocol handler initialized
[  148.499804] IR JVC protocol handler initialized
[  148.507796] IR Sony protocol handler initialized
[  148.632009] saa7133[0]: i2c eeprom 00: ce 5a 95 75 54 20 00 00 00 00 00 00 
00 00 00 01
[  148.632028] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632045] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632061] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632078] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632094] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632110] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632127] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632143] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632159] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632176] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632197] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632205] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632212] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632220] saa7133[0]: i2c eeprom e0: 00 00 00 00 ff ff ff ff ff ff ff ff 
ff ff ff ff
[  148.632227] saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff 
ff ff ff ff
[  148.652048] tuner 1-0061: chip found @ 0xc2 (saa7133[0])
[  148.763651] xc5000 1-0061: creating new instance
[  148.772018] xc5000: Successfully identified at address 0x61
[  148.772021] xc5000: Firmware has not been loaded previously
[  177.112011] Registered IR keymap rc-behold
[  177.112046] BUG: unable to handle kernel NULL pointer dereference at (null)
[  177.112052] IP: [f80589d0] ir_register_class+0x3d/0x14e [ir_core]
[  177.112063] *pde =  
[  177.112067] Oops:  [#1] SMP 
[  177.112072] last sysfs file: 
/sys/devices/pci:00/:00:1e.0/:04:01.0/resource
[  177.112076] Modules linked in: rc_behold ir_kbd_i2c(+) xc5000 tuner 
ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder saa7134(+) 
v4l2_common ir_nec_decoder videodev v4l1_compat videobuf_dma_sg videobuf_core 
ir_common ir_core tveeprom ppdev lp ipv6 dm_snapshot dm_mirror dm_region_hash 
dm_log dm_mod sha1_generic arc4 ecb ppp_mppe ppp_generic slhc loop 
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss 
snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event 
snd_seq snd_timer snd_seq_device snd parport_pc parport soundcore i2c_i801 
tpm_tis tpm psmouse snd_page_alloc intel_agp i2c_core processor button tpm_bios 
serio_raw agpgart rng_core pcspkr evdev ext3 jbd mbcache sg sr_mod cdrom sd_mod 
ata_generic ata_piix libata scsi_mod ide_pci_generic ehci_hcd uhci_hcd ide_core 
r8169 mii usbcore nls_base thermal fan thermal_sys [last unloaded: 
scsi_wait_scan]
[  177.112185] 
[  177.112194] Pid: 3062, comm: modprobe Not tainted 2.6.33-tm6000 #7 
G31M-S2L/G31M-ES2L
[  177.112196] EIP: 0060:[f80589d0] EFLAGS: 00010246 CPU: 0
[  177.112199] EIP is at ir_register_class+0x3d/0x14e [ir_core]
[  177.112201] EAX: f8059a68 EBX: fff4 ECX:  EDX: 
[  177.112203] ESI: f5cfa600 EDI: f5e24000 EBP: f5e24000 ESP: f5ea5e88
[  177.112205]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  177.112207] Process modprobe (pid: 3062, ti=f5ea4000 task=f721d100 
task.ti=f5ea4000)
[  177.112208] Stack:
[  177.112209]   fff4  f5cfa600 f5e24000 f8058590  
f8219044
[  177.112214] 0 f5cfa6b4 f5cfa6d0 0282  f5e24000 f8219044 
f5f923e4 f81f1478
[  177.112218] 0 f81f1b24 f66a1580 f81c0d5a f81c0d51 f5e24000 f6bd0174 
002d f5f92380
[  177.112224] Call Trace:
[  177.112227]  [f8058590] ? __ir_input_register+0x258/0x2d7 [ir_core]
[  177.112231]  [f81f1478] ? ir_probe+0x452/0x50f [ir_kbd_i2c]
[  177.112234]  [f81f1026] ? ir_probe+0x0/0x50f [ir_kbd_i2c]
[  177.112240]  [f83b3226] ? i2c_device_probe+0x72/0x8d [i2c_core]
[  177.112244]  [c1198d11] ? 

Re: V4L Camera frame timestamp question

2010-06-10 Thread Jean-Francois Moine
On Thu, 10 Jun 2010 03:24:05 + (UTC)
jiajun zhujia...@gmail.com wrote:

 I'm currently using the V4L-DVB driver to control a few logitech
 webcams and playstation eye cameras on a Gubuntu system.
 
 Everything works just fine except one thing:  the buffer timestamp
 value seems wrong.
[snip]
 this should be the timestamp of when the image is taken (similar to
 gettimeofday() function)
 but the value I got is something way smaller (e.g. 75000) than what
 it should be (e.g. 1275931384)
 
 Is this a known problem?

Hi,

No, I did not know it! Thank you. I will try to fix it for the kernel
2.6.35.

Best regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PATCHES FOR 2.6.35] gspca for_2.6.35

2010-06-10 Thread Jean-Francois Moine
Hi Mauro,

The following changes since commit e411f2dda48c81c556c802d4430717950cf088fd:

  Merge branch 'for-linus' of git://git.monstr.eu/linux-2.6-microblaze 
(2010-06-09 08:52:03 -0700)

are available in the git repository at:

  git://linuxtv.org/jfrancois/gspca.git for_2.6.35

Jean-François Moine (1):
  gspca - main: Set the wall time as buffer timestamp.

 drivers/media/video/gspca/gspca.c |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)

Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: V4L Camera frame timestamp question

2010-06-10 Thread Paulo Assis
2010/6/10 Jean-Francois Moine moin...@free.fr:
 On Thu, 10 Jun 2010 03:24:05 + (UTC)
 jiajun zhujia...@gmail.com wrote:

 I'm currently using the V4L-DVB driver to control a few logitech
 webcams and playstation eye cameras on a Gubuntu system.

 Everything works just fine except one thing:  the buffer timestamp
 value seems wrong.
        [snip]
 this should be the timestamp of when the image is taken (similar to
 gettimeofday() function)
 but the value I got is something way smaller (e.g. 75000) than what
 it should be (e.g. 1275931384)

 Is this a known problem?

 Hi,

 No, I did not know it! Thank you. I will try to fix it for the kernel
 2.6.35.


You can't use gettimeofday for timestamps or you will have big
problems if your clock changes when you are grabbing video.
You must use a monotonic clock, this is what gspca and uvc are doing,
they now use ktime, a monotonic highres clock.
This prevents time shifts that can break the video stream playback,
also gettimeofday as problems in multicore cpus since for most
processors
the internal cpus are not exactly in sync.

So PLEASE leave it like it is now, also other drivers should really
move into using ktime nad not gettimeofday.

You are converting the timestamp to seconds this will produce a
smaller value, you should really convert it to ms, then you would get
a value closer to what you want.

Best Regards,
Paulo

 Best regards.

 --
 Ken ar c'hentañ |             ** Breizh ha Linux atav! **
 Jef             |               http://moinejf.free.fr/
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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 PATCHES FOR 2.6.35] gspca for_2.6.35

2010-06-10 Thread Paulo Assis
PLEASE NO,
The current use of ktime is much better, timestamps are perfectly in
sync and will not suffer from time shifts if the clock value changes.

PLEASE just leave it like it is now.

Best Regards,
Paulo

2010/6/10 Jean-Francois Moine moin...@free.fr:
 Hi Mauro,

 The following changes since commit e411f2dda48c81c556c802d4430717950cf088fd:

  Merge branch 'for-linus' of git://git.monstr.eu/linux-2.6-microblaze 
 (2010-06-09 08:52:03 -0700)

 are available in the git repository at:

  git://linuxtv.org/jfrancois/gspca.git for_2.6.35

 Jean-François Moine (1):
      gspca - main: Set the wall time as buffer timestamp.

  drivers/media/video/gspca/gspca.c |   15 ---
  1 files changed, 12 insertions(+), 3 deletions(-)

 Thanks.

 --
 Ken ar c'hentañ |             ** Breizh ha Linux atav! **
 Jef             |               http://moinejf.free.fr/
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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 PATCHES FOR 2.6.35] gspca for_2.6.35

2010-06-10 Thread Laurent Pinchart
On Thursday 10 June 2010 11:25:41 Paulo Assis wrote:
 PLEASE NO,
 The current use of ktime is much better, timestamps are perfectly in
 sync and will not suffer from time shifts if the clock value changes.
 
 PLEASE just leave it like it is now.

Agreed. The V4L2 spec should be modified.

-- 
Regards,

Laurent Pinchart
--
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_frontend: fix typos in comments and one function

2010-06-10 Thread Guillaume Audirac
Hi Steven,

 This and your other two patches are in
 http://www.kernellabs.com/hg/~stoth/saa7164-dev

 They look good to me.

What is the proper process to see the patches accepted and integrated ? I
want to be aligned with the way of working before sending other
corrections or improvements.

Thanks.

-- 
Guillaume

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


No frontend0 for Technotrend Budget 3200

2010-06-10 Thread Tobias Trus
Hello,

I've got a Technotrend Budget 3200 installed in my Kubuntu Lucid (10.04) 
machine. It worked fine out of the box. Because I want to watch a broadcast and 
record another one at the same time I bought another DVB-Card. This time I 
bought a Technisat Skystar HD2 because with the TT Budget I've problems 
getting a lock on some channels.

To getting the Technisat SkyStar HD2 work I compiled and installed the actual 
v4l-dvb-drivers using hg clone http://linuxtv.org/hg/v4l-dvb.

Now the Technisat worked fine but the frontend0-entry for the Technotrend is 
missing. Does anybody know how to fix it?

best regards
Tobias
--
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 Camera frame timestamp question

2010-06-10 Thread Paulo Assis
Hi,

2010/6/10 Jiajun Zhu zhujia...@gmail.com:
 Thanks for the discussion.
 Based on my testing, the image timestamps or ktime is the system uptime in
 nanosecond, is this correct?
 For my application, I need to synchronize the camera image with other data
 which are all timestamped by gettimeofday().

Like I explained gettimeofday is not the proper way to set timestamps,
you should use a monotonic clock:

e.g.:

//timestamps in nanosec
uint64_t ns_time_monotonic()
{
static struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, ts);
return ((uint64_t) ts.tv_sec * G_NSEC_PER_SEC + (uint64_t) ts.tv_nsec);
}

This will give you a similar timestamp to ktime.

 How would you suggest me to do this?
 I can think of two options:
 1.  Get the system uptime and compute the offset between gettimeofday() at
 the start of my program, and then use this offset
      to correct all the image timestamps.
      The only linux userspace function I can find to get system uptime is to
 read /proc/uptime file, which resolution is 0.01 seconds.
 2.  Hack the camera driver to use do_getimeofday() instead of ktime, and
 ignore all the problems you guys mentioned earlier.
 Any comments?

In my case to sync audio and video timestamps I just take the first
video ts and check it against the
initial audio ts (taken with the above function) , remember that for
timestamps the important thing is the delta between them,
so you can store the first one and just use the difference for the
next  ones. e.g.:

//timestamps in nanosec

if (first_frame)
 ts_ref = (uint64_t) buf.timestamp.tv_sec * 10 +
buf.timestamp.tv_usec *1000;

frame_ts =  ((uint64_t) buf.timestamp.tv_sec * 10 +
buf.timestamp.tv_usec *1000)  - ts_ref;

now you can also use ts_ref for audio timestamps.

If you really need to use getttimeofday (very bad idea), you just need
the timeofday for the first (ref_ts) timestamp
for the others just use the delta.

so when you grab the first frame also get the value of getimeofday()
(in the same time base), that's that simple, from then on just do:

 initial_frame_timeofday + frame_ts


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


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

2010-06-10 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Thu Jun 10 19:00:22 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14974:023a0048e6a8
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

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

Detailed results are available here:

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

Full logs are available here:

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

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

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


please update V4L-DVB wiki concerning Compro DVD-T300 support

2010-06-10 Thread Rohan Carly
Hi, I had success with some TV tuner hardware that wasn't listed on the 
linuxtv.org V4L-DVB wiki. Could you please update it?


The relevant section is here:
http://www.linuxtv.org/wiki/index.php/DVB-T_PCI_Cards#Compro

My device is a Compro DVD-T300 (purchased in Australia):

lime:~# lspci | grep -i saa
01:06.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video 
Broadcast Decoder (rev 01)


I use Debian 5 (lenny) and it seemed to be detected fine when I installed the 
AMD64 kernel/system.
When I installed the 32-bit x86 kernel/system (using a 64bit cpu) detection 
didn't seem to be automatic anymore.


Symptom: after modprobe saa7134 , /dev/video0  was created, but not /dev/dvb

Solution...

After reading this website:
http://en.gentoo-wiki.com/wiki/Saa7134
I discovered that I had to do instead
modprobe saa7134 card=70

zcat 
/usr/share/doc/linux-doc-2.6.26/Documentation/video4linux/CARDLIST.saa7134.gz 
| grep -i compro

 19 - Compro VideoMate TV  [185b:c100]
 40 - Compro VideoMate TV PVR/FM   [185b:c100]
 41 - Compro VideoMate TV Gold+[185b:c100]
 49 - Compro VideoMate Gold+ Pal   [185b:c200]
 62 - Compro VideoMate TV Gold+II
 70 - Compro Videomate DVB-T300[185b:c900]
 71 - Compro Videomate DVB-T200[185b:c901]
103 - Compro Videomate DVB-T200A
139 - Compro VideoMate T750[185b:c900]

Hope this helps some people,

Rohan Carly.

--
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: please update V4L-DVB wiki concerning Compro DVD-T300 support

2010-06-10 Thread Devin Heitmueller
On Thu, Jun 10, 2010 at 10:20 PM, Rohan Carly se...@rohan.id.au wrote:
 Hi, I had success with some TV tuner hardware that wasn't listed on the
 linuxtv.org V4L-DVB wiki. Could you please update it?

The Wiki is open to anyone's contributions.  If you have found an
inaccuracy or some missing info, you should feel free to just create
an account and contribute the changes yourself.

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