RE: Global Video Buffers Pool - PMM and UPBuffer reference drivers [RFC]
Hello,
On Monday, October 12, 2009 6:00 PM Russell King wrote:
Below are some brief comments from having looked through the code. I
don't intend to suggest that they're anywhere near complete though,
but are observations I've spotted today.
Thank you for your review!
On Thu, Oct 01, 2009 at 12:39:29PM +0200, Marek Szyprowski wrote:
arch/arm/mach-s3c6410/Kconfig |1 +
arch/arm/mach-s3c6410/include/mach/pmm-plat.h | 40 +
drivers/Kconfig |3 +
drivers/Makefile |1 +
drivers/s3cmm/Kconfig | 142 +++
drivers/s3cmm/Makefile|9 +
drivers/s3cmm/pmm-init.c | 75 ++
drivers/s3cmm/pmm.c | 1400
+
drivers/s3cmm/upbuffer.c | 608 +++
include/linux/s3c/pmm.h | 141 +++
include/linux/s3c/upbuffer.h | 131 +++
ipc/shm.c | 24 +-
mm/shmem.c| 55 +-
Does this have to be s3c specific, or can this be turned into something
generic?
In our opinion our approach can be generic, at least for UMA systems with
a lot of devices that can work only with memory buffers that are contiguous
in physical memory. We have however no idea where it should be placed in
drivers directory tree, that's why we left it in our custom s3c directories.
[snip]
+static int direct_pfn_prepare(struct upbuf *b, struct vm_area_struct *vma)
+{
+ struct upbuf_private *priv = b-priv;
+ unsigned long start, base;
+ int page_count, i, res;
+ pte_t pte;
+
+ debug(direct_pfn_prepare\n);
+
+ if (!(vma-vm_flags VM_PFNMAP) || !vma-vm_file) {
+ return -EINVAL;
+ }
+
+ page_count = priv-page_count;
+ BUG_ON(!page_count);
+
+ debug(Direct PFN mapping found,
+ using special file reference counter.\n);
+
+ /* increment vma file use count before hacking with pte map */
+ get_file(vma-vm_file);
I do hope you're not under the impression that getting the file in some
way protects the pte map? My understanding is the only thing which
protects page tables (and VMAs) is vma-vm_mm-mmap_sem.
If you want to protect against VMAs going away, read-lock it. If you
want to modify VMAs, write-lock it. Also, only a write lock will also
protect against the page fault handler changing the page tables (since
it will want to gain a read-lock.)
Good point. In our approach memory buffers can be locked for a long time
and we don't want to lock the whole applications memory management and
address space (vm_mm) for such a long time. That's why we were looking
for alternative way.
We decided to protect the physical memory of the buffer not the vma area
itself. If we can ensure that the physical memory would not be reused by
other application until the driver finishes the multimedia transaction,
everything would be fine. If user application unmap the vma area before
the multimedia transaction finishes, it is its own fault. We don't care
about that, unless it causes security issues with other applications.
This is of course for virtual mappings. What we cannot accept though is
the physical memory (from our PMM allocator) being freed before the
transaction is finished.
In our approach we rely on the fact that PMM uses free-after-release
semantic, which means that the allocated physical memory is freed only
after releasing the file that was used to mmap the particular buffer.
In this case locking the buffer can be simplified to increasing the
reference count of the vm_file. We thought that this is a correct way
of locking underlying memory buffers for that vm area. Now we
understand that this worked only for our custom allocator.
Do you know if there is any other way to lock the particular vm area
without locking the whole memory management of the process (vm_mm)?
In other words, we would like to protect the underlying physical
memory from being freed prematurely (without our consent).
[snip]
+ b-paddr= priv-page_pa_first + priv-page_offset;
+ priv-data.file = vma-vm_file;
+ priv-sync = direct_pfn_sync;
+ priv-release = direct_pfn_release;
+ debug(vma = %p, vma-vm_file = %p\n, (void*)vma,
(void*)vma-vm_file);
+
+ if ((pte PTE_CACHEABLE) == 0) {
The big hint here is that there's no L_ prefix. This is buggy. There is
no cacheable bit in a 'pte' anymore - there are memory types, which you
need to mask out and compare instead.
Even if you did have access to the hardware page table entry, the contents
of it is CPU specific, and that's most certainly true of the old 'cacheable'
bit.
Moreover, shared file mappings on VIVT processors can have their cache
Re: uvcvideo causes ehci_hcd to halt
Alan Stern wrote On 13-10-2009 17:53: Can you add a dump_stack() call just after the ehci_err() line in drivers/usb/host/ehci-hcd.c:handshake_on_error_set_halt()? It should provide some clues. At the same time (i.e., during the same test) you should collect a usbmon trace. Alan Stern Hi. First the backtrace: [ 149.510272] uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:0203) [ 149.515017] input: BisonCam, NB Pro as /devices/pci:00/:00:1d.7/usb1/1-5/1-5:1.0/input/input10 [ 149.515588] usbcore: registered new interface driver uvcvideo [ 149.516247] USB Video Class driver (v0.1.0) [ 149.658012] Pid: 1137, comm: hald-probe-vide Tainted: G C 2.6.31.4-128 #2 [ 149.658012] Call Trace: [ 149.658012] [c0373f62] handshake_on_error_set_halt+0x36/0x65 [ 149.658012] [c0374073] enable_periodic+0x32/0x72 [ 149.658012] [c03741c9] qh_link_periodic+0x116/0x11e [ 149.658012] [c0374665] qh_schedule+0x120/0x12c [ 149.658012] [c03775d0] intr_submit+0x8c/0x124 [ 149.658012] [c0377d2a] ehci_urb_enqueue+0x7a/0xa5 [ 149.658012] [c036965f] usb_hcd_submit_urb+0xbb/0x13c [ 149.658012] [c0369b1e] usb_submit_urb+0x1f1/0x20d [ 149.658012] [f854aaff] uvc_status_start+0x18/0x1a [uvcvideo] [ 149.658012] [f8546e23] uvc_v4l2_open+0x8a/0xcf [uvcvideo] [ 149.658012] [f7c3d74a] v4l2_open+0x68/0x7c [videodev] [ 149.658012] [c01c648e] chrdev_open+0x125/0x13c [ 149.658012] [c01c28a9] __dentry_open+0x119/0x207 [ 149.658012] [c01c2a31] nameidata_to_filp+0x2c/0x43 [ 149.658012] [c01c6369] ? chrdev_open+0x0/0x13c [ 149.658012] [c01ccc28] do_filp_open+0x3e5/0x741 [ 149.658012] [c01ccfe9] ? getname+0x20/0xb7 [ 149.658012] [c01d4be8] ? alloc_fd+0x55/0xbe [ 149.658012] [c01c2699] do_sys_open+0x4a/0xe2 [ 149.658012] [c0435527] ? do_page_fault+0x2d6/0x304 [ 149.658012] [c01c2773] sys_open+0x1e/0x26 [ 149.658012] [c0103214] sysenter_do_call+0x12/0x28 [ 149.658012] ehci_hcd :00:1d.7: force halt; handhake f7c66024 4000 - -110 And the usbmon trace during modprobe uvcvideo can be found at: http://cekirdek.pardus.org.tr/~ozan/ivir/logs/usbmon.trace.bad I also manage to not reproduce the problem so it's kinda racy. You can find good/bad dmesg/usbmon traces at: http://cekirdek.pardus.org.tr/~ozan/ivir/logs Thanks, Ozan Caglayan -- 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
Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
Hello, I'm having problems with glitchy reception on a HVR-1600 card using ClearQAM digital cable channels. Unfortunately, I'm remote from the box, so can't describe the visual appearance, but I do have SSH access. Looking at the output of femon -c 100 (attached as femon.txt), I'm seeing the occasional burst of UNC errors. I've attached dmesg as dmesg.txt in case it gives any clues; the v4l drivers are as in kernel 2.6.30 from Linus, with no extra patches. I'm using Xine to decode the channel - my channels.conf line for the channel in question is: WTAE:567012500:QAM_256:0:0:5 Any ideas? -- I can do any further investigation or experiments required, Simon Farnsworth Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.30-1.NTB5.fc8.i686.PAE (sfarnswo...@f8simon.office.onelan.co.uk) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Thu Jul 30 19:28:43 BST 2009 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD NSC Geode by NSC Cyrix CyrixInstead Centaur CentaurHauls Transmeta GenuineTMx86 Transmeta TransmetaCPU UMC UMC UMC UMC BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 3f79 (usable) BIOS-e820: 3f79 - 3f79e000 (ACPI data) BIOS-e820: 3f79e000 - 3f7efa60 (ACPI NVS) BIOS-e820: 3f7efa60 - 3f80 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) DMI present. AMI BIOS detected: BIOS may corrupt low RAM, working around it. e820 update range: - 0001 (usable) == (reserved) last_pfn = 0x3f790 max_arch_pfn = 0x10 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-D uncachable E-E3FFF write-protect E4000-E7FFF write-through E8000-EBFFF write-protect EC000-E write-through F-F write-protect MTRR variable ranges enabled: 0 base 0 mask FC000 write-back 1 base 03F80 mask FFF80 uncachable 2 disabled 3 disabled 4 disabled 5 disabled 6 disabled 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 original variable MTRRs reg 0, base: 0GB, range: 1GB, type WB reg 1, base: 1016MB, range: 8MB, type UC total RAM coverred: 1016M Found optimal setting for mtrr clean up gran_size: 64K chunk_size: 16M num_reg: 2 lose cover RAM: 0G New variable MTRRs reg 0, base: 0GB, range: 1GB, type WB reg 1, base: 1016MB, range: 8MB, type UC x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 init_memory_mapping: -377fe000 Using x86 segment limits to approximate NX protection 00 - 40 page 4k 40 - 003740 page 2M 003740 - 00377fe000 page 4k kernel direct mapping tables up to 377fe000 @ 1-15000 RAMDISK: 37e04000 - 37fef2e9 Allocated new RAMDISK: 0010 - 002eb2e9 Move RAMDISK from 37e04000 - 37fef2e8 to 0010 - 002eb2e8 ACPI: RSDP 000f9120 00014 (v00 ACPIAM) ACPI: RSDT 3f79 00040 (v01 110608 RSDT1528 20081106 MSFT 0097) ACPI: FACP 3f790200 00084 (v02 110608 FACP1528 20081106 MSFT 0097) ACPI: DSDT 3f790430 05DF9 (v01 965GA 965GA013 0013 INTL 20051117) ACPI: FACS 3f79e000 00040 ACPI: APIC 3f790390 0005C (v01 110608 APIC1528 20081106 MSFT 0097) ACPI: MCFG 3f7903f0 0003C (v01 110608 OEMMCFG 20081106 MSFT 0097) ACPI: OEMB 3f79e040 00071 (v01 110608 OEMB1528 20081106 MSFT 0097) ACPI: GSCI 3f79e0c0 02024 (v01 110608 GMCHSCI 20081106 MSFT 0097) ACPI: TCPA 3f796230 00032 (v01 110608 TBLOEMID 0001 MSFT 0097) ACPI: SSDT 3f7a2810 004E6 (v01 PmRefCpuPm 3000 INTL 20051117) ACPI: Local APIC address 0xfee0 127MB HIGHMEM available. 887MB LOWMEM available. mapped low ram: 0 - 377fe000 low ram: 0 - 377fe000 node 0 low ram: - 377fe000 node 0 bootmap 00011000 - 00017f00 (9 early reservations) == bootmem [00 - 00377fe000] #0 [00 - 001000] BIOS data page == [00 - 001000] #1 [001000 - 002000]EX TRAMPOLINE == [001000 - 002000] #2 [006000 - 007000] TRAMPOLINE == [006000 - 007000] #3 [40 - a14008]TEXT DATA BSS == [40 - a14008] #4 [09fc00 - 10]BIOS reserved == [09fc00 - 10] #5 [a15000 - a18193] BRK == [a15000 - a18193] #6 [01 - 011000] PGTABLE == [01 - 011000] #7 [10 - 2eb2e9] NEW RAMDISK == [10 - 2eb2e9] #8 [011000 - 018000] BOOTMAP == [011000 - 018000] found SMP MP-table at [c00ff780] ff780 Zone PFN ranges: DMA 0x0010 - 0x1000 Normal 0x1000 -
Re: [linux-dvb] Linuxtv wiki needs email notification/more email-ready users
Hi, On Tue, Oct 13, 2009 at 12:52:08AM -0400, CityK wrote: Hi Henrik, H. Langos wrote: It would be great if it was possible to get (immediate/daily/weekly?) change notifications by email in order not to lose track of what is happening to the pages that I care about. (I bet this is standard functionality of mediawiki or at least one of the more common extentions.) In searching for something else, I came across this recent thread on the mediawiki m/l: http://lists.wikimedia.org/pipermail/mediawiki-l/2009-October/032214.html There are a few suggestions in it (I just skimmed through). Perhaps one of them would be good to implement. I took a look at those but in doing so I've (re)discovered the automatic rss feed that each page generates. Those rss feeds can be polled by services like feedmyinbox.com to generate a daily report. Our Mediawiki version does not yet have the ability to generate RSS feeds for users' watchlists without them being logged in (I've seen that feature on MW 1.16beta on the iPodlinux.org wiki though), but I am happy enough with the general Recent changes and the individual pages' feeds. Thank you very much for pointing me in the right direction cheers -henrik -- 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: Global Video Buffers Pool - PMM and UPBuffer reference drivers [RFC]
Hello,
[Code modified a bit to shorten it; removed some error reporting;
irrelevant parts of the code removed.]
diff --git a/drivers/s3cmm/pmm-init.c b/drivers/s3cmm/pmm-init.c
new file mode 100644
index 000..f1e31a5
--- /dev/null
+++ b/drivers/s3cmm/pmm-init.c
@@ -0,0 +1,75 @@
+static unsigned long pmm_memory_start, pmm_memory_size;
+
+static int __init pmm_early_param(char *param)
+{
+ unsigned long long size = memparse(param, 0);
+ void *ptr;
+
+ if (size = 0 || size (1ull 30))
+ return -EINVAL;
+
+ pmm_memory_size = PAGE_ALIGN((unsigned long)size);
+ ptr = alloc_bootmem_pages_nopanic(pmm_memory_size);
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
How does this work? When early params are parsed, the memory subsystem
hasn't been initialized - not even bootmem. So this will always fail.
From my investigation into Linux kernel source code it seems as if
bootmem were initialised prior to parsing early params. Lets look at
start_kernel():
#v+
init/main.c:
584setup_arch(command_line);
[...]
595parse_early_param();
[...]
607mm_init();
#v-
On ARM with MMU setup_arch() calls paging_init()
(arch/arm/kernel/setup.c:730) which calls bootmem_init()
(arch/arm/mm/mmu.c:989) which is the function that initialises
bootmem.
Early params are obviously handled by parse_early_param() function
which is invoked after the call to setup_arch().
What is also worth mentioning is that mm_init() initialises standard
allocators so after this function is called bootmem no longer works.
I've also tried to use various *_initcall()s (the ones defined in
include/linux/init.h) but neither of them seemed to work.
+ if (ptr)
+ pmm_memory_start = virt_to_phys(ptr);
+
+ return 0;
+}
+early_param(pmm, pmm_early_param);
+
+
+
+/** Called from pmm_module_init() when module is initialised. */
+void pmm_module_platform_init(pmm_add_region_func add_region)
+{
+ if (pmm_memory_start pmm_memory_size)
+ add_region(pmm_memory_start, pmm_memory_size,
+ PMM_MEM_GENERAL, 0);
+}
+EXPORT_SYMBOL(pmm_module_platform_init);
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał mina86 Nazarewicz (o o)
ooo +---min...@mina86.com---min...@jabber.org---ooO--(_)--Ooo--
--
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: Hauppage WinTV-HVR-900H
Bill Davidsen wrote: The answer was responsive to the question, a couple of links to software which might serve. I would think your going off about it was further off-topic, it certainly didn't help the O.P. any. When someone ends a question with please help I would assume that any answer would be better than we're working on it. Answering an on-topic question with a short list of links is hardly spamming or even advertising, it's called being polite and helpful. I would rather run commercial software on Linux that open source on Windows, thanks, if those are the choices. After several months of looking I have yet to find any video app that a typical office worker can use. Something no more complex than xawtv, which has been running fine on FC4 and FC6 for these folks. I would certainly consider a commercial solution rather than have them go back to the dark side of the force and Windows-7. i've followed the advice of marcus in the past and that is why for over a year i had a completely useless piece of hardware in the end the real developers here sorted the problem out this list is for people who run or want to run the drivers at linuxtv.org so no, i don't think i was off-topic he constantly spams the list here with his closed source commercial solution just about my only job on this list is to counter his bull with kind regards -- simon -- 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: em28xx DVB modeswitching change: call for testers
Hello all, I have setup a tree that removes the mode switching code when starting/stopping streaming. If you have one of the em28xx dvb devices mentioned in the previous thread and volunteered to test, please try out the following tree: http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch In particular, this should work for those of you who reported problems with zl10353 based devices like the Pinnacle 320e (or Dazzle) and were using that one line change I sent this week. It should also work with Antti's Reddo board without needing his patch to move the demod reset into the tuner_gpio. This also brings us one more step forward to setting up the locking properly so that applications cannot simultaneously open the analog and dvb side of the device. Thanks for your help, Devin Hello Devin, I've just downloaded, compiled and installed em28xx-modeswitch. Unfortunately, it doesn't work and doesn't even create /dev/dvb, /dev/videoX, /dev/vbiX. Only /dev/dsp1 is created. The dmesg is attached to this email. As you can see it ends up in errors. One last note, I downloaded from the bz2 link. Cheers. -- *** Giuseppe Borzi, Assistant Professor at the University of Messina - Department of Civil Engineering Address: Contrada di Dio, Messina, I-98166, Italy Tel: +390903977323 Fax: +390903977480 email: gbo...@ieee.org url: http://ww2.unime.it/dic/gborzi/index.php *** usb 1-3.1: new high speed USB device using ehci_hcd and address 8 usb 1-3.1: configuration #1 chosen from 1 choice em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) em28xx #0: chip ID is em2882/em2883 em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 02 00 b8 00 00 00 5b 1e 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 5a 00 55 aa 79 55 54 03 00 17 98 01 00 00 00 00 em28xx #0: i2c eeprom f0: 0c 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb8846b20 em28xx #0: EEPROM info: em28xx #0: AC97 audio (5 sample rates) em28xx #0: USB Remote wakeup capable em28xx #0: 500mA max power em28xx #0: Table at 0x04, strings=0x206a, 0x006a, 0x em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) em28xx #0: Your board has no unique USB ID. em28xx #0: A hint were successfully done, based on eeprom hash. em28xx #0: This method is not 100% failproof. em28xx #0: If the board were missdetected, please email this log to: em28xx #0: V4L Mailing List linux-media@vger.kernel.org em28xx #0: Board detected as Pinnacle Hybrid Pro tvp5150 2-005c: chip found @ 0xb8 (em28xx #0) tuner 2-0061: chip found @ 0xc2 (em28xx #0) general protection fault: [#1] PREEMPT SMP last sysfs file: /sys/module/tuner/initstate CPU 0 Modules linked in: em28xx(+) ir_common videobuf_vmalloc videobuf_core tveeprom iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables cryptd aes_x86_64 aes_generic ipv6 hidp rfcomm sco bridge stp llc bnep l2cap zl10353 snd_usb_audio snd_usb_lib snd_rawmidi usbhid hid tuner_xc2028 tuner snd_seq_dummy tvp5150 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 snd_hda_codec_realtek btusb bluetooth snd_pcm_oss snd_mixer_oss snd_hda_intel arc4 snd_hda_codec snd_hwdep snd_pcm fan snd_timer snd soundcore snd_page_alloc kqemu pcmcia fuse ecb sdhci_pci sdhci mmc_core coretemp iwl3945 iTCO_wdt iTCO_vendor_support iwlcore mac80211 led_class yenta_socket rsrc_nonstatic ohci1394 pcmcia_core cpufreq_powersave ieee1394 cfg80211 rfkill psmouse r8169 mii uhci_hcd i2c_i801 battery thermal button sg ac pcspkr serio_raw ehci_hcd cpufreq_ondemand usbcore evdev acpi_cpufreq freq_table processor rtc_cmos rtc_core rtc_lib ext4 mbcache jbd2 crc16 sr_mod cdrom sd_mod pata_acpi ata_generic ata_piix libata scsi_mod i915 drm i2c_algo_bit i2c_core video
Re: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
On Wed, 2009-10-14 at 09:54 +0100, Simon Farnsworth wrote: Hello, I'm having problems with glitchy reception on a HVR-1600 card using ClearQAM digital cable channels. Unfortunately, I'm remote from the box, so can't describe the visual appearance, but I do have SSH access. Looking at the output of femon -c 100 (attached as femon.txt), I'm seeing the occasional burst of UNC errors. I've attached dmesg as dmesg.txt in case it gives any clues; the v4l drivers are as in kernel 2.6.30 from Linus, with no extra patches. I'm using Xine to decode the channel - my channels.conf line for the channel in question is: WTAE:567012500:QAM_256:0:0:5 Any ideas? Have your remote user read http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality and take any actions that seem appropriate/easy. The in kernel mxl5005s driver is known to have about 3 dB worse performance for QAM vs 8-VSB (Steven Toth took some measurements once). If I had access to the mxl5005s datasheet and any programming manuals, I could probably fix this. However, I do not have them. Though, I have not asked MaxLinear for them either since I don't have cable at my home (yet). Regards, Andy -- 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: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
Andy Walls wrote: Have your remote user read http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality and take any actions that seem appropriate/easy. I'll try that again - they're grouching, because their TV is fine, and the same card in a Windows PC is also fine. It's just under Linux that they're seeing problems, so I may not be able to get them to co-operate. The in kernel mxl5005s driver is known to have about 3 dB worse performance for QAM vs 8-VSB (Steven Toth took some measurements once). Am I misunderstanding dmesg here? I see references to a Samsung S5H1409, not to an mxl5005s; if I've read the driver code correctly, I'd see a KERN_INFO printk for the mxl5005s when it comes up. -- Simon Farnsworth -- 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: Mem2Mem V4L2 devices [RFC]
Hello, On Thursday, October 08, 2009 11:26 PM Karicheri, Muralidharan wrote: Why not? In a typical camera scenario, application can feed one frame and get two output frames (one for storing and another for sending over email (a lower resolution). I just gave an example. You gave an example of the Y-type pipeline which start in real streaming device (camera) which is completely different thing. Y-type CAPTURE pipeline is quite common thing, which can be simply mapped to 2 different capture video nodes. In my previous mail I asked about Y-type pipeline which starts in memory. I don't think there is any common use case for such thing. Marek, You can't say that. This feature is currently supported in our internal release which is being used by our customers. So for feature parity it is required to be supported as we can't determine how many customers are using this feature. Besides in the above scenario that I have mentioned, following happens. sensor - CCDC - Memory (video node) Memory - Previewer - Resizer1 - Memory |- Resizer2 - Memory Typically application capture full resolution frame (Bayer RGB) to Memory and then use Previewer and Resizer in memory to memory mode to do conversion to UYVY format. But application use second resizer to get a lower resolution frame simultaneously. We would like to expose this hardware capability to user application through this memory to memory device. Ok. I understand that Your current custom API exports such functionality. I thought a bit about this issue and found a solution how this can be implemented using one video node approach. It would require additional custom ioctl but imho there is no other way. An application can open the /dev/videoX node 2 times. Then it can 'link' them with this special ioctl, so the driver would know which instances are 'linked' together. Then the application queues source buffer to both instances, sets destination format/size/colorspace/etc, and queues output buffers. Then calls stream on both instances. The driver can detect if the 2 instances has been linked together and if the source buffer is the same in both of them, it will use this special feature of your hardware and run 2 resizers simultaneously. This sounds a bit complicated (especially because the driver would need to play a bit with synchronization and possible races...), but currently I see no other possibility to implement it on top of one-video-node approach. Since only one capture queue per IO instance is possible in this model (matched by buf type), I don't think we can scale it for 2 outputs case. Or is it possible to queue 2 output buffers of two different sizes to the same queue? This can be hacked by introducing yet another 'type' (for example SECOND_CAPTURE), but I don't like such solution. Anyway - would we really need Y-type mem2mem device? Yes. No hacking please! We should be able to do S_FMT for the second Resizer output and dequeue the frame. Not sure how can we handle this in this model. Currently I see no clean way of adding support for more than one output in one video node approach. Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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: Hauppage WinTV-HVR-900H
Devin Heitmueller wrote: On Fri, Oct 9, 2009 at 1:22 PM, Ali Abdallah al...@xfce.org wrote: Screenshots here for TV and S-Video input configuration with TV time. http://ali.blogsite.org/files/tvtime/ Could you try the S-Video or composite input and see if the picture quality is still bad (as this well help isolate whether it's a problem with the tuner chip or the decoder. Same picture quality with S-Video, but with composite there is no picture. Ok, this helps alot. This rules out the tuner and suggests that perhaps the video decoder is not being programmed properly. Could you please send me the output of dmesg? I'll see about setting up a tree with some additional debugging for you to try out. Follow up, i manager to get the hvr 900 instead the 900H, and i got the same result with the analog signal, i tried with my friend's windows system, same result, no analog channels detected, however i got all the channels a hvr pci card, so i expect these USB keys needs really a very strong signal, so there is no problem in the driver, sorry for the noise, hopefully the 900H will get a driver soon. Thanks, Devin Thanks, Ali. -- 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: More about Winfast TV USB Deluxe
Loaded em28xx with i2c_scan and i2c_debug and tvaudio with tda9874a
option and debug.
sudo modprobe -v em28xx i2c_scan=1 i2c_debug=1
sudo modprobe -v tvaudio tda9874a=1 debug=1
And got this ouput:
[91083.588182] em28xx #0: found i2c device @ 0x30 [???]
[91083.590179] em28xx #0: found i2c device @ 0x3e [???]
[91083.590804] em28xx #0: found i2c device @ 0x42 [???]
[91083.600308] em28xx #0: found i2c device @ 0x86 [tda9887]
[91083.603805] em28xx #0: found i2c device @ 0xa0 [eeprom]
[91083.606183] em28xx #0: found i2c device @ 0xb0 [tda9874]
[91083.608808] em28xx #0: found i2c device @ 0xc2 [tuner (analog)]
[91083.617682] em28xx #0: Identified as Leadtek Winfast USB II Deluxe (card=28)
[91083.617684] em28xx #0:
[91083.617684]
[91083.617687] em28xx #0: The support for this board weren't valid yet.
[91083.617688] em28xx #0: Please send a report of having this working
[91083.617690] em28xx #0: not to V4L mailing list (and/or to other addresses)
[91083.617691]
[91083.980702] saa7115 4-0021: saa7114 found (1f7114d0e00) @ 0x42
(em28xx #0)
[91086.173114] tvaudio: TV audio decoder + audio/video mux driver
[91086.173116] tvaudio: known chips: tda9840, tda9873h, tda9874h/a/ah,
tda9875, tda9850, tda9855, tea6300, tea6320, tea6420, tda8425,
pic16c54 (PV951), ta8874z
[91086.173125] tvaudio 4-00b0: chip found @ 0x160
[91086.173127] tvaudio 4-00b0: no matching chip description found
[91086.173131] tvaudio: probe of 4-00b0 failed with error -5
It seems to be a tda9874 there - em28xx #0: found i2c device @ 0xb0 [tda9874]
But does tvaudio stop @ 0x160 (decimal value of 0xa0 rigth? ) and
doesn't look further?
I mean does tvaudio find my boards eeprom, cant talk to it and gives up?
/Magnus
2009/10/13 Magnus Alm magnus@gmail.com:
Hi!
Thanks to Devin's moral support I now have sound in television. ;-)
Thanks!!
I pooked around some more managed to get radio to function with these
settings:
[EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE] = {
.name = Leadtek Winfast USB II Deluxe,
.valid = EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
.tda9887_conf = TDA9887_PRESENT |
TDA9887_PORT1_ACTIVE,
.decoder = EM28XX_SAA711X,
.input = { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = SAA7115_COMPOSITE4,
.amux = EM28XX_AMUX_AUX,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = SAA7115_COMPOSITE5,
.amux = EM28XX_AMUX_LINE_IN,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = SAA7115_SVIDEO3,
.amux = EM28XX_AMUX_LINE_IN,
} },
.radio = {
.type = EM28XX_RADIO,
.amux = EM28XX_AMUX_AUX,
}
},
I tested with different settings on tda9887 and modprobe tda9887
port1=1 seemed to work be best.
One odd thing when the modules is load is this:
[15680.459343] tuner 4-: chip found @ 0x0 (em28xx #0)
[15680.473017] tuner 4-0043: chip found @ 0x86 (em28xx #0)
[15680.473089] tda9887 4-0043: creating new instance
[15680.473091] tda9887 4-0043: tda988[5/6/7] found
[15680.485719] tuner 4-0061: chip found @ 0xc2 (em28xx #0)
[15680.486169] tuner-simple 4-: unable to probe Alps TSBE1,
proceeding anyway. -- What is that?
[15680.486171] tuner-simple 4-: creating new instance
--
[15680.486174] tuner-simple 4-: type set to 10 (Alps TSBE1)
--
[15680.496562] tuner-simple 4-0061: creating new instance
[15680.496566] tuner-simple 4-0061: type set to 38 (Philips PAL/SECAM
multi (FM1216ME MK3))
Another question, my box has a tda9874ah chip and if understand the
data sheet it gives support for stereo (even Nicam if that is still
used anymore.).
So I tried to configure my box the same way as
[EM2820_BOARD_COMPRO_VIDEOMATE_FORYOU] by adding these lines:
.tvaudio_addr = 0xb0, address of
tda9874 according to ic2-addr.h
.adecoder = EM28XX_TVAUDIO,
But it didnt work, got the following message when I plugged it in:
[15677.928972] em28xx #0: Please send a report of having this working
[15677.928974] em28xx #0: not to V4L mailing list (and/or to other addresses)
[15677.928975]
[15678.288360] saa7115 4-0021: saa7114 found (1f7114d0e00) @ 0x42
(em28xx #0)
[15680.457094] tvaudio: TV audio decoder + audio/video mux driver
[15680.457097] tvaudio: known chips: tda9840, tda9873h, tda9874h/a/ah,
tda9875, tda9850, tda9855, tea6300, tea6320, tea6420, tda8425,
pic16c54 (PV951), ta8874z
Re: Hauppage WinTV-HVR-900H
On Wed, Oct 14, 2009 at 11:48 AM, Simon Kenyon si...@koala.ie wrote: Bill Davidsen wrote: The answer was responsive to the question, a couple of links to software which might serve. I would think your going off about it was further off-topic, it certainly didn't help the O.P. any. When someone ends a question with please help I would assume that any answer would be better than we're working on it. Answering an on-topic question with a short list of links is hardly spamming or even advertising, it's called being polite and helpful. I would rather run commercial software on Linux that open source on Windows, thanks, if those are the choices. After several months of looking I have yet to find any video app that a typical office worker can use. Something no more complex than xawtv, which has been running fine on FC4 and FC6 for these folks. I would certainly consider a commercial solution rather than have them go back to the dark side of the force and Windows-7. i've followed the advice of marcus in the past and that is why for over a year i had a completely useless piece of hardware in the end the real developers here sorted the problem out this list is for people who run or want to run the drivers at linuxtv.org so no, i don't think i was off-topic he constantly spams the list here with his closed source commercial solution just about my only job on this list is to counter his bull I have followed this one too for a longer time too. In general it seems like that people were just fighting the existing and working solution from Marcus. I'm actually glad that someone is standing up and trying to make everything easier now. It would be more helpful if you could add some helpful information how to get the devices work, rather than complaining about someone (especially on personal level as it seems) who supposingly brought up a competitive solution. The only issue I see is that this announced work is not opensource, but I'd also rather leave that one open to the enduser instead of generally fighting against it.. Some people here have an aggressiv potential it seems. just my 2 cents, James -- 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
[RFC] Video events, version 2
Hi,
Here's the second version of the video events RFC. It's based on Laurent
Pinchart's original RFC. My aim is to address the issues found in the
old RFC during the V4L-DVB mini-summit in the Linux plumbers conference
2009. To get a good grasp of the problem at hand it's probably a good
idea read the original RFC as well:
URL:http://www.spinics.net/lists/linux-media/msg10217.html
Changes to version 1
--
struct video_event has been renamed to v4l2_event. The struct is used in
userspace and V4L related structures appear to have v4l2 prefix so that
should be better than video.
The entity field has been removed from the struct v4l2_event since the
subdevices will have their own device nodes --- the events should come
from them instead of the media controller. Video nodes could be used for
events, too.
A few reserved fields have been added. There are new ioctls as well for
enumeration and (un)subscribing.
Interface description
-
Event type is either a standard event or private event. Standard events
will be defined in videodev2.h. Private event types begin from
V4L2_EVENT_PRIVATE. Some high order bits could be reserved for future use.
#define V4L2_EVENT_PRIVATE_START0x0800
#define V4L2_EVENT_RESERVED 0x1000
VIDIOC_ENUM_EVENT is used to enumerate the available event types. It
works a bit the same way than VIDIOC_ENUM_FMT i.e. you get the next
event type by calling it with the last type in the type field. The
difference is that the range is not continuous like in querying controls.
VIDIOC_G_EVENT is used to get events. sequence is the event sequence
number and the data is specific to driver or event type.
The user will get the information that there's an event through
exception file descriptors by using select(2). When an event is
available the poll handler sets POLLPRI which wakes up select. -EINVAL
will be returned if there are no pending events.
VIDIOC_SUBSCRIBE_EVENT and VIDIOC_UNSUBSCRIBE_EVENT are used to
subscribe and unsubscribe from events. The argument is event type.
struct v4l2_eventdesc {
__u32 type;
__u8description[64];
__u32 reserved[4];
};
struct v4l2_event {
__u32 type;
__u32 sequence;
struct timeval timestamp;
__u8data[64];
__u32 reserved[4];
};
#define VIDIOC_ENUM_EVENT _IORW('V', 83, struct v4l2_eventdesc)
#define VIDIOC_G_EVENT _IOR('V', 84, struct v4l2_event)
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 85, __u32)
#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 86, __u32)
As it was discussed in the LPC, event subscriptions should be bound to
file handle. The implementation, however, is not visible to userspace.
This is why I'm not specifying it in this RFC.
While the number of possible standard (and probably private) events
would be quite small and the implementation could be a bit field, I do
see that the interface must be using types passed as numbers instead of
bit fields.
Is it necessary to buffer events of same type or will an event replace
an older event of the same type? It probably depends on event type which
is better. This is also a matter of implementation.
Comments and questions are more than welcome.
Cheers,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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: em28xx DVB modeswitching change: call for testers
On Wed, Oct 14, 2009 at 6:25 AM, Giuseppe Borzi gbo...@gmail.com wrote: Hello all, I have setup a tree that removes the mode switching code when starting/stopping streaming. If you have one of the em28xx dvb devices mentioned in the previous thread and volunteered to test, please try out the following tree: http://kernellabs.com/hg/~dheitmueller/em28xx-modeswitch In particular, this should work for those of you who reported problems with zl10353 based devices like the Pinnacle 320e (or Dazzle) and were using that one line change I sent this week. It should also work with Antti's Reddo board without needing his patch to move the demod reset into the tuner_gpio. This also brings us one more step forward to setting up the locking properly so that applications cannot simultaneously open the analog and dvb side of the device. Thanks for your help, Devin Hello Devin, I've just downloaded, compiled and installed em28xx-modeswitch. Unfortunately, it doesn't work and doesn't even create /dev/dvb, /dev/videoX, /dev/vbiX. Only /dev/dsp1 is created. The dmesg is attached to this email. As you can see it ends up in errors. One last note, I downloaded from the bz2 link. Cheers. Did you run make unload before you plugged in the device? Do me a favor - unplug the device, reboot the PC, plug it back in and see if it still happens. I just want to be sure this isn't some sort of issue with conflict between the new and old modules before I debug this any further. 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: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
On Wed, Oct 14, 2009 at 7:01 AM, Simon Farnsworth simon.farnswo...@onelan.com wrote: Andy Walls wrote: Have your remote user read http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality and take any actions that seem appropriate/easy. I'll try that again - they're grouching, because their TV is fine, and the same card in a Windows PC is also fine. It's just under Linux that they're seeing problems, so I may not be able to get them to co-operate. The in kernel mxl5005s driver is known to have about 3 dB worse performance for QAM vs 8-VSB (Steven Toth took some measurements once). Am I misunderstanding dmesg here? I see references to a Samsung S5H1409, not to an mxl5005s; if I've read the driver code correctly, I'd see a KERN_INFO printk for the mxl5005s when it comes up. Simon, the HVR-1600 has both an s5h1409 and an mxl5005s - the s5h1409 is the digital demodulator and the mxl5005s is the tuner chip. 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
Looking for libv4l documentation!
Hi, I been searching for a tutorial or a documentation for libv4l to convert the pixelformat supported by my webcan but I can´t find any. I found a article saying that I only should open my device using v4l_open(/dev/video0) instead of open(/dev/video0) and the lib should do the conversion, but it sound a bit odd for me since I believe it should need a more sofisticated threatment. Does anyone could point to me any reference to such a documentation?? Great regards! Guilherme Longo -- 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
Request driver for cards
Hi, what is the procedure to request drivers for specific new, perhaps unknown supported cards? I did have a look at http://www.linuxtv.org/wiki/index.php/Main_Page but it didn't contain any information about supported cards. Neither did 2.6.30 /usr/src/linux/Documentation/dvb/cards.txt for the following brands: name, site: Compro, S300 http://www.comprousa.com/en/product/s300/s300.html K-World VS-DVB-S 100/IS, http://global.kworld-global.com/main/prod_in.aspx?mnuid=1248modid=6pcid=46ifid=16prodid=98 Perhaps I shouldn't waste time if I could find a dual/twin tuner card for dvb-s or dvb-s2. Are there any recommended twin-tuner pci-e cards that is support and can actually be bought by the average consumer? Thanks -- 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: Looking for libv4l documentation!
Just a little observation, I am looking for this library because my webcan has a sn9c10x chipset and I can´t find how sn9c10x pixelformat is captured. There are a huge list of pixelformats in v4l2 spec but there is just a reserved word for this format. They say it exist but I can´t find how it is captured. If someone could tell me where to find such documentation, plz, it would be better than converting the pixelformat. Great Regards Guilherme Longo Guilherme Longo escreveu: Hi, I been searching for a tutorial or a documentation for libv4l to convert the pixelformat supported by my webcan but I can´t find any. I found a article saying that I only should open my device using v4l_open(/dev/video0) instead of open(/dev/video0) and the lib should do the conversion, but it sound a bit odd for me since I believe it should need a more sofisticated threatment. Does anyone could point to me any reference to such a documentation?? Great regards! Guilherme Longo -- 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: Hauppage WinTV-HVR-900H
Mauro Carvalho Chehab wrote: have it implemented). This is the case of xc3028, so you'll need to turn off signal detection while tuning, and be sure that you're loading the proper frequency table used on your Country. It should be noticed that several tuner drivers don't have signal detection (or not This is what i'm doing actually, i have signal detection disabled in tvtime+of course the proper frequency for my country, but still i get channels with very bad pictures (not watchable) with my USB sticks, but i get all the channels with a very good pictures with my PCI card (with signal detection enabled), and using the same analog cable+same setup+same kernel version. Cheers, Mauro Cheers, Ali. -- 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: Haupp. HVR-1100 problem and DVB-T card
- Messaggio originale - Da: hermann pitton hermann-pit...@arcor.de A: fabio tirapelle ftirape...@yahoo.it I have installed mythtv on this configuration: Asus M3N78-VM GF8200 RGVSM AMD Ath64 X2LV 3100BOX6000+ 1MB Haupp. WinTV HVR-1100 -t/a PCI TechniSat SkyStar 2 DVB-S PCI nVidia GeForce 8200 Ubuntu 8.10 - Linux htpc 2.6.27-11-generic I would try to test the HVR1110 next on another PC with known working PCI hardware, also above different operating systems if possible. Hi Hermann! Thank you for your quick response. I tested the card on a M2N-VM DH and it works. So my best guess is that the card does not work on my actual motherboard. We know that the HVR1110s are properly detected on almost all hardware. Before thinking about replacing mobo/PSU, make sure the card is OK. Do you have a suggestion for a new mobo that you know is working (if I can keep my other hardware that would be great)? Thank you very mutch for your time, Fabio -- 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: em28xx DVB modeswitching change: call for testers
Did you run make unload before you plugged in the device? Do me a favor - unplug the device, reboot the PC, plug it back in and see if it still happens. I just want to be sure this isn't some sort of issue with conflict between the new and old modules before I debug this any further. Thanks, Devin Hello Devin, I did as you suggested. Unplugged the stick reboot and plug it again. And just to be sure I did it two times. Now the device works, but it is unable to change channel. That is to say, when I use the command vlc channels.conf it tunes to the first station in the channel file and can't change it. Other apps (xine, kaffeine) that seems to change to the latest channel don't work at all. The dmesg output after plugging the driver is in attach. In dmesg I noticed lines like this [drm] TV-14: set mode NTSC 480i 0 I suppose this hasn't anything to do with the analog audio problem, but just to be sure I ask you. Also, using arecord/aplay for analog audio I get an underrun error message arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay - Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000 Hz, Stereo Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000 Hz, Stereo underrun!!! (at least -1255527098942.108 ms long) Cheers. -- *** Giuseppe Borzi, Assistant Professor at the University of Messina - Department of Civil Engineering Address: Contrada di Dio, Messina, I-98166, Italy Tel: +390903977323 Fax: +390903977480 email: gbo...@ieee.org url: http://ww2.unime.it/dic/gborzi/index.php *** usb 1-3.1: new high speed USB device using ehci_hcd and address 7 usb 1-3.1: configuration #1 chosen from 1 choice Linux video capture interface: v2.00 em28xx: New device USB 2881 Video @ 480 Mbps (eb1a:2881, interface 0, class 0) em28xx #0: chip ID is em2882/em2883 em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 00 6a 20 6a 00 em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 02 00 b8 00 00 00 5b 1e 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 02 00 00 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 5a 00 55 aa 79 55 54 03 00 17 98 01 00 00 00 00 em28xx #0: i2c eeprom f0: 0c 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb8846b20 em28xx #0: EEPROM info: em28xx #0: AC97 audio (5 sample rates) em28xx #0: USB Remote wakeup capable em28xx #0: 500mA max power em28xx #0: Table at 0x04, strings=0x206a, 0x006a, 0x em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) em28xx #0: Your board has no unique USB ID. em28xx #0: A hint were successfully done, based on eeprom hash. em28xx #0: This method is not 100% failproof. em28xx #0: If the board were missdetected, please email this log to: em28xx #0: V4L Mailing List linux-media@vger.kernel.org em28xx #0: Board detected as Pinnacle Hybrid Pro tvp5150 2-005c: chip found @ 0xb8 (em28xx #0) tuner 2-0061: chip found @ 0xc2 (em28xx #0) xc2028 2-0061: creating new instance xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner usb 1-3.1: firmware: requesting xc3028-v27.fw xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 2-0061: Loading firmware for type=BASE (1), id . xc2028 2-0061: Loading firmware for type=(0), id b700. SCODE (2000), id b700: xc2028 2-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. em28xx #0: Config register raw data: 0x58 em28xx #0: AC97 vendor ID = 0x em28xx #0: AC97 features = 0x6a90 em28xx #0: Empia 202 AC97 audio processor detected tvp5150 2-005c: tvp5150am1 detected. em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 video device registered as /dev/video0 em28xx #0: V4L2 VBI device registered as /dev/vbi0 em28xx audio device (eb1a:2881): interface 1, class 1 em28xx audio device (eb1a:2881): interface 2, class 1 usbcore: registered new interface driver em28xx em28xx driver loaded usbcore: registered new interface driver snd-usb-audio tvp5150 2-005c:
Re: em28xx DVB modeswitching change: call for testers
On Wed, Oct 14, 2009 at 10:06 AM, Giuseppe Borzi gbo...@gmail.com wrote: Hello Devin, I did as you suggested. Unplugged the stick reboot and plug it again. And just to be sure I did it two times. Now the device works, but it is unable to change channel. That is to say, when I use the command vlc channels.conf it tunes to the first station in the channel file and can't change it. Other apps (xine, kaffeine) that seems to change to the latest channel don't work at all. The dmesg output after plugging the driver is in attach. In dmesg I noticed lines like this [drm] TV-14: set mode NTSC 480i 0 I suppose this hasn't anything to do with the analog audio problem, but just to be sure I ask you. Also, using arecord/aplay for analog audio I get an underrun error message arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay - Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000 Hz, Stereo Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000 Hz, Stereo underrun!!! (at least -1255527098942.108 ms long) Cheers. Ok, let me look at the code and see what I can figure out. 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: em28xx DVB modeswitching change: call for testers
Em Wed, 14 Oct 2009 10:11:48 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Wed, Oct 14, 2009 at 10:06 AM, Giuseppe Borzi gbo...@gmail.com wrote: Hello Devin, I did as you suggested. Unplugged the stick reboot and plug it again. And just to be sure I did it two times. Now the device works, but it is unable to change channel. That is to say, when I use the command vlc channels.conf it tunes to the first station in the channel file and can't change it. Other apps (xine, kaffeine) that seems to change to the latest channel don't work at all. The dmesg output after plugging the driver is in attach. In dmesg I noticed lines like this [drm] TV-14: set mode NTSC 480i 0 I suppose this hasn't anything to do with the analog audio problem, but just to be sure I ask you. Also, using arecord/aplay for analog audio I get an underrun error message arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay - Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000 Hz, Stereo Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000 Hz, Stereo underrun!!! (at least -1255527098942.108 ms long) Cheers. Ok, let me look at the code and see what I can figure out. Devin, You can't simply remove the DVB gpio setup there. It is used when you change from analog/digital, when you restore from hibernation and to turn on the demod on hybrid devices, and to turn it off after stopping DVB. If you're having troubles there, then probably the DVB demod poweron/reset gpio sequence is wrong or incomplete. Devin Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx DVB modeswitching change: call for testers
On Wed, Oct 14, 2009 at 10:30 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Devin, You can't simply remove the DVB gpio setup there. It is used when you change from analog/digital, when you restore from hibernation and to turn on the demod on hybrid devices, and to turn it off after stopping DVB. If you're having troubles there, then probably the DVB demod poweron/reset gpio sequence is wrong or incomplete. The em28xx_dvb_bus_ctrl() callback should already be putting it into digital mode when the frontend gets opened. The point behind the change is that we should not be switching in and out of dvb mode whenever somebody starts/stops streaming. It should be controlled based on opening closing the frontend (which is what the ts_bus_ctrl callback should accomplish). We ran into the issue because the dvb gpio for the board in question actually strobes the reset rather than just taking it out of reset. While I could change the dvb_gpio to match some of the other boards, we really *should* be strobing the reset after powering up the chip. If we're really relying on the calls in the start_feed() callback when coming out of hibernation, then the code is broken in that case as well, since there is no guarantee the demod is properly re-initialized. 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
libv4l does not work!
Do we need include any other header file than libv4l2.h libv4lconvert.h to get libv4l working? I read Hans saying that: Just replace open(dev/video0, ...) with v4l2_open(dev/video0, ...), ioctl with v4l2_ioctl, etc. libv4l2 will then do conversion of any known (webcam) pixelformats to bgr24 or yuv420. But I am getting undefined reference to 'v4l2_open' and 'v4l2_ioctl'. Can I get some help? regards! Guilherme Longo -- 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] Status of v4l repositories / merging new one
Em Mon, 12 Oct 2009 22:20:23 +0200 Helmut Auer v...@helmutauer.de escreveu: Hello List AFAIK there are different v4l repositories supporting differnet hardware, e.g v4l-dvb(missing skystar HD), liplianin (missing knc1) etc. To add another one, we have a repository supporting the pci-e dual dvb-s low pointer profile mediapointer card :) But for my distribution I'd like to have one repository, supporting all cards Whats to do to get all these repositories merged ? Are there any plans about doing that ? The base development tree is v4l-dvb. It is up to the driver authors to submit me pull requests for their work, in order to have their drivers merged. They do it when they feel comfortable that the driver is ready for submission. With the creation of drivers/staging, a few weeks ago, even drivers that are not yet mature enough for their usage can be added. So, all that is currently needed is the driver author interests for having their work merged. PS.: please post at linux-me...@vger.kernel.org. The linux-dvb ML is obsolete and will be discontinued soon. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dib3000mb dvb-t with kernel 2.6.32-rc3 do not work
Hi Patrick, I tried linux-2.6.31.4 and tuning still does not work. $ tzap $sender -r status 00 | signal | snr | ber 001f | unc | status 04 | signal | snr | ber 001f | unc | status 04 | signal | snr | ber 001f | unc | status 04 | signal 00b2 | snr | ber 001f | unc | status 04 | signal | snr | ber 001f | unc | status 04 | signal | snr | ber 001f | unc | Did you read my other email? The problem must in this file : /usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c line 136 to line 146 i am not familar with the v4l-dvb-hg-repository. I do not know, which patch exactly causes the problem. Greetings Mario Am Mon, 5 Oct 2009 15:50:13 +0200 (CEST) schrieb Patrick Boettcher pboettc...@kernellabs.com: Hi Mario, On Mon, 5 Oct 2009, Mario Bachmann wrote: with kernel 2.6.30.8 my TwinhanDTV USB-Ter USB1.1 / Magic Box I worked. Now with kernel 2.6.32-rc3 (and 2.6.31.1) the modules seems to be loaded fine, but tzap/kaffeine/mplayer can not tune to a channel: dmesg says: dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 16). DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device) DVB: registering adapter 0 frontend 0 (DiBcom 3000M-B DVB-T)... dibusb: This device has the Thomson Cable onboard. Which is default. input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:04.0/usb4/4-2/input/input5 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dibusb_mb [..] and so on. The signal-values are zero or near zero, but when i boot the old kernel 2.6.30.8, t can tune without problems. In a personal email to me you are saying that the differences between dibusb-common.c in 2.6.30.8 and 2.6.32-rc3 are the main cause for the problem. Is it possible for you find out which exact change is causing the trouble? With the v4l-dvb-hg-repository it is possible to get each intemediate version of this file. Afaics, there is only 3 modifications for the timeframe we are talking about. best regards, -- Patrick Boettcher - 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: Hauppage WinTV-HVR-900H
James Peters wrote: I have followed this one too for a longer time too. In general it seems like that people were just fighting the existing and working solution from Marcus. I'm actually glad that someone is standing up and trying to make everything easier now. It would be more helpful if you could add some helpful information how to get the devices work, rather than complaining about someone (especially on personal level as it seems) who supposingly brought up a competitive solution. The only issue I see is that this announced work is not opensource, but I'd also rather leave that one open to the enduser instead of generally fighting against it.. Some people here have an aggressiv potential it seems. the OP wants analog to work on this device developers (certainly in the USA) have no incentive to work on that as they have gone digital i personally cannot help with that device as for Marcus's stuff not being open source - well then what has it got to do with this mailing list? anyway, it used to be open source - but he went off in a sulk because people would not do things the one true way as he saw it perhaps if you were to reread some of the old email threads you would realise that you have not quite grasped the whole situation -- simon -- 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://linuxtv.org/hg/~awalls/cx23888-ir-part2
Em Sun, 11 Oct 2009 08:21:24 -0400 Andy Walls awa...@radix.net escreveu: On Sun, 2009-10-11 at 07:37 -0300, Mauro Carvalho Chehab wrote: Em Sun, 27 Sep 2009 20:12:12 -0400 Andy Walls awa...@radix.net escreveu: Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part2 for the following 5 changesets: 01/05: v4l2-subdev: Add v4l2_subdev_ir_ops and IR notify defines for v4l2_device http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=8cbb951bbb9f 02/05: cx23885: Complete CX23888 IR subdev implementation for Rx almost for Tx http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=a2d8d3d88c6d Andy, there are some coding style issues here, not properly reported by the current checkpatch.pl version we had at the tree, nor by the newer version. I've opened a separate thread at LKML about that. For example, it didn't got any CodingStyle troubles on the formulas like: + if (d RXCLK_RCD+1) +CX23888_IR_REFCLK_FREQ/100); + if (rem = CX23888_IR_REFCLK_FREQ/100/2) + clocks = CX23888_IR_REFCLK_FREQ/100 * (u64) ns; /* millicycles */ + return DIV_ROUND_CLOSEST((n+1) * 100, 16); As there are no related changes on Documentation/CodingStyle, changing or relaxing whitespacing rules, it is better to wait for the checkpatch.pl Maintainer (also called Andy ;) ) for him to check what's going wrong and hopefully provide a fix for the regression. I'm afraid that more relevant codingstyle checks like the usage of deprecated functions could eventually be broken. So, better to wait for his answer, before proceed with patch merging. OK. I'm going to use alot of this code as is in the cx25840 module, it makes sense to get this version cleaned up first. cx23885: Complete CX23888 IR subdev implementation for Rx almost for Tx There are some bad whitespacing here violating CodingStyle that checkpatch.pl didn't get. Please submit a latter patch fixing it. I suspect it is a checkpatch.pl regression, but it seems that we won't have a fix for it soon. I do have a concern that this set of changes may need revision if the cx23885 module or ir-common.h or ir-functions.c change significantly. However you have positive control over those. Yes. I don't think we should have significant changes at rc5 decode routine. The better would be to add there also the pulse-distance and nec decoding code to ir-functions (implemented on some drivers), to have there all common IR code. My other concern is kfifo being changed, requiring rework of my second set of changes. There were some patches on the LKML for fixing kfifo with some positive discussions. Last I checked, nothing had moved forward on kfifo. The current kfifo implementation, IMO, need a few changes for it to be widely used. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
On Wed, Oct 14, 2009 at 5:42 PM, Simon Kenyon si...@koala.ie wrote: James Peters wrote: I have followed this one too for a longer time too. In general it seems like that people were just fighting the existing and working solution from Marcus. I'm actually glad that someone is standing up and trying to make everything easier now. It would be more helpful if you could add some helpful information how to get the devices work, rather than complaining about someone (especially on personal level as it seems) who supposingly brought up a competitive solution. The only issue I see is that this announced work is not opensource, but I'd also rather leave that one open to the enduser instead of generally fighting against it.. Some people here have an aggressiv potential it seems. the OP wants analog to work on this device developers (certainly in the USA) have no incentive to work on that as they have gone digital i personally cannot help with that device as for Marcus's stuff not being open source - well then what has it got to do with this mailing list? anyway, it used to be open source - but he went off in a sulk because people would not do things the one true way as he saw it perhaps if you were to reread some of the old email threads you would realise that you have not quite grasped the whole situation That's your opinion, I do appreciate every mail which is about linux and TV here commercial and non commercial. I'm not interested in reading about flamewars or personal attacks. James -- 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: libv4l does not work!
On Wed, 14 Oct 2009 12:02:43 -0300 Guilherme Longo grlongo.irel...@gmail.com wrote: Do we need include any other header file than libv4l2.h libv4lconvert.h to get libv4l working? I read Hans saying that: Just replace open(dev/video0, ...) with v4l2_open (dev/video0, ...), ioctl with v4l2_ioctl, etc. libv4l2 will then do conversion of any known (webcam) pixelformats to bgr24 or yuv420. But I am getting undefined reference to 'v4l2_open' and 'v4l2_ioctl'. Can I get some help? You must also link your program with necessary libraries, for example gcc code.c -lv4l2 -- Onur Küçük Knowledge speaks, onur.--.-.delipenguen.net but wisdom listens -- 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
(V4L2_PIX_FMT_SBGGR8) wierd behavior trying to get image from buffer!
You guys with more experience could tell me why this strange behavior with my app. First of all, I built my app from a code well known in the Video For Linux spec. It is a capture example. 1º - Why is this /* Buggy driver paranoia. */? min = fmt.fmt.pix.width * 2; if (fmt.fmt.pix.bytesperline min) fmt.fmt.pix.bytesperline = min; min = fmt.fmt.pix.bytesperline * fmt.fmt.pix.height; if (fmt.fmt.pix.sizeimage min) fmt.fmt.pix.sizeimage = min; 2º - I am using libv4l, and using the V4L2_PIX_FMT_SBGGR8 pixelformat in order to get 640x480 of resolution. Otherwise I get only 160x120! This is where the problem lies, I can´t get a good image, I am actually getting no more than fuzzy image. So I presumed that I am geting smth else from the buffer instead of the data I should get. I started checking the parameters and plz, have a look at this wierd response: fmt.fmt.pix.width:640 - Fine fmt.fmt.pix.height: 480 - Fine fmt.fmt.pix.bytesperline: 1920 - How comes ? It is 3 times more, in the SBGGR8 pixelformat each pixel is 1 byte! fmt.fmt.pix.sizeimage:921600 - The image is (fmt.fmt.pix.bytesperline * fmt.fmt.pix.height) I believe that this sizeimage should be set to 307200, representing 640 * 480. Is there someone familiar with this problem and how to solve it?? Great regards. Guilherme Longo -- 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] Video events, version 2
On Wednesday 14 October 2009 15:02:14 Sakari Ailus wrote:
Hi,
Here's the second version of the video events RFC. It's based on Laurent
Pinchart's original RFC. My aim is to address the issues found in the
old RFC during the V4L-DVB mini-summit in the Linux plumbers conference
2009. To get a good grasp of the problem at hand it's probably a good
idea read the original RFC as well:
URL:http://www.spinics.net/lists/linux-media/msg10217.html
Changes to version 1
--
struct video_event has been renamed to v4l2_event. The struct is used in
userspace and V4L related structures appear to have v4l2 prefix so that
should be better than video.
The entity field has been removed from the struct v4l2_event since the
subdevices will have their own device nodes --- the events should come
from them instead of the media controller. Video nodes could be used for
events, too.
A few reserved fields have been added. There are new ioctls as well for
enumeration and (un)subscribing.
Interface description
-
Event type is either a standard event or private event. Standard events
will be defined in videodev2.h. Private event types begin from
V4L2_EVENT_PRIVATE. Some high order bits could be reserved for future use.
#define V4L2_EVENT_PRIVATE_START 0x0800
#define V4L2_EVENT_RESERVED 0x1000
Suggestion: use the V4L2_EV_ prefix perhaps instead of the longer V4L2_EVENT?
VIDIOC_ENUM_EVENT is used to enumerate the available event types. It
works a bit the same way than VIDIOC_ENUM_FMT i.e. you get the next
event type by calling it with the last type in the type field. The
difference is that the range is not continuous like in querying controls.
Question: why do we need an ENUM_EVENT? I don't really see a use-case for this.
Also note that there are three methods in use for enumerating within V4L:
1) there is an index field in the struct that starts at 0 and that the
application increases by 1 until the ioctl returns an error.
2) old-style controls where just enumerated from CID_BASE to CID_LASTP1,
which is very, very ugly.
3) controls new-style allow one to set bit 31 on the control ID and in that
case the ioctl will give you the first control with an ID that is higher than
the specified ID.
1 or 3 are both valid options IMHO.
But again, I don't see why we need it in the first place.
VIDIOC_G_EVENT is used to get events. sequence is the event sequence
number and the data is specific to driver or event type.
The user will get the information that there's an event through
exception file descriptors by using select(2). When an event is
available the poll handler sets POLLPRI which wakes up select. -EINVAL
will be returned if there are no pending events.
VIDIOC_SUBSCRIBE_EVENT and VIDIOC_UNSUBSCRIBE_EVENT are used to
subscribe and unsubscribe from events. The argument is event type.
Two event types can be defined already (used by ivtv):
#define V4L2_EVENT_DECODER_STOPPED 1
#define V4L2_EVENT_OUTPUT_VSYNC 2
struct v4l2_eventdesc {
__u32 type;
__u8description[64];
__u32 reserved[4];
};
struct v4l2_event {
__u32 type;
__u32 sequence;
struct timeval timestamp;
__u8data[64];
This should be a union:
union {
enum v4l2_field ev_output_vsync;
__u8 data[64];
};
__u32 reserved[4];
};
#define VIDIOC_ENUM_EVENT _IORW('V', 83, struct v4l2_eventdesc)
#define VIDIOC_G_EVENT_IOR('V', 84, struct v4l2_event)
#define VIDIOC_SUBSCRIBE_EVENT_IOW('V', 85, __u32)
#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 86, __u32)
For (un)subscribe I suggest that we also use a struct with the event type
and a few reserved fields.
As it was discussed in the LPC, event subscriptions should be bound to
file handle. The implementation, however, is not visible to userspace.
This is why I'm not specifying it in this RFC.
While the number of possible standard (and probably private) events
would be quite small and the implementation could be a bit field, I do
see that the interface must be using types passed as numbers instead of
bit fields.
Is it necessary to buffer events of same type or will an event replace
an older event of the same type? It probably depends on event type which
is better. This is also a matter of implementation.
Comments and questions are more than welcome.
Here's a mixed bag of idea/comments:
We need to define what to do when you unsubscribe an event and there are still
events of that type pending. Do we remove those pending events as well?
I think we should just keep them, but I'm open for other opinions.
I was wondering if a 'count' field in v4l2_event might be useful: e.g. if you
get multiple identical events, and that event is already registered, then you
can
[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:Wed Oct 14 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13101:3919b17dc88e gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc3-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.32-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppage WinTV-HVR-900H
Simon Kenyon wrote: James Peters wrote: I have followed this one too for a longer time too. In general it seems like that people were just fighting the existing and working solution from Marcus. I'm actually glad that someone is standing up and trying to make everything easier now. It would be more helpful if you could add some helpful information how to get the devices work, rather than complaining about someone (especially on personal level as it seems) who supposingly brought up a competitive solution. The only issue I see is that this announced work is not opensource, but I'd also rather leave that one open to the enduser instead of generally fighting against it.. Some people here have an aggressiv potential it seems. the OP wants analog to work on this device developers (certainly in the USA) have no incentive to work on that as they have gone digital i personally cannot help with that device The problem lies in the easy to use applications and UI being married to analog. The Linux digital applications are build it yourself like ham radio, while the Windows applications are like CB, plug and works. I have been trying for months to find any solution for a group of office workers who are trying to move off Fedora FC4 and FC6 (tvtime and mostly xawtv) and old Windows to new desktop, preferably FC11. I support their Linux servers, I am helping find a desktop solution because I believe in Linux (ie. I'm donating my time and the price of cards I bought for testing). Their install support guy will plug cards in the box, or USB adaptors, and install an RPM. He won't install a bunch of RPMs, configure a database, and play dba to get mythtv working. The users understand selecting transport like digital-cable-us, analog-braodcast-us, S-video, and channels. They are not going to look up frequencies, build channel tables, of type transponder frequencies in kHz into vlc and similar. So if I could find a commercial solution for them, which they could install and run with minimal problem, I'd be happy. I like open source, I have supported open source back to stuff I wrote on MULTICS, but sometimes working now solutions are needed, not help with development. And putting a bunch of partial solutions together is fine for Lego or Erector sets, not so much for office working wanting to install and use an intuitive solution. as for Marcus's stuff not being open source - well then what has it got to do with this mailing list? anyway, it used to be open source - but he went off in a sulk because people would not do things the one true way as he saw it Is this list to promote video on Linux, or just some particular implementation of it? Is there a better list, where all competing hardware and software can be discussed as solutions without people getting flamed? I don't want to offend by talking about the wrong hardware brand, or software which can be used by a ten year old, but those are the kinds of QA I thought I'd find here. perhaps if you were to reread some of the old email threads you would realise that you have not quite grasped the whole situation -- Bill Davidsen david...@tmr.com Unintended results are the well-earned reward for incompetence. -- 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
Has anybody tried Freeview HD in UK
Hi, I've read that they are going to start trial for HD DVB on Freeview http://www.bbc.co.uk/blogs/bbcinternet/2009/06/whats_happening_with_freeview.html http://www.dtg.org.uk/dtg/press_release.php?id=14 They mention September, October and Decembre 2009, does anybody know more detailed info? Is it using the same transmission, just a different codec, or do we need new receivers? Andrea -- 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
stv090x/stv6110x improvements and bug fixes
Hi, some time ago, I made some improvements and fixed some bugs in the stv090x and stv6110x frontend drivers. These include: - increased search range on STV090x based on symbol rate - fixed some STV090x register definitions and typos - fix STR and SNR calculation and normalize the value into the 0..0x range - fixed STV6110x r divider calculation when setting frequency - first disable DVB-S and DVB-S2 mode before enabling it again for automatic search - fix calculation of AGC2 values - corrections of several register values - several blind scan related fixes They were available since about two months and tested successfully using TT S2-1600 card by me and other people from vdrportal.de. I made them public in my repository available at http://powarman.dyndns.org/hg/v4l-dvb Regards Andreas -- 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: Has anybody tried Freeview HD in UK
On 10/14/2009 10:12 PM, Andrea wrote: Hi, I've read that they are going to start trial for HD DVB on Freeview http://www.bbc.co.uk/blogs/bbcinternet/2009/06/whats_happening_with_freeview.html http://www.dtg.org.uk/dtg/press_release.php?id=14 They mention September, October and Decembre 2009, does anybody know more detailed info? Is it using the same transmission, just a different codec, or do we need new receivers? In my understanding they will start new DVB-T2 standard and due to that new devices are needed. There is no DVB-T2 devices publicly sold currently. Few vendors like Pace and Humax have public prototypes. Basically new demodulator chips are needed and I don't know if there is any publicly released. Finland will also start DVB-T2 SFN (Single Frequency Network) with h.264 during next year. There is two VHF muxes currently reserved for that. Antti -- http://palosaari.fi/ -- 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: Haupp. HVR-1100 problem and DVB-T card
Hi Fabio, Am Mittwoch, den 14.10.2009, 13:54 + schrieb fabio tirapelle: - Messaggio originale - Da: hermann pitton hermann-pit...@arcor.de A: fabio tirapelle ftirape...@yahoo.it I have installed mythtv on this configuration: Asus M3N78-VM GF8200 RGVSM AMD Ath64 X2LV 3100BOX6000+ 1MB Haupp. WinTV HVR-1100 -t/a PCI TechniSat SkyStar 2 DVB-S PCI nVidia GeForce 8200 Ubuntu 8.10 - Linux htpc 2.6.27-11-generic I would try to test the HVR1110 next on another PC with known working PCI hardware, also above different operating systems if possible. Hi Hermann! Thank you for your quick response. I tested the card on a M2N-VM DH and it works. So my best guess is that the card does not work on my actual motherboard. We know that the HVR1110s are properly detected on almost all hardware. Before thinking about replacing mobo/PSU, make sure the card is OK. Do you have a suggestion for a new mobo that you know is working (if I can keep my other hardware that would be great)? the mobo might need some quirk i'm not aware off. Since we do not have any other such report yet, knock on wood, I would expect all other hardware is still fine. Cheers, Hermann -- 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
DVB Hardware blind scan - frontend?
I'm looking to take advantage of blind-scan support in the STV0903 DVB-S/S2 frontend. What does this entail? I'm not seeing anything in linux/dvb/frontend.h in regards to frontend capabilities and the ability to do frequency and symbol rate scans. drivers/media/dvb/dvb-core/dvb_frontend.h has talk of defining different search types and algorithms.. Where can I get more information about this? Any example code I can look over out there? Is blind-scan support still hardware-specific or does DVB API v5 support it? Thanks for any help on the matter! --Mike -- 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: More about Winfast TV USB Deluxe
Strange, but changeing the tvaudio_addr = 0xb0 to 88, (half of the
decimal value of b0) made tvaudio find my tda9874.
[ 1186.725140] tvaudio: TV audio decoder + audio/video mux driver
[ 1186.725142] tvaudio: known chips: tda9840, tda9873h, tda9874h/a/ah,
tda9875, tda9850, tda9855, tea6300, tea6320, tea6420, tda8425,
pic16c54 (PV951), ta8874z
[ 1186.725151] tvaudio 4-0058: chip found @ 0xb0
[ 1186.736444] tvaudio 4-0058: chip_read2: reg254=0x11
[ 1186.749704] tvaudio 4-0058: chip_read2: reg255=0x2
[ 1186.749708] tvaudio 4-0058: tda9874a_checkit(): DIC=0x11, SIC=0x2.
[ 1186.749710] tvaudio 4-0058: found tda9874a.
[ 1186.749712] tvaudio 4-0058: tda9874h/a/ah found @ 0xb0 (em28xx #0)
[ 1186.749714] tvaudio 4-0058: matches:.
[ 1186.749716] tvaudio 4-0058: chip_write: reg0=0x0
[ 1186.760012] tvaudio 4-0058: chip_write: reg1=0xc0
[ 1186.772014] tvaudio 4-0058: chip_write: reg2=0x2
[ 1186.784013] tvaudio 4-0058: chip_write: reg11=0x80
[ 1186.796010] tvaudio 4-0058: chip_write: reg12=0x0
[ 1186.808013] tvaudio 4-0058: chip_write: reg13=0x0
[ 1186.820012] tvaudio 4-0058: chip_write: reg14=0x1
[ 1186.832015] tvaudio 4-0058: chip_write: reg15=0x0
[ 1186.844012] tvaudio 4-0058: chip_write: reg16=0x14
[ 1186.856018] tvaudio 4-0058: chip_write: reg17=0x50
[ 1186.868011] tvaudio 4-0058: chip_write: reg18=0xf9
[ 1186.880745] tvaudio 4-0058: chip_write: reg19=0x80
[ 1186.892347] tvaudio 4-0058: chip_write: reg20=0x80
[ 1186.904015] tvaudio 4-0058: chip_write: reg24=0x80
[ 1186.916011] tvaudio 4-0058: chip_write: reg255=0x0
[ 1186.928021] tvaudio 4-0058: tda9874a_setup(): A2, B/G [0x00].
[ 1186.928091] tvaudio 4-0058: thread started
Now I probably need to set some gpio's too
/Magnus
2009/10/14 Magnus Alm magnus@gmail.com:
Loaded em28xx with i2c_scan and i2c_debug and tvaudio with tda9874a
option and debug.
sudo modprobe -v em28xx i2c_scan=1 i2c_debug=1
sudo modprobe -v tvaudio tda9874a=1 debug=1
And got this ouput:
[91083.588182] em28xx #0: found i2c device @ 0x30 [???]
[91083.590179] em28xx #0: found i2c device @ 0x3e [???]
[91083.590804] em28xx #0: found i2c device @ 0x42 [???]
[91083.600308] em28xx #0: found i2c device @ 0x86 [tda9887]
[91083.603805] em28xx #0: found i2c device @ 0xa0 [eeprom]
[91083.606183] em28xx #0: found i2c device @ 0xb0 [tda9874]
[91083.608808] em28xx #0: found i2c device @ 0xc2 [tuner (analog)]
[91083.617682] em28xx #0: Identified as Leadtek Winfast USB II Deluxe
(card=28)
[91083.617684] em28xx #0:
[91083.617684]
[91083.617687] em28xx #0: The support for this board weren't valid yet.
[91083.617688] em28xx #0: Please send a report of having this working
[91083.617690] em28xx #0: not to V4L mailing list (and/or to other addresses)
[91083.617691]
[91083.980702] saa7115 4-0021: saa7114 found (1f7114d0e00) @ 0x42
(em28xx #0)
[91086.173114] tvaudio: TV audio decoder + audio/video mux driver
[91086.173116] tvaudio: known chips: tda9840, tda9873h, tda9874h/a/ah,
tda9875, tda9850, tda9855, tea6300, tea6320, tea6420, tda8425,
pic16c54 (PV951), ta8874z
[91086.173125] tvaudio 4-00b0: chip found @ 0x160
[91086.173127] tvaudio 4-00b0: no matching chip description found
[91086.173131] tvaudio: probe of 4-00b0 failed with error -5
It seems to be a tda9874 there - em28xx #0: found i2c device @ 0xb0 [tda9874]
But does tvaudio stop @ 0x160 (decimal value of 0xa0 rigth? ) and
doesn't look further?
I mean does tvaudio find my boards eeprom, cant talk to it and gives up?
/Magnus
2009/10/13 Magnus Alm magnus@gmail.com:
Hi!
Thanks to Devin's moral support I now have sound in television. ;-)
Thanks!!
I pooked around some more managed to get radio to function with these
settings:
[EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE] = {
.name = Leadtek Winfast USB II Deluxe,
.valid = EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
.tda9887_conf = TDA9887_PRESENT |
TDA9887_PORT1_ACTIVE,
.decoder = EM28XX_SAA711X,
.input = { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = SAA7115_COMPOSITE4,
.amux = EM28XX_AMUX_AUX,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = SAA7115_COMPOSITE5,
.amux = EM28XX_AMUX_LINE_IN,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = SAA7115_SVIDEO3,
.amux = EM28XX_AMUX_LINE_IN,
} },
.radio = {
.type = EM28XX_RADIO,
.amux = EM28XX_AMUX_AUX,
}
},
I tested with different settings on tda9887 and modprobe tda9887
port1=1 seemed to work be best.
One odd thing when the
Re: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
On Wed, 2009-10-14 at 12:01 +0100, Simon Farnsworth wrote: Andy Walls wrote: Have your remote user read http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality and take any actions that seem appropriate/easy. I'll try that again - they're grouching, because their TV is fine, and the same card in a Windows PC is also fine. It's just under Linux that they're seeing problems, so I may not be able to get them to co-operate. Right, the windows driver code for the mxl5005s is better. Inform him that the linux driver for the mxl5005s could be better. If he has any contacts at MaxLinear to get the datasheet and programming manual released to me, I can make the linux driver better. The in kernel mxl5005s driver is known to have about 3 dB worse performance for QAM vs 8-VSB (Steven Toth took some measurements once). Am I misunderstanding dmesg here? I see references to a Samsung S5H1409, The S5H1409 refers to the CX24227 ATSC/QAM demodulator chip (Conexant bought the rights to the S5H1409 from Samsung). That chip is where the analog waveform actually gets demodulated down to digital data bits. . not to an mxl5005s; The MXL5005s is the silicon tuner chip on the Digital TV side of the HVR-1600. A simple picture for you: Cable ---| MXL5005s || CX24227 || CX23418 |--- PCI bus Analog Waveform---|Digital Data-- if I've read the driver code correctly, I'd see a KERN_INFO printk for the mxl5005s when it comes up. Here's my HVR-1600 related entries from dmesg on startup. I have the MXL5005S showing up at 9.510: [8.779549] cx18: Start initialization, version 1.2.0 [9.042096] cx18-0: Initializing card 0 [9.042099] cx18-0: Autodetected Hauppauge card [9.042128] ivtv: End initialization [9.042433] cx18 :02:02.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [9.044796] cx18-0: cx23418 revision 0101 (B) [9.287165] tveeprom 2-0050: Hauppauge model 74551, rev C1A3, serial# 1845764 [9.287169] tveeprom 2-0050: MAC address is 00-0D-FE-1C-2A-04 [9.287172] tveeprom 2-0050: tuner model is TCL MFNM05-4 (idx 103, type 43) [9.287175] tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08) [9.287177] tveeprom 2-0050: audio processor is CX23418 (idx 38) [9.287179] tveeprom 2-0050: decoder processor is CX23418 (idx 31) [9.287181] tveeprom 2-0050: has radio [9.287183] cx18-0: Autodetected Hauppauge HVR-1600 [9.287185] cx18-0: Simultaneous Digital and Analog TV capture supported [9.402274] tuner 3-0043: chip found @ 0x86 (cx18 i2c driver #0-1) [9.402351] tda9887 3-0043: creating new instance [9.402353] tda9887 3-0043: tda988[5/6/7] found [9.405781] tuner 3-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) [9.418329] cs5345 2-004c: chip found @ 0x98 (cx18 i2c driver #0-0) [9.421205] tuner-simple 3-0061: creating new instance [9.421208] tuner-simple 3-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F)) [9.423993] cx18-0: Registered device video0 for encoder MPEG (64 x 32 kB) [9.423997] DVB: registering new adapter (cx18) [9.510767] MXL5005S: Attached at address 0x63 [9.510774] DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... [9.510855] cx18-0: DVB Frontend registered [9.510858] cx18-0: Registered DVB adapter0 for TS (32 x 32 kB) [9.510892] cx18-0: Registered device video32 for encoder YUV (16 x 128 kB) [9.510922] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes) [9.510946] cx18-0: Registered device video24 for encoder PCM audio (256 x 4 kB) [9.510970] cx18-0: Registered device radio0 for encoder radio [9.510973] cx18-0: Initialized card: Hauppauge HVR-1600 [9.510997] cx18: End initialization -- 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: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
On Wed, Oct 14, 2009 at 11:12 PM, Andy Walls awa...@radix.net wrote: On Wed, 2009-10-14 at 12:01 +0100, Simon Farnsworth wrote: Andy Walls wrote: Have your remote user read http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality and take any actions that seem appropriate/easy. I'll try that again - they're grouching, because their TV is fine, and the same card in a Windows PC is also fine. It's just under Linux that they're seeing problems, so I may not be able to get them to co-operate. Right, the windows driver code for the mxl5005s is better. Inform him that the linux driver for the mxl5005s could be better. If he has any contacts at MaxLinear to get the datasheet and programming manual released to me, I can make the linux driver better. I've got the datasheet. It's just one of those projects on my list where I have to get around to hooking up the i2c analyzer to a running board, capture the block that gets programmed into the chip under Windows, and compare the bits against Linux. I've just been tied up in too much other stuff to do the legwork 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
[PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-audio-panic
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/em28xx-audio-panic for the following: em28xx: fix panic that can occur when starting audio streaming Since this is a rather nasty kernel panic, we should probably look at getting this back into stable as well. 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
