Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/ davinci offer (and preferably also for similar devices by other manufacturers). Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? I've asked Magnus Damm to take a look at this. I know he did some work in this area and he may have fixed some of these issues already. Very useful, that Embedded Linux conference... Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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: libv4l release: 0.5.97: the whitebalance release!
On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: PROBLEM: crashes or unstability while watching tv with MPlayer from pci bttv card
Begin forwarded message: Date: Wed, 15 Apr 2009 06:31:46 -0500 From: Alejandro Vélez null...@gmail.com To: linux-ker...@vger.kernel.org Subject: PROBLEM: crashes or unstability while watching tv with MPlayer from pci bttv card [1.] One line summary of the problem: General system unstability occurs while previewing any video input from the pci bttv-card with MPlayer SVN. [2.] Full description of the problem/report: after a time of watching or previewing the tv card input with MPlayer the system becomes irreversibly unstable, for example the kernel can crash in a different number of ways all the times that that I have reproduced such behavior or the system just lockups with the caps lock and scroll lock leds blinking. [3.] Keywords (i.e., modules, networking, kernel): kernel, crashes, lockups, unstability, MPlayer, Hauppauge WinTV-Go, bttv, X11, bttv. [4.] Kernel version (from /proc/version): Linux version 2.6.29.1-smp (r...@midas) (gcc version 4.3.3 (GCC) ) #1 SMP Fri Apr 10 18:42:54 CDT 2009 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) Not Applicable. There's a different type of kernel crash if there's it at all everytime that I reproduce the bug. [6.] A small shell script or example program which triggers the problem (if possible) I just preview the tv input with the command: mplayer tv:// -tv input=1:normid=0 [7.] Environment [7.1.] Software (add the output of the ver_linux script here) If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux slacktoo 2.6.29.1-smp #1 SMP Fri Apr 10 18:42:54 CDT 2009 i686 Unknown CPU Type AuthenticAMD GNU/Linux Gnu C 4.2.3 Gnu make 3.81 binutils 2.17.50.0.17.20070615 util-linux 2.13.1 mount 2.13.1 module-init-tools found quota-tools3.13. Linux C Library2.7 Dynamic linker (ldd) 2.7 Linux C++ Library 6.0.9 Procps 3.2.7 Kbd1.12 oprofile 0.9.2 Sh-utils 6.9 udev 118 Modules Loaded savage drm bsd_comp ppp_synctty ppp_async crc_ccitt ppp_generic slhc it87 hwmon_vid snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss ipt_MASQUERADE xt_limit xt_pkttype ipt_REJECT xt_tcpudp xt_state ipt_LOG iptable_mangle iptable_nat iptable_filter nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables nls_utf8 ntfs xfs exportfs quota_v2 quota_tree lp fuse tuner_simple tuner_types tuner tvaudio fan snd_cs4232 snd_wavefront snd_wss_lib ns558 snd_opl3_lib snd_hwdep bttv snd_mpu401 ir_common i2c_algo_bit v4l2_common thermal parport_pc videodev parport v4l1_compat serio_raw processor thermal_sys hwmon videobuf_dma_sg videobuf_core evdev psmouse button rtc_cmos rtc_core rtc_lib snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore btcx_risc uhci_hcd via_agp tveeprom i2c_viapro shpchp agpgart sundance i2c_core 8139too mii sg ext3 jbd mbcache [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : Unknown CPU Type stepping: 1 cpu MHz : 1673.954 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up bogomips: 3347.90 clflush size: 32 power management: ts [7.3.] Module information (from /proc/modules): savage 30940 2 - Live 0xe6ccb000 drm 137824 3 savage, Live 0xe6ae7000 bsd_comp 5244 0 - Live 0xe6f2e000 ppp_synctty 6940 0 - Live 0xe6eca000 ppp_async 8668 1 - Live 0xe6de5000 crc_ccitt 1628 1 ppp_async, Live 0xe6ddd000 ppp_generic 22472 7 bsd_comp,ppp_synctty,ppp_async, Live 0xe6d88000 slhc 5404 1 ppp_generic, Live 0xe6d6d000 it87 19820 0 - Live 0xe6d51000 hwmon_vid 2684 1 it87, Live 0xe6d4e000 snd_seq_dummy 2464 0 - Live 0xe6cc6000 snd_seq_oss 29792 0 - Live 0xe6ca3000 snd_seq_midi_event 5980 1 snd_seq_oss, Live 0xe6c8e000 snd_seq 47984 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event, Live 0xe6a67000 snd_pcm_oss 37728 0 - Live 0xe683e000 snd_mixer_oss 14300 1 snd_pcm_oss, Live 0xe6812000 ipt_MASQUERADE 2460 1 - Live 0xe897a000 xt_limit 1824 3 - Live 0xe8885000 xt_pkttype 1372 1 - Live 0xe886d000 ipt_REJECT 2780 8 - Live 0xe8659000 xt_tcpudp 2620 40 - Live 0xe852f000 xt_state 1756 7 - Live 0xe84f4000 ipt_LOG 5344 13 - Live 0xe84d8000 iptable_mangle 2332 0 - Live 0xe843b000 iptable_nat 4796 1 - Live 0xe8415000 iptable_filter 2268 1 - Live 0xe83f nf_conntrack_irc
Re: dvbd
Hi! Kjeld Flarup wrote: I've taken some interest in a small piece of software called dvbd. http://dvbd.sourceforge.net/ I really like the concept of this software, because it could be used for sharing one DVB card among several different applications. That's right. BUT the software have not been developed since 2004. And it needs a few tweaks when you're using a more recent C++ compiler like gcc 4.3.x. Is this because it is not so smart anyway, or are there some better programs out there? There is VDR, of course. But I don't like the way it does things. Therefore, I've been using dvbd for years to handle my small zoo of DVB-T receivers (I've got four of them running at the moment). It easily handles several recordings in parallel without using many resources - a few megabytes of RAM and a few percent of CPU time on an old (2005) Athlon64. I currently consider moving it to an Intel Atom based system. dvbd does sometimes have issues with disk writes, though. It doesn't do much buffering, and if another process is blocking the disk it's writing to for too long, you may encounter drop-outs. It's best to give it a disk of its own. Similarly, if dvbd doesn't get scheduled for a while, it will lose data from the receivers. On a single-core machine that also does other things (like mine), I recommend to raise its priority with nice --20, or maybe use a realtime priority level. -- Michael Tired Riepe michael.ri...@googlemail.com X-Tired: Each morning I get up I die a little -- 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
saa716x driver
Hi. I have a card named AverMedia TV Hybrid Speedy PCI-E and I'm tryiing to make it working under linux. I've found the drivers at http://jusst.de/hg/saa716x/ The drivers hangs on loading, this is the output: saa716x_pci_init (0): found a Avermedia H788 PCIe card SAA716x Hybrid :03:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 SAA716x Hybrid :03:00.0: setting latency timer to 64 SAA7160 Rev 3 [1461:1455], irq: 17, mmio: 0xc2000570 SAA7160 64Bit, MSI Disabled, MSI-X=32 msgs saa716x_i2c_hwinit (0): Adapter (c000) SAA716x I2C Core 0 RESET saa716x_i2c_hwinit (0): Adapter (b000) SAA716x I2C Core 1 RESET saa716x_i2c_send (0): TXFIFO not empty after Timeout, tried 10 loops, 100 mS! saa716x_i2c_hwinit (0): Adapter (c000) SAA716x I2C Core 0 RESET this repeats many times, modprobe hangs for a few minutes saa716x_i2c_hwinit (0): Adapter (c000) SAA716x I2C Core 0 RESET saa716x_eeprom_header (0): ERROR: Header size mismatch! Read size=8 bytes, Expected=65535 saa716x_eeprom_data (0): ERROR: Header Read failed -1 saa716x_hybrid_pci_probe (0): SAA716x EEPROM dump failed DVB: registering new adapter (SAA716x dvb adapter) I've also tried various int_type values but with no success. After some experiments, I've found that reverting patches Fix BUS ordering and Fix swapped I2C buses fixed the hang during module loading, now it the output is: saa716x_pci_init (0): found a Avermedia H788 PCIe card SAA716x Hybrid :03:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 SAA716x Hybrid :03:00.0: setting latency timer to 6 SAA7160 Rev 3 [1461:1455], irq: 17, mmio: 0xc20005b0 SAA7160 64Bit, MSI Disabled, MSI-X=32 msgs saa716x_i2c_hwinit (0): Adapter (49152) SAA716x I2C Core saa716x_i2c_hwinit (0): Adapter (45056) SAA716x I2C Core saa716x_get_offset (0): Offset @ 192 saa716x_read_rombytes (0): Last Message length=16 SAA7160 ROM: = Device 0 = SAA7160 ROM: = Device 1 = SAA7160 ROM: = Device 2 = SAA7160 ROM: = Device 3 = SAA7160 ROM: = Device 4 = DVB: registering new adapter (SAA716x dvb adapter) After that, there are created some device nodes in /dev/dvb/adapter0 (demux0, dvr0, net0) but no frontend device node. It looks like the drivers are not yet fully working. Is there a chance that the card will be usable under linux? -- Marcel Šebek -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Apr 19 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11517:cda79523a93c 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-rc1-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-rc1-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-rc1-i686: WARNINGS 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-rc1-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29.1-mips: OK linux-2.6.30-rc1-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: OK linux-2.6.30-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK 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: OK linux-2.6.30-rc1-x86_64: WARNINGS fw/apps: OK sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc1): 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: WARNINGS 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: WARNINGS 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/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification from this daily build 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
Add Elgato EyeTV DTT deluxe to dibcom driver
This patch introduces support for DVB-T for the following dibcom based
card:
Elgato EyeTV DTT deluxe (USB-ID: 0fd9:0020)
Patch tested with Ubuntu 8.10 and Totem/gstream for watching TV in
Berlin, see also following log:
Apr 19 17:05:30 parallels-ubuntu kernel: [ 1320.452301] usb 1-1: new
high speed USB device using ehci_hcd and address 4
Apr 19 17:05:30 parallels-ubuntu kernel: [ 1320.630760] usb 1-1:
configuration #1 chosen from 1 choice
Apr 19 17:05:30 parallels-ubuntu kernel: [ 1320.676135] dvb-usb: found
a 'Elgato EyeTV Dtt Dlx PD378S' in warm state.
Apr 19 17:05:30 parallels-ubuntu kernel: [ 1320.686115] dvb-usb: will
pass the complete MPEG2 transport stream to the software demuxer.
Apr 19 17:05:30 parallels-ubuntu kernel: [ 1320.689773] DVB:
registering new adapter (Elgato EyeTV Dtt Dlx PD378S)
Apr 19 17:05:31 parallels-ubuntu kernel: [ 1321.401068] DVB:
registering adapter 0 frontend 0 (DiBcom 7000PC)...
Apr 19 17:05:32 parallels-ubuntu kernel: [ 1322.039172] DiB0070:
successfully identified
Apr 19 17:05:32 parallels-ubuntu kernel: [ 1322.052382] input: IR-
receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.
7/usb1/1-1/input/input6
Apr 19 17:05:32 parallels-ubuntu kernel: [ 1322.076363] dvb-usb:
schedule remote query interval to 50 msecs.
Apr 19 17:05:32 parallels-ubuntu kernel: [ 1322.076373] dvb-usb:
Elgato EyeTV Dtt Dlx PD378S successfully initialized and connected.
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-04-19
19:26:33.0 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c 2009-04-19
10:58:16.0 +0200
@@ -1497,6 +1497,7 @@ struct usb_device_id dib0700_usb_id_tabl
{ USB_DEVICE(USB_VID_HAUPPAUGE, USB_PID_HAUPPAUGE_TIGER_ATSC_B210) },
{ USB_DEVICE(USB_VID_YUAN, USB_PID_YUAN_MC770) },
{ USB_DEVICE(USB_VID_ELGATO,USB_PID_ELGATO_EYETV_DTT) },
+ { USB_DEVICE(USB_VID_ELGATO,USB_PID_ELGATO_EYETV_DTT_Dlx) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -1696,7 +1697,7 @@ struct dvb_usb_device_properties dib0700
},
},
- .num_device_descs = 11,
+ .num_device_descs = 12,
.devices = {
{ DiBcom STK7070P reference design,
{ dib0700_usb_id_table[15], NULL },
@@ -1742,6 +1743,10 @@ struct dvb_usb_device_properties dib0700
{ dib0700_usb_id_table[45], NULL },
{ NULL },
},
+ { Elgato EyeTV Dtt Dlx PD378S,
+ { dib0700_usb_id_table[50], NULL },
+ { NULL },
+ },
},
.rc_interval = DEFAULT_RC_INTERVAL,
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-04-19
19:26:08.0 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb.h 2009-04-19
11:02:54.0 +0200
@@ -224,7 +224,7 @@ struct dvb_usb_device_properties {
int generic_bulk_ctrl_endpoint;
int num_device_descs;
- struct dvb_usb_device_description devices[11];
+ struct dvb_usb_device_description devices[12];
};
/**
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-04-19
19:24:49.0 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2009-04-19
10:39:18.0 +0200
@@ -253,5 +253,6 @@
#define USB_PID_MSI_DIGI_VOX_MINI_III 0x8807
#define USB_PID_SONY_PLAYTV0x0003
#define USB_PID_ELGATO_EYETV_DTT 0x0021
+#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x0020
#endif
---
Grüße Armin Schenker
s...@snafu.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
2009/4/19 Hans de Goede hdego...@redhat.com: On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Applying Adam Bakers patch makes the control appear _but_ I can't seem to make out any difference when any of the whitebalancing and normalize options, regardless of how i tweak the max / min values. Best regards, Erik Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
On 04/19/2009 09:20 PM, Erik Andrén wrote: 2009/4/19 Hans de Goedehdego...@redhat.com: On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Applying Adam Bakers patch makes the control appear _but_ I can't seem to make out any difference when any of the whitebalancing and normalize options, regardless of how i tweak the max / min values. Did you also do the export LIBV4LCONTROL_CONTROLS=15 In the terminal from where you are starting the viewing application ? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Add Elgato EyeTV DTT deluxe to dibcom driver
Armin Schenker kirjoitti: -.num_device_descs = 11, +.num_device_descs = 12, -struct dvb_usb_device_description devices[11]; +struct dvb_usb_device_description devices[12]; I don't comment about this patch but general. I didn't realized this value is allowed to increase when adding new devices. Due to that there is now three dvb_usb_device_properties in af9015 which makes driver a little bit complex. What we should do? Can I remove code from af9015 and increase dvb_usb_device_description count to about 30? What is biggest suitable value we want use, how much memory one entry will take. regards 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
[patch review] av7110_hw: fix compile warning
One more warning fix.
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
--
diff -r cda79523a93c linux/drivers/media/dvb/ttpci/av7110_hw.c
--- a/linux/drivers/media/dvb/ttpci/av7110_hw.c Thu Apr 16 18:30:38 2009 +0200
+++ b/linux/drivers/media/dvb/ttpci/av7110_hw.c Mon Apr 20 00:17:51 2009 +0400
@@ -1089,7 +1089,7 @@
else {
int i, len = dc-x0-dc-color+1;
u8 __user *colors = (u8 __user *)dc-data;
- u8 r, g, b, blend;
+ u8 r, g = 0, b = 0, blend = 0;
ret = 0;
for (i = 0; ilen; i++) {
if (get_user(r, colors + i * 4) ||
--
Best regards, Klimov Alexey
--
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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
On Sun, Apr 19, 2009 at 10:18 PM, Hans Verkuil hverk...@xs4all.nl wrote: 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: Sun Apr 19 19:00:03 CEST 2009 path: http://www.linuxtv.org/hg/v4l-dvb changeset: 11517:cda79523a93c 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-rc1-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-rc1-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-rc1-i686: WARNINGS When trying to compile v4l-dvb tree under 2.6.30-rc2 (up-to-date) i have such error with pvr2 module: CC [M] /w/new/v4l-dvb/v4l/pvrusb2-hdw.o /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_upload_firmware1': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:1474: error: implicit declaration of function 'usb_settoggle' /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_hdw_load_modules': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:2133: warning: format not a string literal and no format arguments make[3]: *** [/w/new/v4l-dvb/v4l/pvrusb2-hdw.o] Error 1 make[2]: *** [_module_/w/new/v4l-dvb/v4l] Error 2 It's probably due to this git commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3444b26afa145148951112534f298bdc554ec789 I don't have idea how to fix it fast and correctly. -- Best regards, Klimov Alexey -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hi, Am Montag, den 20.04.2009, 02:42 +0400 schrieb Alexey Klimov: On Sun, Apr 19, 2009 at 10:18 PM, Hans Verkuil hverk...@xs4all.nl wrote: 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:Sun Apr 19 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11517:cda79523a93c 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-rc1-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-rc1-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-rc1-i686: WARNINGS When trying to compile v4l-dvb tree under 2.6.30-rc2 (up-to-date) i have such error with pvr2 module: CC [M] /w/new/v4l-dvb/v4l/pvrusb2-hdw.o /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_upload_firmware1': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:1474: error: implicit declaration of function 'usb_settoggle' /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_hdw_load_modules': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:2133: warning: format not a string literal and no format arguments make[3]: *** [/w/new/v4l-dvb/v4l/pvrusb2-hdw.o] Error 1 make[2]: *** [_module_/w/new/v4l-dvb/v4l] Error 2 It's probably due to this git commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3444b26afa145148951112534f298bdc554ec789 I don't have idea how to fix it fast and correctly. without looking into further details, did build a 2.6.30-rc2-git4 yesterday evening for an x86_64 and the whole media tree compiled without warnings and errors including that one. Was looking for if, the the breakage of some saa7134 cards on 2.6.29 made it into that one too. As far as I can say without graphics card and wireless support there, but able to record, luckily not. Maybe give it a try and/or identify related further patches. Is git5 now. 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
Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
On Mon, 20 Apr 2009, Alexey Klimov wrote: [...] When trying to compile v4l-dvb tree under 2.6.30-rc2 (up-to-date) i have such error with pvr2 module: CC [M] /w/new/v4l-dvb/v4l/pvrusb2-hdw.o /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_upload_firmware1': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:1474: error: implicit declaration of function 'usb_settoggle' /w/new/v4l-dvb/v4l/pvrusb2-hdw.c: In function 'pvr2_hdw_load_modules': /w/new/v4l-dvb/v4l/pvrusb2-hdw.c:2133: warning: format not a string literal and no format arguments make[3]: *** [/w/new/v4l-dvb/v4l/pvrusb2-hdw.o] Error 1 make[2]: *** [_module_/w/new/v4l-dvb/v4l] Error 2 It's probably due to this git commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3444b26afa145148951112534f298bdc554ec789 I don't have idea how to fix it fast and correctly. This might explain things a bit. The following thread took place on linux-usb on 7-April: quote On Tue, 7 Apr 2009, Greg KH wrote: On Tue, Apr 07, 2009 at 05:31:55PM +, David Vrabel wrote: Wireless USB endpoint state has a sequence number and a current window and not just a single toggle bit. So allow HCDs to provide a endpoint_reset method and call this or clear the software toggles as required (after a clear halt). usb_settoggle() and friends are then HCD internal and are moved into core/hcd.h. You remove this api, yet the pvrusb2 driver used it, and you don't seem to have resolved the issue where it was calling it: diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c b/drivers/media/video/pvrusb2/pvrusb2-hdw.c index fa304e5..b86682d 100644 --- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c @@ -1418,7 +1418,6 @@ static int pvr2_upload_firmware1(struct pvr2_hdw *hdw) return ret; } - usb_settoggle(hdw-usb_dev, 0 0xf, !(0 USB_DIR_IN), 0); usb_clear_halt(hdw-usb_dev, usb_sndbulkpipe(hdw-usb_dev, 0 0x7f)); pipe = usb_sndctrlpipe(hdw-usb_dev, 0); Should usb_reset_endpoint() be called here instead? Speaking as the maintainer of that driver, I'm OK with accepting this as-is for now. This is a sequence that should not interfere with normal driver operation. I will look at this further a little later (not likely before the merge window closes) and if this change turns out to cause a problem I'll make a follow-up fix upstream. Acked-By: Mike Isely is...@pobox.com -Mike /quote So the kernel already has this; it just needs to be pulled back into v4l-dvb. It's an obvious trivial thing for now and I've acked it there. Obviously we're getting had here because you're compiling against a kernel snapshot that's been changed but v4l-dvb doesn't have the corresponding change in its local copy of the pvrusb2 driver. Part of the fun of synchronizing changes from different trees :-( Mauro: If you just want to take this as-is (or find the git commit and pull it down), I'm fine. Otherwise I'll set up a repo that you can pull from with this single-line change. The above changeset also has the following attributions: From: David Vrabel david.vra...@csr.com Signed-off-by: David Vrabel david.vra...@csr.com -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] soc-camera: convert to platform device
Hi Magnus http://www.open-technology.de/download/20090415/ based on linux-next history branch, commit ID in -base file. Don't be surprised, that patch-set also contains a few not directly related patches. Testing on Migo-R board with 2.6.30-rc2-git-something and the following cherry-picked patches: 0007-driver-core-fix-driver_match_device.patch 0033-soc-camera-host-driver-cleanup.patch 0034-soc-camera-remove-an-extra-device-generation-from-s.patch 0035-soc-camera-simplify-register-access-routines-in-mul.patch and part of 0036 (avoiding rejects, ap325 seems broken btw) Have I broken it or is it unrelated? I don't know about current 2.6.30-rc2 git. But when I used 2.6.30-rc1, It doesn't work either. The reason was soc_camera_bus_type doesn't has match function. please check 49b420a13ff95b449947181190b08367348e3e1b And please see http://marc.info/?t=12324585986r=1w=2 I send patch to this problem. 2009/03/31 [PATCH] soc_camera: Add soc_camera_match function And please check this patch. This patch needed on ov772x, but may be rc2 already have it. 06/09: ov772x: wrong pointer for soc_camera_link is modified http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=157893ad8d0b Best regards -- Kuninori Morimoto -- 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] [PATCH] firmware: convert av7110 driver to request_firmware()
Hi, Am Sonntag, den 19.04.2009, 23:41 +0200 schrieb Román: 2009/4/19 David Woodhouse dw...@infradead.org: On Sun, 2009-04-19 at 13:40 -0700, VDR User wrote: To be absolutely clear; users compiling dvb drivers outside of the kernel should copy v4l-dvb/linux/firmware/av7110/bootcode.bin.ihex to /lib/firmware/av7110/bootcode.bin correct? Run 'objcopy -Iihex -Obinary bootcode.bin.ihex bootcode.bin' first, then copy the resulting bootcode.bin file to /lib/firmware/av7110/ That doesn't seem very *obvious* to me, actually. After ten year of using gnu/linux, I don't consider myself a newbie, but I didn't know what was the purpose of that command (if I ever knew it existed). Maybe it's just I never had the need for such a tool. We didn't want to put raw binary files into the kernel source tree so we converted them to a simple hex form instead. IMHO that's the right direction. As I said, the makefiles in the kernel tree get this right, and convert them to binary for you and automatically install them. It shouldn't be hard to fix the v4l tree to do it too, but as I also said, I'm not particularly interested in doing that myself. -- dwmw2 Well, VDR *just wanted it fixed*: that's what he asked for in its first message on this thread. At least, David, you gave some useful information; but I found your attitude -and please note I don't want to offend you personally- more or less annoying. I don't understand why you said so lightly he was trolling, specially when he is a somewhat active participant on this list, I know you didn't either, but if I had to say someone was trolling in here, you'll be my first candidate. Derek simply pointed out a problem on the v4l-dvb tree. I think the most of us don't have much time to spend on this kind of volunteer projects, so we should avoid wasting it on sterile arguments. Once again, excuse me if I did offend you. That was not my intention. Regards, -- Román giving seemingly the troll then, but asking just some simple questions, likely already answered over all this years ... The firmware download for the tda10046 was broken for months, likely half a year. Technotrend changed the URL and LifeView disappeared somehow. Now we have a fix, Douglas had the fun to promote it. The firmware versions still differ between revision 20 and 29. Some OEMs, as far as i can tell, controlled on that other OS, that firmware updates should only be made on such revisions of the chips really in need and later ones should not be touched. This could mean that the flashing itself inherits some known risks only. For what I have seen so far, it also could be the other way round sometimes, let the old chips with the old firmware and don't touch them. How do you know about this? Related, they get a substantial load on their servers to serve also cards not even produced by them. Who did ask them to still tolerate this and how sure you know they deliver the correct stuff, given that revision 20 and 29 are around for free choice ? Have there been any tries to ask Philips/NXP what to use on what and can we be confident that the latest version is always suitable for all stuff around? I just don't know and have some doubts. 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
Re: libv4l release: 0.5.97: the whitebalance release!
Hans de Goede wrote: On 04/19/2009 09:20 PM, Erik Andrén wrote: 2009/4/19 Hans de Goedehdego...@redhat.com: On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Applying Adam Bakers patch makes the control appear _but_ I can't seem to make out any difference when any of the whitebalancing and normalize options, regardless of how i tweak the max / min values. Did you also do the export LIBV4LCONTROL_CONTROLS=15 In the terminal from where you are starting the viewing application ? Yes. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
