Re: 2.6.32 dvbdev error / Cinergy XS [0ccd:0043]
Am Samstag, 10. Oktober 2009 23:48:37 schrieb Devin Heitmueller: On Sat, Oct 10, 2009 at 4:19 PM, Michael G miga_m...@gmx.de wrote: Hi, can someone please help me to get my Cinergy XS (Bus 001 Device 010: ID 0ccd:0043 TerraTec Electronic GmbH) to run in a 2.6.32 RC3 gentoo system? When I use the in-kernel driver I'll get the following output: usb 1-1: new high speed USB device using ehci_hcd and address 10 usb 1-1: configuration #1 chosen from 1 choice em28xx: New device TerraTec Electronic GmbH Cinergy T USB XS @ 480 Mbps (0ccd:0043, interface 0, class 0) em28xx #0: chip ID is em2870 em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 43 00 c0 12 81 00 6a 24 8e 34 em28xx #0: i2c eeprom 10: 00 00 06 57 02 0c 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 01 00 00 00 00 00 5b 00 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 ee 2d 46 4a 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 24 03 43 00 69 00 em28xx #0: i2c eeprom 70: 6e 00 65 00 72 00 67 00 79 00 20 00 54 00 20 00 em28xx #0: i2c eeprom 80: 55 00 53 00 42 00 20 00 58 00 53 00 00 00 34 03 em28xx #0: i2c eeprom 90: 54 00 65 00 72 00 72 00 61 00 54 00 65 00 63 00 em28xx #0: i2c eeprom a0: 20 00 45 00 6c 00 65 00 63 00 74 00 72 00 6f 00 em28xx #0: i2c eeprom b0: 6e 00 69 00 63 00 20 00 47 00 6d 00 62 00 48 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x339064dc em28xx #0: EEPROM info: em28xx #0: No audio on board. em28xx #0: 500mA max power em28xx #0: Table at 0x06, strings=0x246a, 0x348e, 0x em28xx #0: Identified as Terratec Cinergy T XS (card=43) em28xx #0: em28xx #0: The support for this board weren't valid yet. em28xx #0: Please send a report of having this working em28xx #0: not to V4L mailing list (and/or to other addresses) Chip ID is not zero. It is not a TEA5767 tuner 0-0060: chip found @ 0xc0 (em28xx #0) xc2028 0-0060: creating new instance xc2028 0-0060: type set to XCeive xc2028/xc3028 tuner usb 1-1: firmware: requesting xc3028-v27.fw xc2028 0-0060: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 0-0060: Loading firmware for type=BASE (1), id . xc2028 0-0060: Loading firmware for type=(0), id b700. SCODE (2000), id b700: xc2028 0-0060: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. xc2028 0-0060: Incorrect readback of firmware version. xc2028 0-0060: Loading firmware for type=BASE (1), id . xc2028 0-0060: Loading firmware for type=(0), id b700. SCODE (2000), id b700: xc2028 0-0060: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. xc2028 0-0060: Incorrect readback of firmware version. em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 video device registered as /dev/video1 No /dev/dvb, so no DVT-T. I tried to use the latest v4l-dvb but I can't compile it: /root/v4l-dvb/v4l/dvbdev.c: In function 'init_dvbdev': /root/v4l-dvb/v4l/dvbdev.c:516: error: 'struct class' has no member named 'nodename' make[3]: *** [/root/v4l-dvb/v4l/dvbdev.o] Error 1 make[2]: *** [_module_/root/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.32-rc3' make[1]: *** [default] Error 2 make[1]: Leaving directory `/root/v4l-dvb/v4l' make: *** [all] Error 2 Any help is appreciated! Thanks, Michael Hello Michael, Don't bother trying to compile the latest v4l-dvb code. It's not supported even in the latest code (and there is presently no work going on to add support). Devin Hi Devin, thanks for the info. I'll keep waiting and hoping :) Just a quick addition. With 2.6.30 an em28xx-new it runs an the dmesg output looks like this: usb 1-1: new high speed USB device using ehci_hcd and address 14 usb 1-1: configuration #1 chosen from 1 choice em28xx v4l2 driver version 0.0.1 loaded em28xx: new video device (0ccd:0043): interface 0, class 255 em28xx: device is attached to a USB 2.0 bus em28xx #0: Alternate settings: 8 em28xx #0: Alternate setting 0, max size= 0 em28xx #0: Alternate setting 1, max size= 0 em28xx #0: Alternate setting 2, max size= 1448 em28xx #0: Alternate setting 3, max size= 2048 em28xx #0: Alternate setting 4, max size= 2304 em28xx #0: Alternate setting 5, max size= 2580 em28xx #0: Alternate setting 6, max size= 2892 em28xx #0: Alternate setting 7, max size= 3072 em28xx-video.c:
bttv/msp3400 and hibernation
I'm having analog capture card based on bt878. It works without any major problems. However there is some annoying bug with the msp3400 module (this is audio decoding chip on the card, used to decode stereo sound) when using the build-in kernel hibernation. After resume the kernel module spills some I/O Errors and no audio could be heard. The workaround is simple, remove and modprobe the bttv module. If somebody have idea how to further debug problem, please provide instructions. For now I attach full system log done by having option bttv debug=10 and option msp3400 debug=10 in modprobe.conf . The log is using the latest kernel-2.6.31.3, but this happens with every kernel I've tried so far. msp3400.log.gz Description: GNU Zip compressed data
Re: [PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part2
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. 03/05: cx23885: Add integrated IR subdevice interrupt and notification handling http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=1eb199665dbc 04/05: ir-functions: Export ir_rc5_decode() for use by the cx23885 module http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=55a1e2e8128f 05/05: cx23885: Add IR input keypress handling and enable for the HVR-1850 http://linuxtv.org/hg/~awalls/cx23888-ir-part2?cmd=changeset;node=b05a093688a2 b/linux/drivers/media/video/cx23885/cx23885-input.c | 422 +++ b/linux/drivers/media/video/cx23885/cx23885-input.h | 30 b/linux/drivers/media/video/cx23885/cx23885-ir.c| 128 ++ b/linux/drivers/media/video/cx23885/cx23885-ir.h| 36 linux/drivers/media/common/ir-functions.c |3 linux/drivers/media/video/cx23885/Makefile |4 linux/drivers/media/video/cx23885/cx23885-cards.c | 23 linux/drivers/media/video/cx23885/cx23885-core.c| 84 + linux/drivers/media/video/cx23885/cx23885-ir.c |4 linux/drivers/media/video/cx23885/cx23885-reg.h |5 linux/drivers/media/video/cx23885/cx23885.h | 13 linux/drivers/media/video/cx23885/cx23888-ir.c | 1139 +++- linux/include/media/ir-common.h |1 linux/include/media/v4l2-subdev.h | 94 + 14 files changed, 1932 insertions(+), 54 deletions(-) This is the remainder of the changes required to get IR Rx input keypress handling working for the HVR-1850. This builds upon my previous pull request for my cx23888-ir-part1 repo, which include Steven's patch. (This cx23888-ir-part2 repo also has all the patches in the cx23888-ir-part1 repo.) The changes to v4l2-subdev.h include the struct v4l2_subdev_ir_ops definition that Hans had OK'ed in previous e-mails plus a few other defines I felt needed to be common eventually. When both this and the previous pull request are merged, I can then work on IR support for CX23885 and CX23418 cards that use essentially the same integrated IR controller. Thanks, Andy 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: [PATCH] AVerTV MCE 116 Plus radio
On Sun, 2009-10-11 at 04:01 +0300, Aleksandr V. Piskunov wrote:
On Tue, Oct 06, 2009 at 11:11:59AM +0300, Aleksandr V. Piskunov wrote:
On Tue, Oct 06, 2009 at 11:04:06AM +0300, Aleksandr V. Piskunov wrote:
Added FM radio support to Avermedia AVerTV MCE 116 Plus card
What leaves me puzzled, radio only works ok with ivtv newi2c=1
With default newi2c audio is tinny, metallic, with some strange static.
Similar problem with pvr-150 was reported years ago, guess issue is still
unresolved, perhaps something with cx25840..
This particular tinny audio problem is definitely I2C speed related, to be
more precise, audio only goes bad if i2c-algo-bit is being run with udelay
less than 15, i.e. i2c bus frequency is higher than 30 KHz.
So with default udelay=10 or udelay=5 (optimal for IR reciever on that board)
radio goes bad. Running with newi2c=1 is ok, but again it isn't optimal for IR
reciever on AVerTV M116.
I2C reads/writes to cx25840 themself are ok, verified using register readback
after each write/write4. Problem seems to be that with cx25840 register writes
coming too fast on higher i2c bus speed, switching register 0x808 _from_
TV standard autodetection mode (0xff) _to_ FM radio mode (0xf9) leaves chip
audio detection routine in inconsistent state.
The only solution I found is to do standard routine (assert_reset + write +
deassert_reset) followed by 50ms delay and another reset.
Following patch works_for_me, can be improved to only delay/doublereset when
really needed, etc. Andy, could you comment/review?
Aleksandr,
I will when I get time. This past week and next few weeks are very busy
for me for personal (non-linux) reasons. I'll try to get caught up with
the patches I still have to rework and then look at this.
Obviously, your patch is fairly straightforward and looks OK. I just
haven't checked for any implications. The general tinny audio problem
with the CX25840 on ivtv boards is *always* resolved with an audio
microcontroller reset.
The problem is the microcontroller may restart its detection loop and
tinny audio may return. Can you run FM radio for a long time (a day ?),
and see if it ever goes back to tinny audio?
Regards,
Andy
diff --git a/linux/drivers/media/video/cx25840/cx25840-core.c
b/linux/drivers/media/video/cx25840/cx25840-core.c
--- a/linux/drivers/media/video/cx25840/cx25840-core.c
+++ b/linux/drivers/media/video/cx25840/cx25840-core.c
@@ -626,7 +642,13 @@
if (state-radio) {
cx25840_write(client, 0x808, 0xf9);
cx25840_write(client, 0x80b, 0x00);
- }
+ /* Double reset cx2384x after setting FM radio mode, helps to
+avoid tinny audio when ivtv I2C bus is being run on
+frequency higher than 30 KHz */
+ cx25840_and_or(client, 0x810, ~0x01, 0);
+ msleep(50);
+ cx25840_and_or(client, 0x810, ~0x01, 1);
+ }
else if (std V4L2_STD_525_60) {
/* Certain Hauppauge PVR150 models have a hardware bug
that causes audio to drop out. For these models the
--
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
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. 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. 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. 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: [RESEND PULL] http://udev.netup.ru/hg/v4l-dvb-aospan
Hello Mauro, On Friday 09 October 2009 16:01:58 Mauro Carvalho Chehab wrote: Wouldn't be be better to just use dvbtraffic userspace apps for it? this feature very usable for debugging. Please add it. Also, your patch has some coding style issues. please point to this issues. I will fix. Em Thu, 24 Sep 2009 18:41:08 +0400 Abylai Ospan aos...@netup.ru escreveu: Mauro, Please pulll changes from: http://udev.netup.ru/hg/v4l-dvb-aospan/rev/711d9630876f Show speed of transport stream in Kbit/sec: for example, data obtained from DVB-S2 transponder from Eutelsat W4: Jun 27 12:06:01 udev TS speed 58608 Kbits/sec Jun 27 12:06:03 udev TS speed 58422 Kbits/sec Jun 27 12:06:04 udev TS speed 58608 Kbits/sec for DVB-S1 transponder from the same satellite: Jun 27 12:07:00 udev TS speed 37108 Kbits/sec Jun 27 12:07:02 udev TS speed 37089 Kbits/sec Jun 27 12:07:04 udev TS speed 37202 Kbits/sec this feature can be enabled using following command: echo 1 /sys/module/dvb_core/parameters/dvb_demux_speedcheck and disabled by following command: echo 0 /sys/module/dvb_core/parameters/dvb_demux_speedcheck 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 -- 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: No sound in television with Leadtek Winfast USB II Deluxe
2009/10/11 Magnus Alm magnus@gmail.com:
Hi!
I've been pooking around to get my Leadtek Winfast USB II Deluxe
working in Ubuntu 9.10 (kernel 2.6.31-12-generic).
The code for the drivers is collected with:
hg clone http://linuxtv.org/hg/v4l-dvb
So far, in television mode, I can tune channels and get picture. But I
have no sound.
In Composite mode I have picture and sound, altho it's just black and
white. (Might depend on my source tho, I haven't put that much time
into it.)
In Svideo mode I have sound and color picture, so thats OK.
To get any sound in tvtime or Xawttv, I have to run sox -r 48000 -c 2
-t ossdsp /dev/dsp1 -t ossdsp /dev/dsp in a terminal. Only works with
Composite/Svideo.
The changes I've made to make it work so far is the following:
em28xx-cards.c
{ USB_DEVICE(0x0413, 0x6023),
.driver_info = EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE },
Just for my own convenience, otherwise it finds the
LEADTEK_WINFAST_USBII device instead, I got bored with doing modprobe
em28xx card=28 ;-p.
[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,
.decoder = EM28XX_SAA711X,
.input = { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = SAA7115_COMPOSITE4,
*/ Was SAA7115_COMPOSITE2 originally */
.amux = EM28XX_AMUX_VIDEO,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = SAA7115_COMPOSITE5,
*/ Was SAA7115_COMPOSITE0 originally */
.amux = EM28XX_AMUX_LINE_IN,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = SAA7115_SVIDEO3,
*/ Was SAA7115_COMPOSITE0 originally
*/
.amux = EM28XX_AMUX_LINE_IN,
} },
saa7115.c
R_08_SYNC_CNTL, 0x28, /* 0xBO: auto detection, 0x68 = NTSC */
Changed it from 0x68, so I don't have to switch back to PAL after
switching input mode. Just for my own convenience.
When I was searching the internet for information about getting my usb
tv tuner working, I came across this thread.
http://thread.gmane.org/gmane.linux.drivers.em28xx/97/focus=124
(Cut from the post where the poster got working picture and audio.
After snooping the device in Windows and parsing the output with
parser.pl, then playing around with Usbreplay (a tool I don't have
access to tho, and he was using a em28xx-new build.))
This line made the video appear:
000385: OUT: 01 ms 005258 ms 40 02 00 00 42 00 02 00 02 c4
And this worked for audio:
000895: OUT: 00 ms 006684 ms 40 00 00 00 42 00 01 00 16
This line made both usb audio and jack audio output of the device work :)
The video output I fixed with .vmux = SAA7115_COMPOSITE4, .
After snooping my device in windows, just swapping between
television/Composite/Svideo, I didn't get any line with:
40 00 00 00 42 00 01 00 16
The only comparable output I found from my snooping is:
40 00 00 00 42 00 01 00 02
(Might be because we didn't use the same drivers in Windows, default
the installation program installs the drivers for Winfast TV USB II,
doh!.)
When loading em28xx with reg_debug=1 and doing the same swapping
between input modes, as I did in windows, with tvtime or xawtv.
I got the following lines in syslog containing 40 00 00 00 42 00 01
00 after every input mode switch.
[ 2548.560012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 02
[ 2548.584049] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 04
[ 2548.608014] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 06
[ 2548.632012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 36
[ 2548.656012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 38
[ 2548.732012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 14
[ 2548.756012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 10
[ 2548.780012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 0c
[ 2548.804013] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 0e
[ 2548.828012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 12
[ 2548.852013] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 16
[ 2548.876012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 18
[ 2548.900012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 26
[ 2548.924009] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 2a
[ 2548.948012] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 32
[ 2548.972013] (pipe 0x8600): OUT: 40 00 00 00 42 00 01 00 02
This might not be the source of my problem, since it both starts and
ends with 02, but the em28xx driver seems to be unnecessarily
chatty to me.
There is much more difference's between the logs than that tho, added
examples from each log as attachments,
Re: 2.6.32 dvbdev error / Cinergy XS [0ccd:0043]
On Sun, Oct 11, 2009 at 4:06 AM, Michael G miga_m...@gmx.de wrote: Am Samstag, 10. Oktober 2009 23:48:37 schrieb Devin Heitmueller: On Sat, Oct 10, 2009 at 4:19 PM, Michael G miga_m...@gmx.de wrote: Hi, can someone please help me to get my Cinergy XS (Bus 001 Device 010: ID 0ccd:0043 TerraTec Electronic GmbH) to run in a 2.6.32 RC3 gentoo system? When I use the in-kernel driver I'll get the following output: usb 1-1: new high speed USB device using ehci_hcd and address 10 usb 1-1: configuration #1 chosen from 1 choice em28xx: New device TerraTec Electronic GmbH Cinergy T USB XS @ 480 Mbps (0ccd:0043, interface 0, class 0) em28xx #0: chip ID is em2870 em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 43 00 c0 12 81 00 6a 24 8e 34 em28xx #0: i2c eeprom 10: 00 00 06 57 02 0c 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 01 00 00 00 00 00 5b 00 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 ee 2d 46 4a 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 24 03 43 00 69 00 em28xx #0: i2c eeprom 70: 6e 00 65 00 72 00 67 00 79 00 20 00 54 00 20 00 em28xx #0: i2c eeprom 80: 55 00 53 00 42 00 20 00 58 00 53 00 00 00 34 03 em28xx #0: i2c eeprom 90: 54 00 65 00 72 00 72 00 61 00 54 00 65 00 63 00 em28xx #0: i2c eeprom a0: 20 00 45 00 6c 00 65 00 63 00 74 00 72 00 6f 00 em28xx #0: i2c eeprom b0: 6e 00 69 00 63 00 20 00 47 00 6d 00 62 00 48 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x339064dc em28xx #0: EEPROM info: em28xx #0: No audio on board. em28xx #0: 500mA max power em28xx #0: Table at 0x06, strings=0x246a, 0x348e, 0x em28xx #0: Identified as Terratec Cinergy T XS (card=43) em28xx #0: em28xx #0: The support for this board weren't valid yet. em28xx #0: Please send a report of having this working em28xx #0: not to V4L mailing list (and/or to other addresses) Chip ID is not zero. It is not a TEA5767 tuner 0-0060: chip found @ 0xc0 (em28xx #0) xc2028 0-0060: creating new instance xc2028 0-0060: type set to XCeive xc2028/xc3028 tuner usb 1-1: firmware: requesting xc3028-v27.fw xc2028 0-0060: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 0-0060: Loading firmware for type=BASE (1), id . xc2028 0-0060: Loading firmware for type=(0), id b700. SCODE (2000), id b700: xc2028 0-0060: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. xc2028 0-0060: Incorrect readback of firmware version. xc2028 0-0060: Loading firmware for type=BASE (1), id . xc2028 0-0060: Loading firmware for type=(0), id b700. SCODE (2000), id b700: xc2028 0-0060: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. xc2028 0-0060: Incorrect readback of firmware version. em28xx #0: v4l2 driver version 0.1.2 em28xx #0: V4L2 video device registered as /dev/video1 No /dev/dvb, so no DVT-T. I tried to use the latest v4l-dvb but I can't compile it: /root/v4l-dvb/v4l/dvbdev.c: In function 'init_dvbdev': /root/v4l-dvb/v4l/dvbdev.c:516: error: 'struct class' has no member named 'nodename' make[3]: *** [/root/v4l-dvb/v4l/dvbdev.o] Error 1 make[2]: *** [_module_/root/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.32-rc3' make[1]: *** [default] Error 2 make[1]: Leaving directory `/root/v4l-dvb/v4l' make: *** [all] Error 2 Any help is appreciated! Thanks, Michael Hello Michael, Don't bother trying to compile the latest v4l-dvb code. It's not supported even in the latest code (and there is presently no work going on to add support). Devin Hi Devin, thanks for the info. I'll keep waiting and hoping :) Just a quick addition. With 2.6.30 an em28xx-new it runs an the dmesg output looks like this: usb 1-1: new high speed USB device using ehci_hcd and address 14 usb 1-1: configuration #1 chosen from 1 choice em28xx v4l2 driver version 0.0.1 loaded em28xx: new video device (0ccd:0043): interface 0, class 255 em28xx: device is attached to a USB 2.0 bus em28xx #0: Alternate settings: 8 em28xx #0: Alternate setting 0, max size= 0 em28xx #0: Alternate setting 1, max size= 0 em28xx #0: Alternate setting 2, max size= 1448 em28xx #0: Alternate setting 3, max size= 2048 em28xx #0: Alternate setting 4, max size= 2304 em28xx #0: Alternate setting 5, max size= 2580 em28xx #0: Alternate setting
Very busy for the next several weeks...
Hi all, You may have noticed very little activity from me lately: this is due to a lot of traveling and a very busy work schedule. This will continue until early November at least. So if you do not get an answer to a question, then that's why. I will try my utmost to do any reviews related to the new APIs discussed during the v4l-dvb mini-summit in Portland. I've started that, after all. One exception will probably be the memory pool discussions: that is not my area of expertise so I doubt I can contribute much there. Note that even though I have more time in November, I really want to use that time to continue work on the control framework, so whether I will have much time to do anything else is doubtful as well. And December will almost certainly be very busy again... My apologies for the ivtv users: I'm pretty certain that's on hold for the rest of the year (not that there was much going on and I hope Andy can help out there). The new SoC support being discussed and worked on will be pretty much the only thing I'll be paying attention to for now. Just so you all know what to expect... Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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
Dazzle TV Hybrid USB and em28xx
Hello to everyone, I bought a Dazzle TV Hybrid USB stick some years ago (2006 maybe?) and until now I've used out of kernel drivers from M. Rechberger. Here's a webpage about the stick http://www.lelong.com.my/Auc/List/2009-10DeStd44780009_AUCTION_-# Dazzle-TV-Hybrid-USB-stick-Watch-TV-without-Internet-BID-Now.htm (this line has been breaked at the sharp # sign) The usbid is eb1a:2881. The Linux distribution I'm using, Archlinux, has updated the kernel to 2.6.31.3 and I've failed to patch the out of kernel drivers again, so I've tried the in kernel em28xx modules. These are the results: when I plug the stick em28xx and em28xx-dvb get loaded by the kernel, I think the stick is recognized as card=53 (Pinnacle Hybrid Pro), and the /dev/videoX, /dev/dspX, /dev/vbiX and /dev/dvb/adapterX devices are created. But analog TV has no audio (I've tried sox/arecord-aplay), teletext doesn't work (mtt segfaults) and DVB doesn't work too. With me-tv I get an error message like Failed to tune to channel and sometimes a timeout. Searching this mailing list I've found a way to get at least DVB working (thanks to Emanuele Deiola) 1) remove em28xx-dvb and em28xx modules if these are already loaded; 2) plug the stick (the kernel loads em28xx and em28xx-dvb); 3) remove em28xx-dvb and em28xx modules # modprobe -r em28xx-dvb # modprobe -r em28xx 4) load em28xx with card=11 # modprobe em28xx card=11 and DVB works, i.e. me-tv, vlc, w_scan work as expected. Analog TV is still without audio, video is OK. I've tried to add the option card=11 in modprobe.conf but the result is that the /dev/dvb/adapterX directory is not created. I hope this is helpful for other people with this stick and to the developers to enhance support for the stick. Please developers let me know if you need more info. -- 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 Oct 11 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13095:5578cc977a13 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/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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: Dazzle TV Hybrid USB and em28xx
Hello Giuseppe, On Sun, Oct 11, 2009 at 12:38 PM, Giuseppe Borzi gbo...@gmail.com wrote: Hello to everyone, I bought a Dazzle TV Hybrid USB stick some years ago (2006 maybe?) and until now I've used out of kernel drivers from M. Rechberger. Here's a webpage about the stick http://www.lelong.com.my/Auc/List/2009-10DeStd44780009_AUCTION_-# Dazzle-TV-Hybrid-USB-stick-Watch-TV-without-Internet-BID-Now.htm (this line has been breaked at the sharp # sign) The usbid is eb1a:2881. The Linux distribution I'm using, Archlinux, has updated the kernel to 2.6.31.3 and I've failed to patch the out of kernel drivers again, so I've tried the in kernel em28xx modules. Make sure you have the latest v4l-dvb code installed. The changes for that board went in relatively recently (make sure you do *not* specify a card= modprobe parameter). http://linuxtv.org/repo But analog TV has no audio (I've tried sox/arecord-aplay), Make sure you have the correct standard selected. This sort of thing often occurs when you are in an area with PAL support but you have the device configured for NTSC. teletext doesn't work (mtt segfaults) and DVB doesn't work too. Teletext is not supported currently - I did the NTSC VBI support and am planning on doing the PAL support in the next couple of weeks. With me-tv I get an error message like Failed to tune to channel and sometimes a timeout. A fix for this was done this week (but hasn't been checked in yet). Check the linux-media archive for the PCTV 320e thread. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Haupp. HVR-1100 problem and DVB-T card
Hi Hermann Hi Fabio, Am Donnerstag, den 08.10.2009, 20:02 + schrieb fabio tirapelle: Hi 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 did send to those likely interested too and might be able to give better advice. Two questions 1) But the Haupp. WinTV will not be found even if I have followed http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1110 http://ubuntuforums.org/showthread.php?t=623126page=2 (#12) Output of dmesg [ 13.062214] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 17 [ 13.062223] b2c2_flexcop_pci :01:06.0: PCI INT A - Link[LNKA] - GSI 17 (level, low) - IRQ 17 [ 13.076654] DVB: registering new adapter (FlexCop Digital TV device) [ 13.078432] b2c2-flexcop: MAC address = 00:d0:d7:0d:30:88 [ 13.078664] b2c2-flexcop: i2c master_xfer failed [ 13.078893] b2c2-flexcop: i2c master_xfer failed [ 13.078895] CX24123: cx24123_i2c_readreg: reg=0x0 (error=-121) [ 13.078897] CX24123: wrong demod revision: 87 [ 13.101063] saa7130/34: v4l2 driver version 0.2.14 loaded [ 13.360642] b2c2-flexcop: found 'ST STV0299 DVB-S' . [ 13.360647] DVB: registering frontend 0 (ST STV0299 DVB-S)... [ 13.360768] b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 DVB-S' at the 'PCI' bus controlled by a 'FlexCopIIb' complete [ 13.363507] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 16 [ 13.363517] saa7134 :01:07.0: PCI INT A - Link[LNKB] - GSI 16 (level, low) - IRQ 16 [ 13.363523] saa7133[0]: found at :01:07.0, rev: 255, irq: 16, latency: 255, mmio: 0x0 Memory allocation at the PCI bus fails and PCI latency is very high for nothing in the end. [ 13.363528] saa7133[0]: subsystem: :, board: UNKNOWN/GENERIC [card=0,autodetected] Either the eeprom is corrupted, or more likely, this fails because of the previous failing. [ 13.363531] saa7133[0]: can't get MMIO memory @ 0x0 [ 13.363538] saa7134: probe of :01:07.0 failed with error -16 [ 13.393682] saa7134 ALSA driver for DMA sound loaded [ 13.393685] saa7134 ALSA: no saa7134 cards found ouput lspci 01:06.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02) 01:07.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1) 2) What kind of DVB-T card will you suggest for my configuration instead of Hauppage WinTv? We have some unknowns on the various Hauppauge 1110s, but in general they are assumed to be well supported. They are all auto eeprom detectable and only for latest revisions you need some latest mercurial v4l-dvb. These look good now too. Could you try again with the HVR1110 as the only PCI card? I have tried without success If this still fails, the mobo seems not to be best treated anyway too, I would guess the card is broken. What kind of mobo do you suggest? If necessary I can buy a new mobo Cheers, Hermann Thanks 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: [Linux-uvc-devel] [PATCH] Re: uvcvideo: Finally fix Logitech Quickcam for Notebooks Pro
Hi Ondrej, On Friday 09 October 2009 08:32:06 Ondrej Zary wrote: On Friday 09 October 2009, Laurent Pinchart wrote: Hi Ondrej, On Wednesday 07 October 2009 14:59:40 Ondrej Zary wrote: On Tuesday 06 October 2009, Ondrej Zary wrote: Hello, I have a Logitech Quickcam for Notebooks Pro camera (046d:08c3) which just does not work even with kernel 2.6.31 and has never worked well before. On http://linux-uvc.berlios.de/, there are two problems listed. I want to really fix these two problems so the camera will just work after plugging in (and not disconnect). I started with problem no. 2 as this causes the camera not to work at all when plugged in: usb 5-2.4: new high speed USB device using ehci_hcd and address 7 usb 5-2.4: configuration #1 chosen from 1 choice uvcvideo: Found UVC 1.00 device unnamed (046d:08c3) uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 26). uvcvideo: Failed to initialize the device (-5). When I do modprobe snd_usb_audio, then rmmod snd_usb_audio and finally modprobe uvcvideo, it works. So it looks like snd_usb_audio does some initialization that allows uvcvideo to work. It didn't work at all I didn't have snd_usb_audio module compiled. What was the change that supposedly broke this in 2.6.22? I discovered that it's not related to usb audio at all. Doing rmmod uvcvideo and modprobe uvcvideo repeatedly succeeded after a couple of tries. Increasing UVC_CTRL_STREAMING_TIMEOUT to 3000 helped (2000 was not enough). Increase UVC_CTRL_STREAMING_TIMEOUT to fix initialization of Logitech Quickcam for Notebooks Pro. This fixes following error messages: uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 26). uvcvideo: Failed to initialize the device (-5). Signed-off-by: Ondrej Zary li...@rainbow-software.org --- linux-2.6.31-orig/drivers/media/video/uvc/uvcvideo.h 2009-09-10 00:13:59.0 +0200 +++ linux-2.6.31/drivers/media/video/uvc/uvcvideo.h 2009-10-07 13:47:27.0 +0200 @@ -304,7 +304,7 @@ #define UVC_MAX_STATUS_SIZE 16 #define UVC_CTRL_CONTROL_TIMEOUT 300 -#define UVC_CTRL_STREAMING_TIMEOUT 1000 +#define UVC_CTRL_STREAMING_TIMEOUT 3000 /* Devices quirks */ #define UVC_QUIRK_STATUS_INTERVAL0x0001 Thanks for the patch. I wonder if it will help other Logitech users. The UVC specification unfortunately doesn't give a time boundary for answering streaming requests, so that's up to the developers. I'm pretty sure we will find at least one webcam model that will require 3001ms at some point :-) I was thinking about adding a module parameter to set the streaming control timeout. I'm not sure what the default value should be though. What's your opinion on this ? If we decide to increase the default value, where should we stop ? I really don't know. Maybe only the first request is slow as the hardware needs some time to initialize? That's my guess as well. If someone knows what value is used by Windows or Mac OS X, that's probably the right choice as most devices are tested with them. I've committed a patch that turns the timeout value into a module parameter and asked Mauro to pull from my repository. The default timeout value has been increased to 3000ms. It seems the value used by the Windows driver is 5000ms. I have no information about what's done on Mac OS X. If it works with 3000ms lets keep it that way. I wouldn't be surprised if the 5000ms was some kind of rounded-up guessed value anyway :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Very busy for the next several weeks...
Hi Hans, On Sunday 11 October 2009 18:02:42 Hans Verkuil wrote: Hi all, You may have noticed very little activity from me lately: this is due to a lot of traveling and a very busy work schedule. This will continue until early November at least. So if you do not get an answer to a question, then that's why. I will try my utmost to do any reviews related to the new APIs discussed during the v4l-dvb mini-summit in Portland. I've started that, after all. One exception will probably be the memory pool discussions: that is not my area of expertise so I doubt I can contribute much there. I've been pretty busy as well since the LPC. The memory pool RFC got delayed a bit (but I've been working on subdev and media-controller related tasks, so my work will hopefully be useful too :-)). Following your discussion I studied the GEM architecture and I'll contact the Intel developers to see if sharing buffers between the GPU and the V4L2 devices could be possible. I'm a bit scared this will be difficult, as GPU memory is accessed through the GART (a kind of IOMMU for GPUs) and we would have to deal with textures tiling and swizzling. Note that even though I have more time in November, I really want to use that time to continue work on the control framework, so whether I will have much time to do anything else is doubtful as well. And December will almost certainly be very busy again... My apologies for the ivtv users: I'm pretty certain that's on hold for the rest of the year (not that there was much going on and I hope Andy can help out there). The new SoC support being discussed and worked on will be pretty much the only thing I'll be paying attention to for now. Just so you all know what to expect... We all have business and personal schedules to deal with. Nobody should expect you or any open-source developer to put life aside and commit 100% to open- source projects (unless funded by a company, but that's another story). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] drivers/media/video/uvc: Use %pUl to print UUIDs
Hi Joe,
On Wednesday 07 October 2009 06:45:38 Joe Perches wrote:
Signed-off-by: Joe Perches j...@perches.com
---
drivers/media/video/uvc/uvc_ctrl.c | 69
--
drivers/media/video/uvc/uvc_driver.c |7 +--
drivers/media/video/uvc/uvcvideo.h | 10 -
3 files changed, 35 insertions(+), 51 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c index c3225a5..4d06976 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -1093,8 +1093,8 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
if (!found) {
uvc_trace(UVC_TRACE_CONTROL,
- Control UVC_GUID_FORMAT /%u not found.\n,
- UVC_GUID_ARGS(entity-extension.guidExtensionCode),
+ Control %pUl/%u not found.\n,
+ entity-extension.guidExtensionCode,
xctrl-selector);
return -EINVAL;
}
@@ -1171,9 +1171,9 @@ int uvc_ctrl_resume_device(struct uvc_device *dev)
(ctrl-info-flags UVC_CONTROL_RESTORE) == 0)
continue;
- printk(KERN_INFO restoring control UVC_GUID_FORMAT
- /%u/%u\n, UVC_GUID_ARGS(ctrl-info-entity),
- ctrl-info-index, ctrl-info-selector);
+ printk(KERN_INFO restoring control %pUl/%u/%u\n,
+ctrl-info-entity,
+ctrl-info-index, ctrl-info-selector);
ctrl-dirty = 1;
}
@@ -1228,46 +1228,43 @@ static void uvc_ctrl_add_ctrl(struct uvc_device
*dev, dev-intfnum, info-selector, (__u8 *)size, 2);
if (ret 0) {
uvc_trace(UVC_TRACE_CONTROL, GET_LEN failed on
- control UVC_GUID_FORMAT /%u (%d).\n,
- UVC_GUID_ARGS(info-entity), info-selector,
- ret);
+ control %pUl/%u (%d).\n,
+ info-entity, info-selector, ret);
return;
}
if (info-size != le16_to_cpu(size)) {
- uvc_trace(UVC_TRACE_CONTROL, Control UVC_GUID_FORMAT
- /%u size doesn't match user supplied
- value.\n, UVC_GUID_ARGS(info-entity),
- info-selector);
+ uvc_trace(UVC_TRACE_CONTROL,
+ Control %pUl/%u size doesn't match user
supplied value.\n,
+ info-entity, info-selector);
return;
}
ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl-entity-id,
dev-intfnum, info-selector, inf, 1);
if (ret 0) {
- uvc_trace(UVC_TRACE_CONTROL, GET_INFO failed on
- control UVC_GUID_FORMAT /%u (%d).\n,
- UVC_GUID_ARGS(info-entity), info-selector,
- ret);
+ uvc_trace(UVC_TRACE_CONTROL,
+ GET_INFO failed on control %pUl/%u (%d).\n,
+ info-entity, info-selector, ret);
return;
}
flags = info-flags;
if (((flags UVC_CONTROL_GET_CUR) !(inf (1 0))) ||
((flags UVC_CONTROL_SET_CUR) !(inf (1 1 {
- uvc_trace(UVC_TRACE_CONTROL, Control
- UVC_GUID_FORMAT /%u flags don't match
- supported operations.\n,
- UVC_GUID_ARGS(info-entity), info-selector);
+ uvc_trace(UVC_TRACE_CONTROL,
+ Control %pUl/%u flags don't match supported
operations.\n,
+ info-entity, info-selector);
return;
}
}
ctrl-info = info;
ctrl-data = kmalloc(ctrl-info-size * UVC_CTRL_NDATA, GFP_KERNEL);
- uvc_trace(UVC_TRACE_CONTROL, Added control UVC_GUID_FORMAT /%u
- to device %s entity %u\n, UVC_GUID_ARGS(ctrl-info-entity),
- ctrl-info-selector, dev-udev-devpath, entity-id);
+ uvc_trace(UVC_TRACE_CONTROL,
+ Added control %pUl/%u to device %s entity %u\n,
+ ctrl-info-entity, ctrl-info-selector,
+ dev-udev-devpath, entity-id);
}
/*
@@ -1293,17 +1290,16 @@ int uvc_ctrl_add_info(struct uvc_control_info
*info) continue;
if (ctrl-selector == info-selector) {
- uvc_trace(UVC_TRACE_CONTROL, Control
- UVC_GUID_FORMAT /%u is already
Re: [PATCH] v4l2_subdev: rename tuner s_standby operation to core s_power
On Monday 05 October 2009 15:48:17 Laurent Pinchart wrote: Upcoming I2C v4l2_subdev drivers need a way to control the subdevice power state from the core. This use case is already partially covered by the tuner s_standby operation, but no way to explicitly come back from the standby state is available. Rename the tuner s_standby operation to core s_power, and fix tuner drivers accordingly. The tuner core will call s_power(0) instead of s_standby(). No explicit call to s_power(1) is required for tuners as they are supposed to wake up from standby automatically. Mauro, Hans told me he didn't see anything wrong with this patch. As there's no negative feedback so far (but unfortunately no positive feedback either) can it be applied ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2_subdev: rename tuner s_standby operation to core s_power
On Monday 12 October 2009 00:36:37 Laurent Pinchart wrote: On Monday 05 October 2009 15:48:17 Laurent Pinchart wrote: Upcoming I2C v4l2_subdev drivers need a way to control the subdevice power state from the core. This use case is already partially covered by the tuner s_standby operation, but no way to explicitly come back from the standby state is available. Rename the tuner s_standby operation to core s_power, and fix tuner drivers accordingly. The tuner core will call s_power(0) instead of s_standby(). No explicit call to s_power(1) is required for tuners as they are supposed to wake up from standby automatically. Mauro, Hans told me he didn't see anything wrong with this patch. As there's no negative feedback so far (but unfortunately no positive feedback either) can it be applied ? Just in case anyone wants it: Signed-off-by: Hans Verkuil hverk...@xs4all.nl This came out of discussions during the LPC and it's a good change. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: Media controller: sysfs vs ioctl
On Monday 21 September 2009 19:23:54 Sakari Ailus wrote: Hans Verkuil wrote: On Sunday 13 September 2009 08:13:04 Nathaniel Kim wrote: 2009. 9. 12., 오전 7:21, Hans Verkuil 작성: Hans, First of all I'm very sorry that I had not enough time to go through your new RFC. I'll checkout right after posting this mail. I think this is a good approach and I also had in my mind that sysfs might be a good method if we could control and monitor through this. Recalling memory when we had a talk in San Francisco, I was frustrated that there is no way to catch events from sort of sub-devices like lens actuator (I mean pizeo motors in camera module). As you know lens actuator is an extremely slow device in comparison with common v4l2 devices we are using and we need to know whether it has succeeded or not in moving to expected position. So I considered sysfs and udev as candidates for catching events from sub-devices. events like success/failure of lens movement, change of status of subdevices. Does anybody experiencing same issue? I think I've seen a lens controller driver in omap3 kernel from TI but not sure how did they control that. My point is that we need a kind of framework to give and event to user space and catching them properly just like udev does. When I was talking to Laurent Pinchart and Sakari and his team at Nokia we discussed just such a framework. It actually exists already, although it is poorly implemented. Look at include/linux/dvb/video.h, struct video_event and ioctl VIDEO_GET_EVENT. It is used in ivtv (ivtv-ioctl.c, look for VIDEO_GET_EVENT). The idea is that you can either call VIDEO_GET_EVENT to wait for an event or use select() and wait for an exception to arrive, and then call VIDEO_GET_EVENT to find which event it was. This is ideal for streaming-related events. In ivtv it is used to report VSYNCs and to report when the MPEG decoder stopped (there is a delay between stopping sending new data to the decoder and when it actually processed all its internal buffers). Laurent is going to look into this to clean it up and present it as a new proper official V4L2 event mechanism. For events completely specific to a subdev I wonder whether it wouldn't be a good idea to use the media controller device for that. I like the select() mechanism since in an application you can just select() on a whole bunch of filehandles. If you can't use select() then you are forced to do awkward coding (e.g. make a separate thread just to handle that other event mechanism). Agree. There's no reasonable way to use video devices here since the events may be connected to non-video related issues --- like the statistics. One possible approach could be allocating a device node for each subdev and use them and leave the media controller device with just the media controller specific ioctls. Then there would be no need to set current subdev nor bind the subdev to file handle either. Just an idea. So with the media controller we can easily let sub-devices notify the media controller when an event is ready and the media controller can then generate an exception. An application can just select() on the mc filehandle. There are two ways of implementing this. One is that the media controller keeps a global queue of pending events and subdevices just queue events to that when they arrive (with some queue size limit to prevent run-away events). With the above arrangement, the events could be easily subdev specific. The mechanism should be generic still, though. So when you call some GET_EVENT type ioctl it should return the ID of the subdevice (aka entity) as well. What makes me slightly uncomfortable is that you still want to use that same ioctl on a normal video node. And the subdev ID has really no meaning there. But making two different ioctls doesn't sit well with me either. The alternative implementation is that the mc will only wait for events from the currently selected sub-device. So if you want to wait on events from different sub-devices, then you have to open the mc multiple times, once for each subdev that you want to receive events from. I think I would probably go for the second implementation because it is consistent with the way ioctls are passed to sub-devices. I like the idea that you can just pass regular V4L2 ioctls to sub-devices. Not all ioctls make sense, obviously (e.g. any of the streaming I/O ioctls), but a surprisingly large number of ioctls can be used in that way. I agree with this. There are just a few ioctls that probably don't make sense (e.g. the steaming related ones). IMO even the format setting ioctls could be nice since the possible input and output formats of the subdevs should be enumerable, too. ENUM_FRAMESIZES and ENUM_FRAMEINTERVALS are missing the v4l2_buf_type, but there are reserved fields... Those two
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-20091011
Mauro: Please from http://linuxtv.org/hg/~mcisely/pvrusb2-20091011 for a few various pvrusb2 fixes / improvements. No critical bug fixes here, just a bunch of little things: - pvrusb2: Make more info available to udev - pvrusb2: Soften encoder warning message - pvrusb2: Improve diagnostic info on driver initialization failure - pvrusb2: Report hardware description to kernel log upon initialization - pvrusb2: Add hardware description to debuginfo output - pvrusb2: Fix redundant message on driver initialization failure (missing break) - pvrusb2: Cosmetic kernel log tweak pvrusb2-debugifc.c |3 +++ pvrusb2-encoder.c |5 - pvrusb2-hdw-internal.h |1 + pvrusb2-hdw.c | 33 - pvrusb2-v4l2.c | 21 - 5 files changed, 52 insertions(+), 11 deletions(-) -Mike -- Mike Isely isely @ isely (dot) net 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
Gadmei 380 on kernel 2.6.28.4
I am trying to use the gadmei 380 which I bought yesterday. I am using kernel 2.6.28.4, I downloaded the entire ~dougsland/em28xx and did a make and install. Everything went on smoothly. However, when I plug in the gadmei 380 usb device, it seems the driver can get loaded by the usb pnp, but at the same time, one of my usb pendrive will get disconnected. Because that's my boot drive ( I boot off from the usb drive ), that will cause problem with my system. Anyone has experienced this before ? Regards. -- 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
