Re: please update V4L-DVB wiki concerning Compro DVD-T300 support
On Thu, Jun 10, 2010 at 10:20 PM, Rohan Carly 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
please update V4L-DVB wiki concerning Compro DVD-T300 support
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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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
Re: V4L Camera frame timestamp question
Hi,
2010/6/10 Jiajun Zhu :
> 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
No frontend0 for Technotrend Budget 3200
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: [PATCH] dvb_frontend: fix typos in comments and one function
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
Re: [GIT PATCHES FOR 2.6.35] gspca for_2.6.35
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: [GIT PATCHES FOR 2.6.35] gspca for_2.6.35
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 : > 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: V4L Camera frame timestamp question
2010/6/10 Jean-Francois Moine : > On Thu, 10 Jun 2010 03:24:05 + (UTC) > jiajun 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
[GIT PATCHES FOR 2.6.35] gspca for_2.6.35
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
On Thu, 10 Jun 2010 03:24:05 + (UTC) jiajun 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
[REGRESSION] saa7134 + ir
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: [] 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:[] 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] [] ? __ir_input_register+0x258/0x2d7 [ir_core] [ 177.112231] [] ? ir_probe+0x452/0x50f [ir_kbd_i2c] [ 177.112234] [] ? ir_probe+0x0/0x50f [ir_kbd_i2c] [ 177.112240] [] ? i2c_device_probe+0x72/0x8d [i2c_core] [ 177.112244] [] ? driver_probe_device+0x76/0xfe [ 177.112247] [] ? __driver_atta
