LV5H clone
Hi, I've a LV5H clone marketed in Italy under Extreme Technology brand which does not work under Ubuntu Jaunty (kernel version 2.6.30 used to solve intel graphics video card performance issue). It is identified by: idVendor=eb1a, idProduct=2883 I tried to use it using the following em28xx.conf (in /etc/modprobe.d directory): options em28xx card=1 in order to use generic 28xx driver; it is attached as /dev/video0 and /dev/vbi0 but tvtime says that it could not recognize video input, xawtv hangs and scantv says that there is no tuner! After modprobe em28xx_dvb (dmesg says succefull initialized...) Kaffeine doesn't recognize it and scan returns a Fatal error /dev/dvb/adapter0 etc... ... There are some chanches to use it under Ubuntu or I've to switch to WXP every time I wish to watch TV? If needed I can run some test ... Thanks in advance, Mimmo -- 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 v2] soc-camera: fix missing clean up on error path
soc-camera: fix missing clean up on error path
If soc_camera_init_user_formats() fails in soc_camera_probe(), we have to call
client's .remove() method to unregister the video device.
Reported-by: Kuninori Morimoto morimoto.kunin...@renesas.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
(please use the new V4L Mailing List)
On Fri, 19 Jun 2009, Kuninori Morimoto wrote:
If soc_camera_init_user_formats() fails in soc_camera_probe(), we have to
call
client's .remove() method to unregister the video device.
Reported-by: Kuninori Morimoto morimoto.kunin...@renesas.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hi Morimoto-san
(snip)
Could you please verify that this patch fixed your problem?
Thank you nice patch.
I tried this, but kernel stoped in boot.
soc_camera_video_stop is called from icd-ops-remove
I think it have dead lock by icd-video_lock.
my kernel is from Paul's git and it's Makefile said 2.6.30-rc6
Yes, you're right. Please, try this version, but this is a bigger change,
also affecting the regular (not error) path, so, I will have to test it
too.
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 78010ab..9f5ae81 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -877,8 +877,11 @@ static int soc_camera_probe(struct device *dev)
(unsigned short)~0;
ret = soc_camera_init_user_formats(icd);
- if (ret 0)
+ if (ret 0) {
+ if (icd-ops-remove)
+ icd-ops-remove(icd);
goto eiufmt;
+ }
icd-height = DEFAULT_HEIGHT;
icd-width = DEFAULT_WIDTH;
@@ -902,8 +905,10 @@ static int soc_camera_remove(struct device *dev)
{
struct soc_camera_device *icd = to_soc_camera_dev(dev);
+ mutex_lock(icd-video_lock);
if (icd-ops-remove)
icd-ops-remove(icd);
+ mutex_unlock(icd-video_lock);
soc_camera_free_user_formats(icd);
@@ -1145,6 +1150,7 @@ evidallocd:
}
EXPORT_SYMBOL(soc_camera_video_start);
+/* Called from client .remove() methods with .video_lock held */
void soc_camera_video_stop(struct soc_camera_device *icd)
{
struct video_device *vdev = icd-vdev;
@@ -1154,10 +1160,8 @@ void soc_camera_video_stop(struct soc_camera_device *icd)
if (!icd-dev.parent || !vdev)
return;
- mutex_lock(icd-video_lock);
video_unregister_device(vdev);
icd-vdev = NULL;
- mutex_unlock(icd-video_lock);
}
EXPORT_SYMBOL(soc_camera_video_stop);
--
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 v2] af9015: avoid magically sized temporary buffer in eeprom_dump
Replace printing to magically sized temporary buffer with use
of KERN_CONT for continual printing of eeprom registers dump.
Since deb_info is defined as dprintk, which is conditionally defined
to printk without additional parameters, meaning that deb_info is equivalent
to direct printk (without adding KERN_ facility), we can use KERN_DEBUG and
KERN_CONT in there, eliminating the need for sprintf into temporary buffer
with not easily readable/magical size.
Though it's strange, that deb_info definition uses printk without KERN_
facility and callers don't use it either.
v2: removed comma after KERN_CONT
Signed-off-by: Jan Nikitenko jan.nikite...@gmail.com
---
I do not see better solution for the magical sized buffer, since
print_hex_dump like functions need dump of registers in memory
(so the magical sized temporary buffer would be needed for a copy anyway).
If deb_info was defined with inside KERN_ facility, then this patch
would not be valid. In that case the magically sized temporary buffer might
be acceptable.
This patch depends on 'af9015: fix stack corruption bug' patch.
On 14:00 Thu 18 Jun , Trent Piepho wrote:
On Thu, 18 Jun 2009, Jan Nikitenko wrote:
+ deb_info(KERN_CONT, --);
No comma after KERN_CONT
Just use printk() instead of deb_info() for the ones that use KERN_CONT.
It's not possible to use printk instead of deb_info just for the ones
that use KERN_CONT, because deb_info not always goes to printk, it depends on
compile time dprintk macro expansion and on runtime configuration of debugging
messages from dvb subsystem.
If printk is used instead of all deb_info calls, this logging would not
be anymore influenced by above mentioned settings for deb_info.
I am not sure if duplicating all conditions of deb_info for direct
printk in there would be any better.
linux/drivers/media/dvb/dvb-usb/af9015.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff -r 722c6faf3ab5 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Wed Jun 17 22:39:23 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Fri Jun 19 09:22:53 2009 +0200
@@ -541,24 +541,22 @@
/* dump eeprom */
static int af9015_eeprom_dump(struct dvb_usb_device *d)
{
- char buf[4+3*16+1], buf2[4];
u8 reg, val;
for (reg = 0; ; reg++) {
if (reg % 16 == 0) {
if (reg)
- deb_info(%s\n, buf);
- sprintf(buf, %02x: , reg);
+ deb_info(KERN_CONT \n);
+ deb_info(KERN_DEBUG %02x:, reg);
}
if (af9015_read_reg_i2c(d, AF9015_I2C_EEPROM, reg, val) == 0)
- sprintf(buf2, %02x , val);
+ deb_info(KERN_CONT %02x, val);
else
- strcpy(buf2, -- );
- strcat(buf, buf2);
+ deb_info(KERN_CONT --);
if (reg == 0xff)
break;
}
- deb_info(%s\n, buf);
+ deb_info(KERN_CONT \n);
return 0;
}
--
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: Leadtek Winfast DTV-1000S
Hi, [9.916022] saa7134 :05:01.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 10.020209] tda10048_firmware_upload: Upload failed. (file not found?) The dvb-fe-tda10048-1.0.fw is needed. You can get it from the following links: http://tw1965.myweb.hinet.net/Linux/firmware.tar.gz http://tw1965.myweb.hinet.net/Linux/Firmware.txt http://tw1965.myweb.hinet.net/ 2009/6/19 James Moschou james.mosc...@gmail.com: OK after adding 'options saa7134 card=156' to /etc/modprobe.d/modprobe.conf it loads correctly, thanks Brad. dmesg: [ 8.438243] Linux video capture interface: v2.00 [ 8.606434] nvidia :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 8.606440] nvidia :01:00.0: setting latency timer to 64 [ 8.607114] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 185.18.14 Wed May 27 01:23:47 PDT 2009 [ 8.626542] input: PC Speaker as /devices/platform/pcspkr/input/input6 [ 8.659879] iTCO_vendor_support: vendor-support=0 [ 8.26] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.05 [ 8.666736] iTCO_wdt: Found a ICH9 TCO device (Version=2, TCOBASE=0x0460) [ 8.666811] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 8.742132] saa7130/34: v4l2 driver version 0.2.15 loaded [ 8.742181] saa7134 :05:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 8.742186] saa7130[0]: found at :05:01.0, rev: 1, irq: 19, latency: 32, mmio: 0xfb002000 [ 8.742191] saa7130[0]: subsystem: 107d:6655, board: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid [card=156,insmod option] [ 8.742214] saa7130[0]: board init: gpio is 22000 [ 8.852862] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [ 8.852908] HDA Intel :00:1b.0: setting latency timer to 64 [ 8.916022] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [ 8.916031] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff ff ff ff ff [ 8.916039] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08 ff 00 8a ff ff ff ff [ 8.916046] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916054] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff 04 ff ff ff ff ff ff [ 8.916062] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916069] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916077] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916085] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916092] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916100] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916108] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916115] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916123] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916131] saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916138] saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.916148] tveeprom 0-0050: Encountered bad packet header [ff]. Corrupt or not a Hauppauge eeprom. [ 8.916150] saa7130[0]: warning: unknown hauppauge model #0 [ 8.916151] saa7130[0]: hauppauge eeprom: model=0 [ 8.980528] Chip ID is not zero. It is not a TEA5767 [ 8.980592] tuner 0-0060: chip found @ 0xc0 (saa7130[0]) [ 9.016010] tda8290: no gate control were provided! [ 9.016080] tuner 0-0060: Tuner has no way to set tv freq [ 9.016086] tuner 0-0060: Tuner has no way to set tv freq [ 9.016171] saa7130[0]: registered device video0 [v4l2] [ 9.016215] saa7130[0]: registered device vbi0 [ 9.016251] saa7130[0]: registered device radio0 [ 9.016387] rt2400pci :05:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [ 9.024385] phy0: Selected rate control algorithm 'pid' [ 9.028685] saa7134 ALSA driver for DMA sound loaded [ 9.028688] saa7130[0]/alsa: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid doesn't support digital audio [ 9.060205] dvb_init() allocating 1 frontend [ 9.093967] Registered led device: rt2400pci-phy0:radio [ 9.093980] Registered led device: rt2400pci-phy0:quality [ 9.150392] lp0: using parport0 (interrupt-driven). [ 9.174892] tda18271 0-0060: creating new instance [ 9.184029] TDA18271HD/C1 detected @ 0-0060 [ 9.211513] Adding 6024332k swap on /dev/sda5. Priority:-1 extents:1 across:6024332k [ 9.588014] DVB: registering new adapter (saa7130[0]) [ 9.588018] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)... [ 9.739258] EXT4 FS on sda1, internal journal on sda1:8 [ 9.916017] tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... [ 9.916022] saa7134 :05:01.0: firmware: requesting
request for help: Asus Europa2 OEM parity error
Hi, As I reported before (i am sorry for insisting, and I understand that working without the card is not so easy), this card (Asus Europa2 OEM [card=100,autodetected]) does not work with kernel 2.6.26 and later (2.6.25 is OK, at least for DVB) in 2.6.25, composite input, DVB are working. radio is not working . analog TV seems to be working (very poor antenna, hard to say) in 2.6.26 (and later, up to 2.6.30) composite input is working, DVB is not working (tzap does not lock), radio is not working (don't remember for analog TV). dmesg warns about parity error. any help would be greatly appreciated... many thanks in advance Yves here is what dmesg is saying with i2c_debug=1 and irq_debug=1 __ __ for 2.6.30, with latest v4l-dvb [r...@localhost v4l-dvb]# make unload make make install dmesg -c 21/dev/null modprobe saa7134 i2c_debug=1 irq_debug=1 [r...@localhost v4l-dvb]# dmesg Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.15 loaded saa7134[0]: found at :02:03.0, rev: 1, irq: 19, latency: 32, mmio: 0xf9ffe000 saa7134[0]: subsystem: 1043:4860, board: Asus Europa2 OEM [card=100,autodetected] saa7134[0]: board init: gpio is 0 IRQ 19/saa7134[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7134[0]: i2c xfer: a0 00 saa7134[0]: i2c xfer: a1 =43 =10 =60 =48 =54 =20 =1c =00 =43 =43 =a9 =1c =55 =d2 =b2 =92 =00 =ff =86 =0f =ff =20 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =01 =40 =01 =03 =03 =02 =03 =04 =08 =ff =00 =4c =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =1d =00 =c2 =86 =10 =01 =01 =0d =01 =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff =ff saa7134[0]: i2c eeprom 00: 43 10 60 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7134[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 20: 01 40 01 03 03 02 03 04 08 ff 00 4c ff ff ff ff saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 40: ff 1d 00 c2 86 10 01 01 0d 01 ff ff ff ff ff ff saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff i2c-adapter i2c-1: Invalid 7-bit address 0x7a saa7134[0]: i2c xfer: 8e ERROR: NO_DEVICE saa7134[0]: i2c xfer: e2 ERROR: NO_DEVICE saa7134[0]: i2c xfer: 5a ERROR: NO_DEVICE saa7134[0]: i2c xfer: 10 07 02 saa7134[0]: i2c xfer: 84 ERROR: NO_DEVICE saa7134[0]: i2c xfer: 86 saa7134[0]: i2c xfer: 86 00 saa7134[0]: i2c xfer: 87 =11 =10 =10 =10 =10 =10 =10 =10 saa7134[0]: i2c xfer: 86 1f saa7134[0]: i2c xfer: 87 =10 saa7134[0]: i2c xfer: 86 2f saa7134[0]: i2c xfer: 87 =10 saa7134[0]: i2c xfer: 86 01 02 saa7134[0]: i2c xfer: 86 00 00 saa7134[0]: i2c xfer: 86 07 saa7134[0]: i2c xfer: 87 =10 saa7134[0]: i2c xfer: 86 00 d6 30 tuner 1-0043: chip found @ 0x86 (saa7134[0]) tda9887 1-0043: creating new instance tda9887 1-0043: tda988[5/6/7] found saa7134[0]: i2c xfer: 86 00 c0 00 00 saa7134[0]: i2c xfer: c0 ERROR: NO_DEVICE saa7134[0]: i2c xfer: c2 tuner 1-0061: chip found @ 0xc2 (saa7134[0]) saa7134[0]: i2c xfer: c2 0b dc 9c 60 saa7134[0]: i2c xfer: c2 0b dc 86 54 saa7134[0]: i2c xfer: c3 =30 tuner-simple 1-0061: creating new instance tuner-simple 1-0061: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner) saa7134[0]: i2c xfer: 86 00 00 00 00 saa7134[0]: i2c xfer: c2 1b 6f 86 52 saa7134[0]: i2c xfer: 86 00 02 00 00 saa7134[0]: i2c xfer: 86 00 00 00 00 saa7134[0]: i2c xfer: c2 1b 6f 86 52 saa7134[0]: i2c xfer: 86 00 00 00 00
Re: PULL request - http://linuxtv.org/hg/~hgoede/gspca
On Thu, 18 Jun 2009 19:44:05 +0200 Hans de Goede hdego...@redhat.com wrote: I've rebased my tree on your latest and fixed the coding style issues, so please pull from: http://linuxtv.org/hg/~hgoede/gspca For: -ov511(+) support -st6422 support -ov519/ov518 fixes -sonixj 0c45:613e support -sonixj fixes -mark v4l1 ov511 driver deprecated -mark v4l1 quickcam_messenger driver deprecated Hi Mauro, The most important change is the one which fixes the NULL pointer dereference in query_ctrl (changeset 56e0ab00180f). As the bug will generate oops, it must be applied to the new 2.6.31 GIT repository. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Leadtek Winfast DTV-1000S
2009/6/19 Terry Wu terrywu2...@gmail.com: Hi, [ 9.916022] saa7134 :05:01.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 10.020209] tda10048_firmware_upload: Upload failed. (file not found?) The dvb-fe-tda10048-1.0.fw is needed. You can get it from the following links: http://tw1965.myweb.hinet.net/Linux/firmware.tar.gz http://tw1965.myweb.hinet.net/Linux/Firmware.txt http://tw1965.myweb.hinet.net/ Firmware is copied to /lib/firmware Here is the dmesg: [8.570412] Linux video capture interface: v2.00 [8.617769] cfg80211: World regulatory domain updated: [8.617772] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [8.617774] (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [8.617775] (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [8.61] (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [8.617778] (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [8.617780] (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [8.680521] saa7130/34: v4l2 driver version 0.2.15 loaded [8.680571] saa7134 :05:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [8.680576] saa7130[0]: found at :05:01.0, rev: 1, irq: 19, latency: 32, mmio: 0xfb002000 [8.680581] saa7130[0]: subsystem: 107d:6655, board: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid [card=156,insmod option] [8.680606] saa7130[0]: board init: gpio is 22009 [8.827183] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [8.827229] HDA Intel :00:1b.0: setting latency timer to 64 [8.860026] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [8.860035] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff ff ff ff ff [8.860043] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08 ff 00 8a ff ff ff ff [8.860051] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860059] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff 04 ff ff ff ff ff ff [8.860067] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860074] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860082] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860089] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860097] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860105] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860112] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860120] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860127] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860135] saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860143] saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860152] tveeprom 0-0050: Encountered bad packet header [ff]. Corrupt or not a Hauppauge eeprom. [8.860154] saa7130[0]: warning: unknown hauppauge model #0 [8.860156] saa7130[0]: hauppauge eeprom: model=0 [8.932026] Chip ID is not zero. It is not a TEA5767 [8.932091] tuner 0-0060: chip found @ 0xc0 (saa7130[0]) [8.976009] tda8290: no gate control were provided! [8.976079] tuner 0-0060: Tuner has no way to set tv freq [8.976084] tuner 0-0060: Tuner has no way to set tv freq [8.976170] saa7130[0]: registered device video0 [v4l2] [8.976214] saa7130[0]: registered device vbi0 [8.976251] saa7130[0]: registered device radio0 [8.976281] rt2400pci :05:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [8.983389] phy0: Selected rate control algorithm 'pid' [9.017796] dvb_init() allocating 1 frontend [9.036163] saa7134 ALSA driver for DMA sound loaded [9.036165] saa7130[0]/alsa: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid doesn't support digital audio [9.068118] Registered led device: rt2400pci-phy0:radio [9.068149] Registered led device: rt2400pci-phy0:quality [9.140897] tda18271 0-0060: creating new instance [9.148509] TDA18271HD/C1 detected @ 0-0060 [9.157831] lp0: using parport0 (interrupt-driven). [9.215386] Adding 6024332k swap on /dev/sda5. Priority:-1 extents:1 across:6024332k [9.552013] DVB: registering new adapter (saa7130[0]) [9.552017] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)... [9.745332] EXT4 FS on sda1, internal journal on sda1:8 [9.880021] tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... [9.880026] saa7134 :05:01.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 10.122198] tda10048_firmware_upload: firmware read 24878 bytes. [ 10.122200] tda10048_firmware_upload: firmware uploading [ 14.208023] tda10048_firmware_upload: firmware uploaded [
[PULL] http://udev.netup.ru/hg/v4l-dvb-commits
Mauro, Please pull from http://udev.netup.ru/hg/v4l-dvb-commits for the following 4 changesets: 01/04: Change lnbh24 configure bits for NetUP card. http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=c8916f9693c7 02/04: Bug fix: stv0900 register read must using i2c in one transaction http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=b6475886d913 03/04: Implement reading uncorrected blocks for stv0900 http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=d9a197533972 04/04: Create table for customize stv0900 ts registers. http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=08bc59505548 dvb/frontends/stv0900.h | 7 ++- dvb/frontends/stv0900_core.c | 100 +-- dvb/frontends/stv0900_priv.h | 2 video/cx23885/cx23885-dvb.c | 23 - 4 files changed, 105 insertions(+), 27 deletions(-) Thanks, Igor -- 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] Use kzalloc for frontend states to have struct dvb_frontend properly initialized
Hi list! This patch changes most frontend drivers to allocate their state structure via kzalloc and not kmalloc. This is done to properly initialize the embedded struct dvb_frontend frontend field, that they all have. The visible effect of this struct being uninitalized is, that the member id that is used to set the name of kernel thread is totally random. Some board drivers (for example cx88-dvb) set this id via videobuf_dvb_alloc_frontend but most do not. So I at least get random id values for saa7134, flexcop and ttpci based cards. It looks like this in dmesg: DVB: registering adapter 1 frontend -10551321 (ST STV0299 DVB-S) The related kernel thread then also gets a strange name like kdvb-ad-1-fe--1. Signed-off-by: Matthias Schwarzott z...@gentoo.org Regards Matthias Index: v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c === --- v4l-dvb.orig/linux/drivers/media/dvb/frontends/mt312.c +++ v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c @@ -782,7 +782,7 @@ struct dvb_frontend *mt312_attach(const struct mt312_state *state = NULL; /* allocate memory for the internal state */ - state = kmalloc(sizeof(struct mt312_state), GFP_KERNEL); + state = kzalloc(sizeof(struct mt312_state), GFP_KERNEL); if (state == NULL) goto error; Index: v4l-dvb/linux/drivers/media/dvb/frontends/ves1x93.c === --- v4l-dvb.orig/linux/drivers/media/dvb/frontends/ves1x93.c +++ v4l-dvb/linux/drivers/media/dvb/frontends/ves1x93.c @@ -456,7 +456,7 @@ struct dvb_frontend* ves1x93_attach(cons u8 identity; /* allocate memory for the internal state */ - state = kmalloc(sizeof(struct ves1x93_state), GFP_KERNEL); + state = kzalloc(sizeof(struct ves1x93_state), GFP_KERNEL); if (state == NULL) goto error; /* setup the state */ Index: v4l-dvb/linux/drivers/media/dvb/frontends/at76c651.c === --- v4l-dvb.orig/linux/drivers/media/dvb/frontends/at76c651.c +++ v4l-dvb/linux/drivers/media/dvb/frontends/at76c651.c @@ -369,7 +369,7 @@ struct dvb_frontend* at76c651_attach(con struct at76c651_state* state = NULL; /* allocate memory for the internal state */ - state = kmalloc(sizeof(struct at76c651_state), GFP_KERNEL); + state = kzalloc(sizeof(struct at76c651_state), GFP_KERNEL); if (state == NULL) goto error; /* setup the state */ Index: v4l-dvb/linux/drivers/media/dvb/frontends/cx22700.c === --- v4l-dvb.orig/linux/drivers/media/dvb/frontends/cx22700.c +++ v4l-dvb/linux/drivers/media/dvb/frontends/cx22700.c @@ -380,7 +380,7 @@ struct dvb_frontend* cx22700_attach(cons struct cx22700_state* state = NULL; /* allocate memory for the internal state */ - state = kmalloc(sizeof(struct cx22700_state), GFP_KERNEL); + state = kzalloc(sizeof(struct cx22700_state), GFP_KERNEL); if (state == NULL) goto error; /* setup the state */ Index: v4l-dvb/linux/drivers/media/dvb/frontends/cx22702.c === --- v4l-dvb.orig/linux/drivers/media/dvb/frontends/cx22702.c +++ v4l-dvb/linux/drivers/media/dvb/frontends/cx22702.c @@ -580,7 +580,7 @@ struct dvb_frontend *cx22702_attach(cons struct cx22702_state *state = NULL; /* allocate memory for the internal state */ - state = kmalloc(sizeof(struct cx22702_state), GFP_KERNEL); + state = kzalloc(sizeof(struct cx22702_state), GFP_KERNEL); if (state == NULL) goto error; Index: v4l-dvb/linux/drivers/media/dvb/frontends/cx24110.c === --- v4l-dvb.orig/linux/drivers/media/dvb/frontends/cx24110.c +++ v4l-dvb/linux/drivers/media/dvb/frontends/cx24110.c @@ -598,7 +598,7 @@ struct dvb_frontend* cx24110_attach(cons int ret; /* allocate memory for the internal state */ - state = kmalloc(sizeof(struct cx24110_state), GFP_KERNEL); + state = kzalloc(sizeof(struct cx24110_state), GFP_KERNEL); if (state == NULL) goto error; /* setup the state */ Index: v4l-dvb/linux/drivers/media/dvb/frontends/dvb_dummy_fe.c === --- v4l-dvb.orig/linux/drivers/media/dvb/frontends/dvb_dummy_fe.c +++ v4l-dvb/linux/drivers/media/dvb/frontends/dvb_dummy_fe.c @@ -117,7 +117,7 @@ struct dvb_frontend* dvb_dummy_fe_ofdm_a struct dvb_dummy_fe_state* state = NULL; /* allocate memory for the internal state */ - state = kmalloc(sizeof(struct dvb_dummy_fe_state), GFP_KERNEL); + state = kzalloc(sizeof(struct dvb_dummy_fe_state), GFP_KERNEL); if (state == NULL) goto error; /* create dvb_frontend */ @@ -137,7 +137,7 @@ struct dvb_frontend *dvb_dummy_fe_qpsk_a struct dvb_dummy_fe_state* state = NULL; /* allocate memory for the internal state */ - state = kmalloc(sizeof(struct dvb_dummy_fe_state), GFP_KERNEL); + state = kzalloc(sizeof(struct
ivtv Radio Data System (RDS) - is there something planned/already available
Is there anything planned/ongoing to support Radio Data System (RDS) with ivtv supported cards? Would be quite helpful for analogue radio channel scanning and finding the matching channel names. Is there something out to be tested? thanks, Winfried -- 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: ivtv Radio Data System (RDS) - is there something planned/already available
On Friday 19 June 2009 13:36:49 wk wrote: Is there anything planned/ongoing to support Radio Data System (RDS) with ivtv supported cards? Would be quite helpful for analogue radio channel scanning and finding the matching channel names. Is there something out to be tested? As far as I know there are no ivtv-based cards with RDS functionality. If you have one that can do RDS under Windows, then please let me know and I can take a look. 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: ok more details: Re: bttv problem loading takes about several minutes
Hi, Ok I have tested modprobe bttv audiodev=-1 card=34 tuner=24 gbuffers=16 I am seeing again the delay. More ideas? Regards Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.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: ivtv Radio Data System (RDS) - is there something planned/already available
On Fri, Jun 19, 2009 at 1:43 PM, Hans Verkuilhverk...@xs4all.nl wrote: On Friday 19 June 2009 13:36:49 wk wrote: Is there anything planned/ongoing to support Radio Data System (RDS) with ivtv supported cards? Would be quite helpful for analogue radio channel scanning and finding the matching channel names. Is there something out to be tested? As far as I know there are no ivtv-based cards with RDS functionality. If you have one that can do RDS under Windows, then please let me know and I can take a look. A workaround can be to use a 10$ USB radio with RDS support and use it as a secondary (silent) tuner for doing the scanning operations in the background, so that you can have a fully up to date radio stations list all the time without impacting the listening of your main radio tuner - works very well! Ed -- 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] Use kzalloc for frontend states to have struct dvb_frontend properly initialized
Hello Matthias, Matthias Schwarzott wrote: This patch changes most frontend drivers to allocate their state structure via kzalloc and not kmalloc. This is done to properly initialize the embedded struct dvb_frontend frontend field, that they all have. The visible effect of this struct being uninitalized is, that the member id that is used to set the name of kernel thread is totally random. Some board drivers (for example cx88-dvb) set this id via videobuf_dvb_alloc_frontend but most do not. So I at least get random id values for saa7134, flexcop and ttpci based cards. It looks like this in dmesg: DVB: registering adapter 1 frontend -10551321 (ST STV0299 DVB-S) The related kernel thread then also gets a strange name like kdvb-ad-1-fe--1. Signed-off-by: Matthias Schwarzott z...@gentoo.org I still think that this id doesn't belong into struct dvb_frontend and should be private to the drivers, but using kzalloc is a good idea in every case. Did you verify that none of the drivers does an additional memset? If so, you can add my Acked-by: Andreas Oberritter o...@linuxtv.org. Regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/11 - v3] vpfe capture bridge driver for DM355 and DM6446
On Wednesday 17 June 2009 23:29:31 Alexey Klimov wrote: Hello, very small comments, see below please Thanks, I've added the missing newlines and the wrong return code in a separate patch in my pull request. 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: ok more details: Re: bttv problem loading takes about several minutes
On Friday 19 June 2009 13:49:37 Halim Sahin wrote: Hi, Ok I have tested modprobe bttv audiodev=-1 card=34 tuner=24 gbuffers=16 I am seeing again the delay. More ideas? Use more printk messages in the bttv_init_card2() function to try and narrow down the exact function call that is causing the delay. I still have no idea what it might be. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
On Monday 15 June 2009 21:48:32 Mauro Carvalho Chehab wrote: Hi Hans, Em Mon, 15 Jun 2009 13:27:42 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sunday 14 June 2009 12:15:34 Hans Verkuil wrote: On Sunday 14 June 2009 11:50:51 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - ivtv/cx18: fix regression: class controls are no longer seen - v4l2-ctl: add modulator get/set options. - v4l2-spec: update VIDIOC_G/S_MODULATOR section. - compat: fix __fls check for the arm architecture. - smscoreapi: fix compile warning The first one is a high prio bug as it is a 2.6.30 regression. Mike, once this is merged in the git tree this one can be queued for the 2.6.30 stable series. The other changes are small stuff. Added one more minor change: - v4l2-i2c-drv.h: add comment describing when not to use this header. The above patches seem ok. Can you pull from this tree and just skip the last controversial patch? Or do you prefer me to redo this tree without that last patch? 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: [PATCH] Use kzalloc for frontend states to have struct dvb_frontend properly initialized
On Fri, Jun 19, 2009 at 8:41 AM, Matthias Schwarzottz...@gentoo.org wrote: Yes, I did verify that. There are no memset calls for that memory. If so, you can add my Acked-by: Andreas Oberritter o...@linuxtv.org. Regards Matthias I'm glad to see this finally happen. This has been bugging me for a while on s5h1409/s5h1411 and I just never got around to submitting a patch. Thanks! Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.kernellabs.com/hg/~dheitmueller/em28xx-indtube2
Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/em28xx-indtube2 for the following: - em28xx: make sure the analog GPIOs are set if we used a card hint - em28xx: add support for EVGA inDtube Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
It seems that attempting to compile the current v4l-dvb against a stock Karmic Koala build fails. I suspect this has to do with the fact that 2.6.30 is built with ieee1394 enabled, which causes firedtv-ieee1394.c to get compiled, and that file references #include files that do not exist. As far as I can tell, IEEE1394 is not enabled in my 2.6.27 build, which is why I was not seeing it before. Other users reported this issue on the #linuxtv irc a few days ago, and I though it was just something weird about their environment. I'm not familiar with the firedtv driver, so if someone who is wants to chime in, I would appreciate it. 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
[REVIEW] refactoring video_register_device
Hi Mauro, Based on your earlier comments I refactored the video_register_device function. My code is here http://www.linuxtv.org/hg/~hverkuil/v4l-dvb and it contains the following four patches: - v4l: remove video_register_device_index This implements the RFC I posted earlier: video_register_device_index is not actually used in any of the drivers so we can remove it and instead automatically determine the index for each device. This simplifies the video_register_device function in preparation for the next patch. - v4l: refactor video_register_device This does the main refactoring. The term 'kernel number' is now replaced with 'device node number', which is hopefully more understandable. The code to find the device node number and minor number has been split off and exists in two variants, depending on CONFIG_VIDEO_FIXED_MINOR_RANGES. I also found and fixed a potential race condition. - ivtv/cx18: replace 'kernel number' with 'device node number'. Minor changes to ivtv/cx18 to conform to the new terminology. - v4l: warn when desired devnodenr is in use add _no_warn function Added the warning when the desired device node number was already in use and add a video_register_device_no_warn variant for use with ivtv and cx18 where that warning is not appropriate. Hopefully this makes this function easier to understand, but I'm too closely familiar with the code to tell whether I've succeeded. So this needs to be reviewed first. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt | 43 ++-- drivers/media/video/cx18/cx18-driver.c |2 drivers/media/video/cx18/cx18-streams.c |4 drivers/media/video/ivtv/ivtv-driver.c |2 drivers/media/video/ivtv/ivtv-streams.c |4 drivers/media/video/v4l2-dev.c | 270 +++ include/media/v4l2-dev.h |6 7 files changed, 192 insertions(+), 139 deletions(-) -- 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
Problems receiving hd channels from astra 19.2 with cx800 driver
Hello, I am using a Tevii S460 DVB-S2 card in a linux environment. Useing the lasted v4l driver source. Use mplayer to test the adapter. Can receive BBC HD from astra 28.2 including the digital audio. How ever when I try HD channels from Astra 19.2 I get error from the cx8802 driver, cx8802_start_dma() Failed. Unsupported value in .mpeg (0 Can receive 'normal' channels from astra 19.2. Linux version 1.6.29-R5, latest v4l sources ( downloaded 4 days ago) The S460 is the only PCI card in the system, motherboard NC62K from Jetway. Does this sound familiar? Regards Peter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
On Friday 19 June 2009 16:52:06 Devin Heitmueller wrote: It seems that attempting to compile the current v4l-dvb against a stock Karmic Koala build fails. I suspect this has to do with the fact that 2.6.30 is built with ieee1394 enabled, which causes firedtv-ieee1394.c to get compiled, and that file references #include files that do not exist. As far as I can tell, IEEE1394 is not enabled in my 2.6.27 build, which is why I was not seeing it before. Other users reported this issue on the #linuxtv irc a few days ago, and I though it was just something weird about their environment. I'm not familiar with the firedtv driver, so if someone who is wants to chime in, I would appreciate it. Devin What's the compile error exactly? The firedtv driver compiles fine in the daily build against the vanilla 2.6.30 kernel. 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: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
On Fri, Jun 19, 2009 at 11:33 AM, Hans Verkuilhverk...@xs4all.nl wrote: What's the compile error exactly? The firedtv driver compiles fine in the daily build against the vanilla 2.6.30 kernel. Regards, Hans Unfortunately, I sent the email from work and didn't have the output in front of me (or else I would have pasted it into the email). Several people also reported it on #linuxtv on 6/11, but it looks like the pastebins have already expired. :-( I will provide the output tonight. I started to debug it last night, and it seems that firedtv-ieee1494.c doesn't normally get compiled at all, so if you add 1394 support to your build you will likely also see the issue. 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: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
On Friday 19 June 2009 17:42:18 Devin Heitmueller wrote: On Fri, Jun 19, 2009 at 11:33 AM, Hans Verkuilhverk...@xs4all.nl wrote: What's the compile error exactly? The firedtv driver compiles fine in the daily build against the vanilla 2.6.30 kernel. Regards, Hans Unfortunately, I sent the email from work and didn't have the output in front of me (or else I would have pasted it into the email). Several people also reported it on #linuxtv on 6/11, but it looks like the pastebins have already expired. :-( I will provide the output tonight. I started to debug it last night, and it seems that firedtv-ieee1494.c doesn't normally get compiled at all, so if you add 1394 support to your build you will likely also see the issue. Hmm, I discovered that firedtv-1394.c isn't compiled in the daily build even though ieee1394 is enabled in the kernel. I can manually enable it, though: make menuconfig, disable and enable the firedtv driver, and then it magically works. But even then it still compiles fine against the vanilla 2.6.30 kernel. 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: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
On Fri, Jun 19, 2009 at 12:04 PM, Hans Verkuilhverk...@xs4all.nl wrote: Hmm, I discovered that firedtv-1394.c isn't compiled in the daily build even though ieee1394 is enabled in the kernel. I can manually enable it, though: make menuconfig, disable and enable the firedtv driver, and then it magically works. But even then it still compiles fine against the vanilla 2.6.30 kernel. Well, I'm obviously kicking myself for not having captured the output last night when I was at home. So, you're saying that firedvt-1394.c is being compiled? Let me rephrase the question: Take a look at firedtv-1394.c, line 22, and tell me where the file csr1212.h can be found either in your kernel source tree or your v4l-dvb tree. 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
sleep in atomic in dvb_dmx_swfilter_packet
Hi, we've found that there is a vmalloc call from atomic context: dvb_dmx_swfilter_packets - spin_lock() - dvb_dmx_swfilter_packet - vmalloc() -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
On Friday 19 June 2009 18:11:11 Devin Heitmueller wrote: On Fri, Jun 19, 2009 at 12:04 PM, Hans Verkuilhverk...@xs4all.nl wrote: Hmm, I discovered that firedtv-1394.c isn't compiled in the daily build even though ieee1394 is enabled in the kernel. I can manually enable it, though: make menuconfig, disable and enable the firedtv driver, and then it magically works. But even then it still compiles fine against the vanilla 2.6.30 kernel. Well, I'm obviously kicking myself for not having captured the output last night when I was at home. So, you're saying that firedvt-1394.c is being compiled? Let me rephrase the question: Take a look at firedtv-1394.c, line 22, and tell me where the file csr1212.h can be found either in your kernel source tree or your v4l-dvb tree. Devin It's here: /usr/src/linux/drivers/ieee1394/csr1212.h 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: Leadtek Winfast DTV-1000S
Hi all, Am Freitag, den 19.06.2009, 19:12 +0930 schrieb James Moschou: 2009/6/19 Terry Wu terrywu2...@gmail.com: Hi, [9.916022] saa7134 :05:01.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 10.020209] tda10048_firmware_upload: Upload failed. (file not found?) The dvb-fe-tda10048-1.0.fw is needed. You can get it from the following links: http://tw1965.myweb.hinet.net/Linux/firmware.tar.gz http://tw1965.myweb.hinet.net/Linux/Firmware.txt http://tw1965.myweb.hinet.net/ Firmware is copied to /lib/firmware Here is the dmesg: [8.570412] Linux video capture interface: v2.00 [8.617769] cfg80211: World regulatory domain updated: [8.617772](start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [8.617774](2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [8.617775](2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [8.61](2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [8.617778](517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [8.617780](5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [8.680521] saa7130/34: v4l2 driver version 0.2.15 loaded [8.680571] saa7134 :05:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [8.680576] saa7130[0]: found at :05:01.0, rev: 1, irq: 19, latency: 32, mmio: 0xfb002000 [8.680581] saa7130[0]: subsystem: 107d:6655, board: Hauppauge Mike seems to have the subdevice wrong. He used 107d:6555. That is why the card is not auto detected. Please try to force card=169 and _not_ card=156. Cheers, Hermann WinTV-HVR1110r3 DVB-T/Hybrid [card=156,insmod option] [8.680606] saa7130[0]: board init: gpio is 22009 [8.827183] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [8.827229] HDA Intel :00:1b.0: setting latency timer to 64 [8.860026] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [8.860035] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff ff ff ff ff [8.860043] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08 ff 00 8a ff ff ff ff [8.860051] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860059] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff 04 ff ff ff ff ff ff [8.860067] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860074] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860082] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860089] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860097] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860105] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860112] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860120] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860127] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860135] saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860143] saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [8.860152] tveeprom 0-0050: Encountered bad packet header [ff]. Corrupt or not a Hauppauge eeprom. [8.860154] saa7130[0]: warning: unknown hauppauge model #0 [8.860156] saa7130[0]: hauppauge eeprom: model=0 [8.932026] Chip ID is not zero. It is not a TEA5767 [8.932091] tuner 0-0060: chip found @ 0xc0 (saa7130[0]) [8.976009] tda8290: no gate control were provided! [8.976079] tuner 0-0060: Tuner has no way to set tv freq [8.976084] tuner 0-0060: Tuner has no way to set tv freq [8.976170] saa7130[0]: registered device video0 [v4l2] [8.976214] saa7130[0]: registered device vbi0 [8.976251] saa7130[0]: registered device radio0 [8.976281] rt2400pci :05:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [8.983389] phy0: Selected rate control algorithm 'pid' [9.017796] dvb_init() allocating 1 frontend [9.036163] saa7134 ALSA driver for DMA sound loaded [9.036165] saa7130[0]/alsa: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid doesn't support digital audio [9.068118] Registered led device: rt2400pci-phy0:radio [9.068149] Registered led device: rt2400pci-phy0:quality [9.140897] tda18271 0-0060: creating new instance [9.148509] TDA18271HD/C1 detected @ 0-0060 [9.157831] lp0: using parport0 (interrupt-driven). [9.215386] Adding 6024332k swap on /dev/sda5. Priority:-1 extents:1 across:6024332k [9.552013] DVB: registering new adapter (saa7130[0]) [9.552017] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN DVB-T)... [9.745332] EXT4 FS on sda1,
Re: Sakar 57379 USB Digital Video Camera...
On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. Another thing I could not see in front of me when I looked at my Jeilin Mass Storage camera, was what is written on it. It says there it is a Cobra DMC300, and it says Digital Video Camera I never paid any attention to that before, because for years my priorities were still cameras. But now, just in case I have lost the driver CD, I went out to Google and found what claims to be a driver for it. I hope that, with such a long idleness just sitting on a back corner of the desk, the battery has not died in the camera. If I get some time in the next few days to try to fight Windows, I will make some logs of my own. Then we can compare notes and see if the two cameras are similar, or not. What I am hoping for, obviously, is that both cameras are downloading JPEG frames, and use similar methods to do that. If that is true (we don't know that, of course) then the only problem I can imagine is that both of them are reported, even in webcam mode, as Mass Storage Bulk Transport devices. If so, then the camera(s) would need to be blacklisted by mass-storage when set up as webcams. Now that I got the supposed driver, I should go out on the web and get the supposed manual for my camera. Then perhaps I can know how it is supposed to be used as a webcam and get the needed sniffs. Meanwhile, I hope that you will do the same. Theodore Kilgore -- 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: OV7670: getting it working with soc-camera.
Hi All,
Turns out that, in addition the below, one more soc-camera ops
function is still needed.
Init is required in my case to make a call to the subdev-ops-core_ops-init
function in order to put the register contents back after the reset callback
in soc_camera_open.
I'm guessing down the line it will make sense to call this directly in
soc_camera
or are the circumstances where it should call additional init functions?
Updated temporary patch to get ov7670 working with soc camera.
---
Basically this is the original patch with the changes Guennadi
suggested. Again this is only for info, not a formal patch submission.
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..9bea804 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -19,6 +19,12 @@
#include media/v4l2-chip-ident.h
#include media/v4l2-i2c-drv.h
+#define OV7670_SOC
+
+
+#ifdef OV7670_SOC
+#include media/soc_camera.h
+#endif /* OV7670_SOC */
MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
MODULE_DESCRIPTION(A low-level driver for OmniVision ov7670 sensors);
@@ -1239,13 +1245,58 @@ static const struct v4l2_subdev_ops ov7670_ops = {
};
/* --- */
+#ifdef OV7670_SOC
+
+static unsigned long ov7670_soc_query_bus_param(struct soc_camera_device
*icd)
+{
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
+ SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
+ SOCAM_DATAWIDTH_8 | SOCAM_DATA_ACTIVE_HIGH;
+
+ return soc_camera_apply_sensor_flags(icl, flags);
+}
+/* This device only supports one bus option */
+static int ov7670_soc_set_bus_param(struct soc_camera_device *icd,
+ unsigned long flags)
+{
+ return 0;
+}
+
+static struct soc_camera_ops ov7670_soc_ops = {
+ .set_bus_param = ov7670_soc_set_bus_param,
+ .query_bus_param = ov7670_soc_query_bus_param,
+};
+#define SETFOURCC(type) .name = (#type), .fourcc = (V4L2_PIX_FMT_ ## type)
+static const struct soc_camera_data_format ov7670_soc_fmt_lists[] = {
+ {
+ SETFOURCC(YUYV),
+ .depth = 16,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ }, {
+ SETFOURCC(RGB565),
+ .depth = 16,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ },
+};
+
+#endif
static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct v4l2_subdev *sd;
struct ov7670_info *info;
int ret;
+#ifdef OV7670_SOC
+ struct soc_camera_device *icd = client-dev.platform_data;
+ icd-ops = ov7670_soc_ops;
+ icd-rect_max.width = VGA_WIDTH;
+ icd-rect_max.height = VGA_HEIGHT;
+ icd-formats = ov7670_soc_fmt_lists;
+ icd-num_formats = ARRAY_SIZE(ov7670_soc_fmt_lists);
+#endif
info = kzalloc(sizeof(struct ov7670_info), GFP_KERNEL);
if (info == NULL)
--
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: WARNINGS, 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:Fri Jun 19 19:00:02 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12070:722c6faf3ab5 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: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-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-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK 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-x86_64: WARNINGS sparse (linux-2.6.30): 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: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK 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: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: Sakar 57379 USB Digital Video Camera...
On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. Another thing I could not see in front of me when I looked at my Jeilin Mass Storage camera, was what is written on it. It says there it is a Cobra DMC300, and it says Digital Video Camera I never paid any attention to that before, because for years my priorities were still cameras. But now, just in case I have lost the driver CD, I went out to Google and found what claims to be a driver for it. I hope that, with such a long idleness just sitting on a back corner of the desk, the battery has not died in the camera. If I get some time in the next few days to try to fight Windows, I will make some logs of my own. Then we can compare notes and see if the two cameras are similar, or not. What I am hoping for, obviously, is that both cameras are downloading JPEG frames, and use similar methods to do that. If that is true (we don't know that, of course) then the only problem I can imagine is that both of them are reported, even in webcam mode, as Mass Storage Bulk Transport devices. If so, then the camera(s) would need to be blacklisted by mass-storage when set up as webcams. Now that I got the supposed driver, I should go out on the web and get the supposed manual for my camera. Then perhaps I can know how it is supposed to be used as a webcam and get the needed sniffs. Meanwhile, I hope that you will do the same. OK. I have two steps to take: 1. Installing the driver and software on my sole remaining Windows machine. It already has snoopy. 2. Getting the camera away from my daughter for more than 2 minutes. It's like the thing is glued to her hand. :) Regards, Andy Theodore Kilgore -- 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: Leadtek Winfast DTV-1000S
On Fri, Jun 19, 2009 at 12:51 PM, hermann pittonhermann-pit...@arcor.de wrote: Hi all, Am Freitag, den 19.06.2009, 19:12 +0930 schrieb James Moschou: 2009/6/19 Terry Wu terrywu2...@gmail.com: Hi, [ 9.916022] saa7134 :05:01.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 10.020209] tda10048_firmware_upload: Upload failed. (file not found?) The dvb-fe-tda10048-1.0.fw is needed. You can get it from the following links: http://tw1965.myweb.hinet.net/Linux/firmware.tar.gz http://tw1965.myweb.hinet.net/Linux/Firmware.txt http://tw1965.myweb.hinet.net/ Firmware is copied to /lib/firmware Here is the dmesg: [ 8.570412] Linux video capture interface: v2.00 [ 8.617769] cfg80211: World regulatory domain updated: [ 8.617772] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 8.617774] (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 8.617775] (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [ 8.61] (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [ 8.617778] (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 8.617780] (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 8.680521] saa7130/34: v4l2 driver version 0.2.15 loaded [ 8.680571] saa7134 :05:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 8.680576] saa7130[0]: found at :05:01.0, rev: 1, irq: 19, latency: 32, mmio: 0xfb002000 [ 8.680581] saa7130[0]: subsystem: 107d:6655, board: Hauppauge Mike seems to have the subdevice wrong. He used 107d:6555. That is why the card is not auto detected. Please try to force card=169 and _not_ card=156. Cheers, Hermann WinTV-HVR1110r3 DVB-T/Hybrid [card=156,insmod option] [ 8.680606] saa7130[0]: board init: gpio is 22009 [ 8.827183] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [ 8.827229] HDA Intel :00:1b.0: setting latency timer to 64 [ 8.860026] saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [ 8.860035] saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff ff ff ff ff [ 8.860043] saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08 ff 00 8a ff ff ff ff [ 8.860051] saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860059] saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff 04 ff ff ff ff ff ff [ 8.860067] saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860074] saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860082] saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860089] saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860097] saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860105] saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860112] saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860120] saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860127] saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860135] saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860143] saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 8.860152] tveeprom 0-0050: Encountered bad packet header [ff]. Corrupt or not a Hauppauge eeprom. [ 8.860154] saa7130[0]: warning: unknown hauppauge model #0 [ 8.860156] saa7130[0]: hauppauge eeprom: model=0 [ 8.932026] Chip ID is not zero. It is not a TEA5767 [ 8.932091] tuner 0-0060: chip found @ 0xc0 (saa7130[0]) [ 8.976009] tda8290: no gate control were provided! [ 8.976079] tuner 0-0060: Tuner has no way to set tv freq [ 8.976084] tuner 0-0060: Tuner has no way to set tv freq [ 8.976170] saa7130[0]: registered device video0 [v4l2] [ 8.976214] saa7130[0]: registered device vbi0 [ 8.976251] saa7130[0]: registered device radio0 [ 8.976281] rt2400pci :05:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [ 8.983389] phy0: Selected rate control algorithm 'pid' [ 9.017796] dvb_init() allocating 1 frontend [ 9.036163] saa7134 ALSA driver for DMA sound loaded [ 9.036165] saa7130[0]/alsa: Hauppauge WinTV-HVR1110r3 DVB-T/Hybrid doesn't support digital audio [ 9.068118] Registered led device: rt2400pci-phy0:radio [ 9.068149] Registered led device: rt2400pci-phy0:quality [ 9.140897] tda18271 0-0060: creating new instance [ 9.148509] TDA18271HD/C1 detected @ 0-0060 [ 9.157831] lp0: using parport0 (interrupt-driven). [ 9.215386] Adding 6024332k swap on /dev/sda5. Priority:-1 extents:1 across:6024332k [ 9.552013] DVB: registering new adapter (saa7130[0]) [ 9.552017] DVB: registering
Re: Sakar 57379 USB Digital Video Camera...
On Fri, 19 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. Another thing I could not see in front of me when I looked at my Jeilin Mass Storage camera, was what is written on it. It says there it is a Cobra DMC300, and it says Digital Video Camera I never paid any attention to that before, because for years my priorities were still cameras. But now, just in case I have lost the driver CD, I went out to Google and found what claims to be a driver for it. I hope that, with such a long idleness just sitting on a back corner of the desk, the battery has not died in the camera. If I get some time in the next few days to try to fight Windows, I will make some logs of my own. Then we can compare notes and see if the two cameras are similar, or not. What I am hoping for, obviously, is that both cameras are downloading JPEG frames, and use similar methods to do that. If that is true (we don't know that, of course) then the only problem I can imagine is that both of them are reported, even in webcam mode, as Mass Storage Bulk Transport devices. If so, then the camera(s) would need to be blacklisted by mass-storage when set up as webcams. Now that I got the supposed driver, I should go out on the web and get the supposed manual for my camera. Then perhaps I can know how it is supposed to be used as a webcam and get the needed sniffs. Meanwhile, I hope that you will do the same. OK. I have two steps to take: 1. Installing the driver and software on my sole remaining Windows machine. It already has snoopy. Great. 2. Getting the camera away from my daughter for more than 2 minutes. It's like the thing is glued to her hand. :) Oops. Not so good. Luck to you with that. But I hope that your daughter is suitably impressed with the idea of making things work in Linux, and suitably impressed with her father's skills about that kind of thing. I should mention. Mine has a microphone, too. Let us hope that the two are essentially identical except for things like packaging. And let us hope that the webcam functionality is not using some kind of weird compression algorithm. But yours, like mine, is using JPEG in still mode, right? So if it is using some weirdo scheme in webcam mode that will be both unpleasant and surprising. The only other things which might interfere are the following: 1. I am teaching in summer school. I just gave a test and I have to grade it over the weekend. The final exam is next Friday, so I will be similarly engaged. 2. We are going on vacation on July 7 and returning on July 23. My wife says that we will spend our spare time this weekend in planning. Because of this and because of item 1, I do not know whether or not I will be able to do the OEM install over here, or not, before next week. 3. Still working to finish expanding the mr97310a driver to support all known cameras with that chip in them. Believe it or not, some of those which have the chip and share a common Vendor:Product number work differently. So, ad-hoc methods needed to be figured out to classify them. This has been done, and all known cameras now work. There are four different initialization sequences to be taken into account. They all work. What is left to do now is to figure out how to apply the needed control sequences for things like brightness, gamma, white balance, and so forth and so on. So I am busy, but at the same time I am very much interested in taking this project on, too, because it involves something I have worked on in the past, myself. So let us see how it appears to come out. If I can get your log file, it will probably give a good start. Theodore Kilgore -- 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
[PATCH] Stop defining I2C adapter IDs nobody uses
There is no point in defining I2C adapter IDs when no code is using
them. As this field might go away in the future, stop using it when
we don't need to.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
There are 2 different cases:
* If ir-kbd-i2c tests the adapter ID on older kernels, we have to keep
the ID definition in the v4l-dvb repository and only drop it in the
upstream kernel.
* For other adapter drivers, we can drop the definition right away.
linux/drivers/media/video/au0828/au0828-i2c.c|1 -
linux/drivers/media/video/bt8xx/bttv-i2c.c |4
linux/drivers/media/video/cafe_ccic.c|1 -
linux/drivers/media/video/cx18/cx18-i2c.c|2 ++
linux/drivers/media/video/cx231xx/cx231xx-i2c.c |1 -
linux/drivers/media/video/cx23885/cx23885-i2c.c |2 ++
linux/drivers/media/video/em28xx/em28xx-i2c.c|2 ++
linux/drivers/media/video/hdpvr/hdpvr-i2c.c |1 -
linux/drivers/media/video/ivtv/ivtv-i2c.c|4
linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c |2 ++
linux/drivers/media/video/vino.c |1 -
linux/drivers/media/video/w9968cf.c |1 -
linux/drivers/media/video/zoran/zoran_card.c |1 -
13 files changed, 16 insertions(+), 7 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-06-04
14:08:18.0 +0200
+++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-06-19
20:30:59.0 +0200
@@ -355,7 +355,9 @@ int __devinit init_bttv_i2c(struct bttv
/* bt878 */
strlcpy(btv-c.i2c_adap.name, bt878,
sizeof(btv-c.i2c_adap.name));
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 31)
btv-c.i2c_adap.id = I2C_HW_B_BT848;/* FIXME */
+#endif
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
btv-c.i2c_adap.algo = (struct i2c_algorithm *)bttv_algo;
#else
@@ -369,7 +371,9 @@ int __devinit init_bttv_i2c(struct bttv
strlcpy(btv-c.i2c_adap.name, bttv,
sizeof(btv-c.i2c_adap.name));
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 31)
btv-c.i2c_adap.id = I2C_HW_B_BT848;
+#endif
memcpy(btv-i2c_algo, bttv_i2c_algo_bit_template,
sizeof(bttv_i2c_algo_bit_template));
btv-i2c_algo.udelay = i2c_udelay;
--- v4l-dvb.orig/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-05-28 12:42:51.0 +0200
+++ v4l-dvb/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-06-19 20:30:02.0 +0200
@@ -618,7 +618,9 @@ static struct i2c_algorithm pvr2_i2c_alg
static struct i2c_adapter pvr2_i2c_adap_template = {
.owner = THIS_MODULE,
.class = 0,
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 31)
.id= I2C_HW_B_BT848,
+#endif
};
--- v4l-dvb.orig/linux/drivers/media/video/zoran/zoran_card.c 2009-06-16
20:56:12.0 +0200
+++ v4l-dvb/linux/drivers/media/video/zoran/zoran_card.c2009-06-19
20:53:11.0 +0200
@@ -733,7 +733,6 @@ zoran_register_i2c (struct zoran *zr)
memcpy(zr-i2c_algo, zoran_i2c_bit_data_template,
sizeof(struct i2c_algo_bit_data));
zr-i2c_algo.data = zr;
- zr-i2c_adapter.id = I2C_HW_B_ZR36067;
strlcpy(zr-i2c_adapter.name, ZR_DEVNAME(zr),
sizeof(zr-i2c_adapter.name));
i2c_set_adapdata(zr-i2c_adapter, zr-v4l2_dev);
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-i2c.c 2009-05-28
12:42:51.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-i2c.c 2009-06-19
20:54:27.0 +0200
@@ -465,7 +465,9 @@ static struct i2c_adapter em28xx_adap_te
.class = I2C_CLASS_TV_ANALOG,
#endif
.name = em28xx,
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 31)
.id = I2C_HW_B_EM28XX,
+#endif
.algo = em28xx_algo,
};
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-21
11:00:21.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-06-19
20:58:10.0 +0200
@@ -190,7 +190,9 @@ static int cx18_getsda(void *data)
/* template for i2c-bit-algo */
static struct i2c_adapter cx18_i2c_adap_template = {
.name = cx18 i2c driver,
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 31)
.id = I2C_HW_B_CX2341X,
+#endif
.algo = NULL, /* set by i2c-algo-bit */
.algo_data = NULL, /* filled from template */
.owner = THIS_MODULE,
--- v4l-dvb.orig/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-06-19
18:34:13.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-06-19
20:58:26.0 +0200
@@ -516,7 +516,9 @@ static struct i2c_algorithm ivtv_algo =
/* template for our-bit banger */
static struct i2c_adapter ivtv_i2c_adap_hw_template = {
.name = ivtv i2c
[PATCH 2/4] V4L: em28xx, fix lock imbalance
There is one omitted unlock in em28xx_usb_probe. Fix that.
Signed-off-by: Jiri Slaby jirisl...@gmail.com
---
drivers/media/video/em28xx/em28xx-cards.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 36abb35..922d21d 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2445,6 +2445,7 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
retval = em28xx_init_dev(dev, udev, interface, nr);
if (retval) {
em28xx_devused = ~(1dev-devno);
+ mutex_unlock(dev-lock);
kfree(dev);
goto err;
}
--
1.6.3.2
--
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 4/4] V4L: saa7134, fix lock imbalance
There seems to be one superfluos unlock in a poll function. Remove it. Signed-off-by: Jiri Slaby jirisl...@gmail.com --- drivers/media/video/saa7134/saa7134-video.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-video.c b/drivers/media/video/saa7134/saa7134-video.c index 82b57a6..dd9aab0 100644 --- a/drivers/media/video/saa7134/saa7134-video.c +++ b/drivers/media/video/saa7134/saa7134-video.c @@ -1443,7 +1443,6 @@ video_poll(struct file *file, struct poll_table_struct *wait) fh-cap.ops-buf_queue(fh-cap,fh-cap.read_buf); fh-cap.read_off = 0; } - mutex_unlock(fh-cap.vb_lock); buf = fh-cap.read_buf; } -- 1.6.3.2 -- 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 1/4] V4L: radio-si470x, fix lock imbalance
There is one path with omitted unlock in si470x_fops_release. Fix that. Signed-off-by: Jiri Slaby jirisl...@gmail.com --- drivers/media/radio/radio-si470x.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/radio/radio-si470x.c b/drivers/media/radio/radio-si470x.c index 640421c..46d2163 100644 --- a/drivers/media/radio/radio-si470x.c +++ b/drivers/media/radio/radio-si470x.c @@ -1200,7 +1200,7 @@ static int si470x_fops_release(struct file *file) video_unregister_device(radio-videodev); kfree(radio-buffer); kfree(radio); - goto done; + goto unlock; } /* stop rds reception */ @@ -1213,9 +1213,8 @@ static int si470x_fops_release(struct file *file) retval = si470x_stop(radio); usb_autopm_put_interface(radio-intf); } - +unlock: mutex_unlock(radio-disconnect_lock); - done: return retval; } -- 1.6.3.2 -- 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 3/4] V4L: hdpvr, fix lock imbalances
There are many lock imbalances in this driver. Fix all found.
Signed-off-by: Jiri Slaby jirisl...@gmail.com
---
drivers/media/video/hdpvr/hdpvr-core.c | 12 ++--
drivers/media/video/hdpvr/hdpvr-video.c |6 --
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
b/drivers/media/video/hdpvr/hdpvr-core.c
index 188bd5a..1c9bc94 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -126,7 +126,7 @@ static int device_authorization(struct hdpvr_device *dev)
char *print_buf = kzalloc(5*buf_size+1, GFP_KERNEL);
if (!print_buf) {
v4l2_err(dev-v4l2_dev, Out of memory\n);
- goto error;
+ return retval;
}
#endif
@@ -140,7 +140,7 @@ static int device_authorization(struct hdpvr_device *dev)
if (ret != 46) {
v4l2_err(dev-v4l2_dev,
unexpected answer of status request, len %d\n, ret);
- goto error;
+ goto unlock;
}
#ifdef HDPVR_DEBUG
else {
@@ -163,7 +163,7 @@ static int device_authorization(struct hdpvr_device *dev)
v4l2_err(dev-v4l2_dev, unknown firmware version 0x%x\n,
dev-usbc_buf[1]);
ret = -EINVAL;
- goto error;
+ goto unlock;
}
response = dev-usbc_buf+38;
@@ -188,10 +188,10 @@ static int device_authorization(struct hdpvr_device *dev)
1);
v4l2_dbg(MSG_INFO, hdpvr_debug, dev-v4l2_dev,
magic request returned %d\n, ret);
- mutex_unlock(dev-usbc_mutex);
retval = ret != 8;
-error:
+unlock:
+ mutex_unlock(dev-usbc_mutex);
return retval;
}
@@ -350,6 +350,7 @@ static int hdpvr_probe(struct usb_interface *interface,
mutex_lock(dev-io_mutex);
if (hdpvr_alloc_buffers(dev, NUM_BUFFERS)) {
+ mutex_unlock(dev-io_mutex);
v4l2_err(dev-v4l2_dev,
allocating transfer buffers failed\n);
goto error;
@@ -381,7 +382,6 @@ static int hdpvr_probe(struct usb_interface *interface,
error:
if (dev) {
- mutex_unlock(dev-io_mutex);
/* this frees allocated memory */
hdpvr_delete(dev);
}
diff --git a/drivers/media/video/hdpvr/hdpvr-video.c
b/drivers/media/video/hdpvr/hdpvr-video.c
index ccd47f5..5937de2 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -375,6 +375,7 @@ static int hdpvr_open(struct file *file)
* in resumption */
mutex_lock(dev-io_mutex);
dev-open_count++;
+ mutex_unlock(dev-io_mutex);
fh-dev = dev;
@@ -383,7 +384,6 @@ static int hdpvr_open(struct file *file)
retval = 0;
err:
- mutex_unlock(dev-io_mutex);
return retval;
}
@@ -519,8 +519,10 @@ static unsigned int hdpvr_poll(struct file *filp,
poll_table *wait)
mutex_lock(dev-io_mutex);
- if (video_is_unregistered(dev-video_dev))
+ if (video_is_unregistered(dev-video_dev)) {
+ mutex_unlock(dev-io_mutex);
return -EIO;
+ }
if (dev-status == STATUS_IDLE) {
if (hdpvr_start_streaming(dev)) {
--
1.6.3.2
--
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/11 - v3] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver
m-kariche...@ti.com writes: From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com Big Thanks to all reviewers who have contributed to this driver by reviewing and offering valuable comments. VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446 This is the version v3 of the patch series. This is the reworked version of the driver based on comments received against the last version (v2) of the patch and is expected to be final version candidate for merge to upstream kernel FYI... I've updated the staging/vpfe branch of davinci git with this series and the tvp514x v3 patch. Also, I'll be pushing the arch/arm/* patches of this series to DaVinci git master and queueing them for upstream merge. Kevin +++ These patches add support for VPFE (Video Processing Front End) based video capture on DM355 and DM6446 EVMs. For more details on the hardware configuration and capabilities, please refer the vpfe_capture.c header. This patch set consists of following:- Patch 1: VPFE Capture bridge driver Patch 2: CCDC hw device header file Patch 3: DM355 CCDC hw module Patch 4: DM644x CCDC hw module Patch 5: ccdc types used across CCDC modules Patch 6: Makefile and config files for the driver Patch 7: DM355 platform and board setup Patch 8: DM644x platform and board setup Patch 9: common vpss hw module for video drivers Patch 10: Remove outdated driver files from davinci git tree Patch 11: Makefile and config files for the davinci git tree (New from v2) NOTE: 1. Patches 10-11 are only for DaVinci GIT tree. Others applies to DaVinci GIT and v4l-dvb 2. Dependent on the TVP514x decoder driver patch for migrating the driver to sub device model from Vaibhav Hiremath. I am sending the reworked version of this patch instead of Vaibhav. Following tests are performed. 1) Capture and display video (PAL NTSC) from tvp5146 decoder. Displayed using fbdev device driver available on davinci git tree 2) Tested with driver built statically and dynamically Muralidhara Karicheri Reviewed by: Hans Verkuil hverk...@xs4all.nl Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be Reviewed by: Alexey Klimov klimov.li...@gmail.com Reviewed by: Kevin Hilman khil...@deeprootsystems.com Reviewed by: David Brownell davi...@pacbell.net Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- 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: Sakar 57379 USB Digital Video Camera...
On Fri, 19 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. And the upshot is that we may have the same camera, at least as a webcam, perhaps with a different name. I finally made mine to work in webcam mode. On mine, one has to press down a button labelled DV at the same time as pressing down the button with the picture of a camera beside it, to turn on the webcam mode. As opposed to just pressing the camera button to turn on the camera to shoot a picture. OK. I have two steps to take: 1. Installing the driver and software on my sole remaining Windows machine. It already has snoopy. 2. Getting the camera away from my daughter for more than 2 minutes. It's like the thing is glued to her hand. :) I hope that you can still manage to do these things. I did get a snoop log of my own, but it would be nice to have some confirmation, too, that the cameras really are acting the same way. That may look like a stupid thing to say until one realizes that things which have the same USB Vendor:Product number do _not_ necessarily act the same way. Well, here are some of the things I learned: As a stillcam, it is confirmed that my cam is a standard mass storage device, transparent SCSI, bulk. It uses outep 0x01 and inep 0x82 (the first pair of endpoints). Here it is as a mass storage device. T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0979 ProdID=0371 Rev= 1.00 S: Manufacturer=Jeilin S: Product=USB 1.1 Device S: SerialNumber=09790 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 4 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms and here it is as a webcam. T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 16 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0979 ProdID=0280 Rev= 1.00 S: Manufacturer=Jeilin S: Product=USB 1.1 Device C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 4 Cls=00(ifc ) Sub=00 Prot=00 Driver=(none) E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms Now it is using the other pair of endpoints, 0x03 and 0x84. There is a sequence of init commands : 71 81 : 70 05 : 95 70 : 00(all the 00 are responses) : 71 81 : 70 04 : 95 70 : 00 : 71 00 : 70 08 : 95 70 : 00 : 94 02 : de 24 : 94 02 : dd f0 : 94 02 : e3 2c : 94 02 : e4 00 : 94 02 : e5 00 : e5 00 : 94 02 : e6 2c : 94 03 : aa 00 : 71 1e : 70 06 : 71 80 : 70 07 and then it starts to stream. The stream downloads 0x200 (512) bytes at a time. It appears that there is an SOF marker consisting of ff ff ff ff followed by at least two zeroes. These seem to occur only at the beginnings of some of the downloaded 0x200-sized blocks. There is a closing sequence at the end which is similar to the init sequence : 71 00 : 70 09 : 71 80 : 70 05 It would be interesting to see your log file and to compare. I could also send you this one if you are curious, but it is 5,760,902 bytes so I should ask that if you want to see it then how to send it? Me, I suspect that if you have one of similar size
Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.
Am Donnerstag, den 18.06.2009, 20:39 -0500 schrieb Yufei Yuan:
This one is about the utility itself. I do apologize for the length
here as inline patch is preferred according to the guide and I don't
have any public online storage. Please let me know if this causes any
inconvenience.
Signed-off-by: Yufei Yuan yfy...@gmail.com
diff -uprN dvb-apps/util/atsc_epg/atsc_epg.c
dvb-apps_new/util/atsc_epg/atsc_epg.c
--- dvb-apps/util/atsc_epg/atsc_epg.c 1969-12-31 18:00:00.0
-0600
+++ dvb-apps_new/util/atsc_epg/atsc_epg.c 2009-06-18
20:17:24.527925142 -0500
@@ -0,0 +1,1249 @@
+/*
+ * atsc_epg utility
+ *
+ * Copyright (C) 2009 Yufei Yuan yfy...@gmail.com
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include time.h
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include sys/ioctl.h
+#include sys/poll.h
+#include errno.h
+#include getopt.h
+#include stdarg.h
+#include libdvbapi/dvbfe.h
+#include libdvbapi/dvbdemux.h
+#include libucsi/dvb/section.h
+#include libucsi/atsc/section.h
+#include libucsi/atsc/types.h
+
+#define TIMEOUT60
+#define RRT_TIMEOUT60
+#define MAX_NUM_EVENT_TABLES 128
+#define TITLE_BUFFER_LEN 4096
+#define MESSAGE_BUFFER_LEN (16 * 1024)
+#define MAX_NUM_CHANNELS 16
+#define MAX_NUM_EVENTS_PER_CHANNEL (4 * 24 * 7)
+
+static int atsc_scan_table(int dmxfd, uint16_t pid, enum
atsc_section_tag tag,
+ void **table_section);
+
+static const char *program;
+static int adapter = 0;
+static int period = 12; /* hours */
+static int frequency;
+static int enable_ett = 0;
+static int ctrl_c = 0;
+static const char *modulation = NULL;
+static char separator[80];
+void (*old_handler)(int);
+
+struct atsc_string_buffer {
+ int buf_len;
+ int buf_pos;
+ char *string;
+};
+
+struct atsc_event_info {
+ uint16_t id;
+ struct tm start;
+ struct tm end;
+ int title_pos;
+ int title_len;
+ int msg_pos;
+ int msg_len;
+};
+
+struct atsc_eit_section_info {
+ uint8_t section_num;
+ uint8_t num_events;
+ uint8_t num_etms;
+ uint8_t num_received_etms;
+ struct atsc_event_info **events;
+};
+
+struct atsc_eit_info {
+ int num_eit_sections;
+ struct atsc_eit_section_info *section;
+};
+
+struct atsc_channel_info {
+ uint8_t num_eits;
+ uint8_t service_type;
+ char short_name[8];
+ uint16_t major_num;
+ uint16_t minor_num;
+ uint16_t tsid;
+ uint16_t prog_num;
+ uint16_t src_id;
+ struct atsc_eit_info *eit;
+ struct atsc_event_info *last_event;
+ int event_info_index;
+ struct atsc_event_info e[MAX_NUM_EVENTS_PER_CHANNEL];
+ struct atsc_string_buffer title_buf;
+ struct atsc_string_buffer msg_buf;
+};
+
+struct atsc_virtual_channels_info {
+ int num_channels;
+ uint16_t eit_pid[MAX_NUM_EVENT_TABLES];
+ uint16_t ett_pid[MAX_NUM_EVENT_TABLES];
+ struct atsc_channel_info ch[MAX_NUM_CHANNELS];
+} guide;
+
+struct mgt_table_name {
+ uint16_t range;
+ const char *string;
+};
+
+struct mgt_table_name mgt_tab_name_array[] = {
+ {0x, terrestrial VCT with current_next_indictor=1},
+ {0x0001, terrestrial VCT with current_next_indictor=0},
+ {0x0002, cable VCT with current_next_indictor=1},
+ {0x0003, cable VCT with current_next_indictor=0},
+ {0x0004, channel ETT},
+ {0x0005, DCCSCT},
+ {0x00FF, reserved for future ATSC use},
+ {0x017F, EIT},
+ {0x01FF, reserved for future ATSC use},
+ {0x027F, event ETT},
+ {0x02FF, reserved for future ATSC use}, /* FIXME */
+ {0x03FF, RRT with rating region},
+ {0x0FFF, user private},
+ {0x13FF, reserved for future ATSC use},
+ {0x14FF, DCCT with dcc_id},
+ {0x, reserved for future ATSC use}
+};
+
+const char *channel_modulation_mode[] = {
+ ,
+ analog,
+ SCTE mode 1,
+ SCTE mode 2,
+ ATSC 8VSB,
Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.
Thanks for your time. It's my first time to do this, so I have been
trying to follow literally on the wiki page to do it right. If you can
elaborate a bit about what is broken? Is it the patch created
incorrectly, or it is pasted incorrectly, or the style is still
problematic?
I noticed that cutting and pasting from my console to the gmail
compose window does not seem working alright. How do you normally do
the inlining?
I have a full weekend to do this, and I do realize from the wiki page
that it does not appear to be simple, :)
I now simply disable the footer, don't worry.
Regards,
On Fri, Jun 19, 2009 at 7:41 PM, hermann pittonhermann-pit...@arcor.de wrote:
Am Donnerstag, den 18.06.2009, 20:39 -0500 schrieb Yufei Yuan:
This one is about the utility itself. I do apologize for the length
here as inline patch is preferred according to the guide and I don't
have any public online storage. Please let me know if this causes any
inconvenience.
Signed-off-by: Yufei Yuan yfy...@gmail.com
diff -uprN dvb-apps/util/atsc_epg/atsc_epg.c
dvb-apps_new/util/atsc_epg/atsc_epg.c
--- dvb-apps/util/atsc_epg/atsc_epg.c 1969-12-31 18:00:00.0
-0600
+++ dvb-apps_new/util/atsc_epg/atsc_epg.c 2009-06-18
20:17:24.527925142 -0500
@@ -0,0 +1,1249 @@
+/*
+ * atsc_epg utility
+ *
+ * Copyright (C) 2009 Yufei Yuan yfy...@gmail.com
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include time.h
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include sys/ioctl.h
+#include sys/poll.h
+#include errno.h
+#include getopt.h
+#include stdarg.h
+#include libdvbapi/dvbfe.h
+#include libdvbapi/dvbdemux.h
+#include libucsi/dvb/section.h
+#include libucsi/atsc/section.h
+#include libucsi/atsc/types.h
+
+#define TIMEOUT 60
+#define RRT_TIMEOUT 60
+#define MAX_NUM_EVENT_TABLES 128
+#define TITLE_BUFFER_LEN 4096
+#define MESSAGE_BUFFER_LEN (16 * 1024)
+#define MAX_NUM_CHANNELS 16
+#define MAX_NUM_EVENTS_PER_CHANNEL (4 * 24 * 7)
+
+static int atsc_scan_table(int dmxfd, uint16_t pid, enum
atsc_section_tag tag,
+ void **table_section);
+
+static const char *program;
+static int adapter = 0;
+static int period = 12; /* hours */
+static int frequency;
+static int enable_ett = 0;
+static int ctrl_c = 0;
+static const char *modulation = NULL;
+static char separator[80];
+void (*old_handler)(int);
+
+struct atsc_string_buffer {
+ int buf_len;
+ int buf_pos;
+ char *string;
+};
+
+struct atsc_event_info {
+ uint16_t id;
+ struct tm start;
+ struct tm end;
+ int title_pos;
+ int title_len;
+ int msg_pos;
+ int msg_len;
+};
+
+struct atsc_eit_section_info {
+ uint8_t section_num;
+ uint8_t num_events;
+ uint8_t num_etms;
+ uint8_t num_received_etms;
+ struct atsc_event_info **events;
+};
+
+struct atsc_eit_info {
+ int num_eit_sections;
+ struct atsc_eit_section_info *section;
+};
+
+struct atsc_channel_info {
+ uint8_t num_eits;
+ uint8_t service_type;
+ char short_name[8];
+ uint16_t major_num;
+ uint16_t minor_num;
+ uint16_t tsid;
+ uint16_t prog_num;
+ uint16_t src_id;
+ struct atsc_eit_info *eit;
+ struct atsc_event_info *last_event;
+ int event_info_index;
+ struct atsc_event_info e[MAX_NUM_EVENTS_PER_CHANNEL];
+ struct atsc_string_buffer title_buf;
+ struct atsc_string_buffer msg_buf;
+};
+
+struct atsc_virtual_channels_info {
+ int num_channels;
+ uint16_t eit_pid[MAX_NUM_EVENT_TABLES];
+ uint16_t ett_pid[MAX_NUM_EVENT_TABLES];
+ struct atsc_channel_info ch[MAX_NUM_CHANNELS];
+} guide;
+
+struct mgt_table_name {
+ uint16_t range;
+ const char *string;
+};
+
+struct mgt_table_name mgt_tab_name_array[] = {
+ {0x, terrestrial VCT with current_next_indictor=1},
+ {0x0001, terrestrial VCT with current_next_indictor=0},
+ {0x0002, cable VCT with current_next_indictor=1},
+
Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.
Hi,
Am Freitag, den 19.06.2009, 20:00 -0500 schrieb Yufei Yuan:
Thanks for your time. It's my first time to do this, so I have been
trying to follow literally on the wiki page to do it right. If you can
elaborate a bit about what is broken? Is it the patch created
incorrectly, or it is pasted incorrectly, or the style is still
problematic?
I noticed that cutting and pasting from my console to the gmail
compose window does not seem working alright. How do you normally do
the inlining?
I have a full weekend to do this, and I do realize from the wiki page
that it does not appear to be simple, :)
I now simply disable the footer, don't worry.
Just keep it on your decision. I'm not against to learn from the past.
It starts with lots of broken lines.
Cheers,
Hermann
Regards,
On Fri, Jun 19, 2009 at 7:41 PM, hermann pittonhermann-pit...@arcor.de
wrote:
Am Donnerstag, den 18.06.2009, 20:39 -0500 schrieb Yufei Yuan:
This one is about the utility itself. I do apologize for the length
here as inline patch is preferred according to the guide and I don't
have any public online storage. Please let me know if this causes any
inconvenience.
Signed-off-by: Yufei Yuan yfy...@gmail.com
diff -uprN dvb-apps/util/atsc_epg/atsc_epg.c
dvb-apps_new/util/atsc_epg/atsc_epg.c
--- dvb-apps/util/atsc_epg/atsc_epg.c 1969-12-31 18:00:00.0
-0600
+++ dvb-apps_new/util/atsc_epg/atsc_epg.c 2009-06-18
20:17:24.527925142 -0500
@@ -0,0 +1,1249 @@
+/*
+ * atsc_epg utility
+ *
+ * Copyright (C) 2009 Yufei Yuan yfy...@gmail.com
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include time.h
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include sys/ioctl.h
+#include sys/poll.h
+#include errno.h
+#include getopt.h
+#include stdarg.h
+#include libdvbapi/dvbfe.h
+#include libdvbapi/dvbdemux.h
+#include libucsi/dvb/section.h
+#include libucsi/atsc/section.h
+#include libucsi/atsc/types.h
+
+#define TIMEOUT60
+#define RRT_TIMEOUT60
+#define MAX_NUM_EVENT_TABLES 128
+#define TITLE_BUFFER_LEN 4096
+#define MESSAGE_BUFFER_LEN (16 * 1024)
+#define MAX_NUM_CHANNELS 16
+#define MAX_NUM_EVENTS_PER_CHANNEL (4 * 24 * 7)
+
+static int atsc_scan_table(int dmxfd, uint16_t pid, enum
atsc_section_tag tag,
+ void **table_section);
+
+static const char *program;
+static int adapter = 0;
+static int period = 12; /* hours */
+static int frequency;
+static int enable_ett = 0;
+static int ctrl_c = 0;
+static const char *modulation = NULL;
+static char separator[80];
+void (*old_handler)(int);
+
+struct atsc_string_buffer {
+ int buf_len;
+ int buf_pos;
+ char *string;
+};
+
+struct atsc_event_info {
+ uint16_t id;
+ struct tm start;
+ struct tm end;
+ int title_pos;
+ int title_len;
+ int msg_pos;
+ int msg_len;
+};
+
+struct atsc_eit_section_info {
+ uint8_t section_num;
+ uint8_t num_events;
+ uint8_t num_etms;
+ uint8_t num_received_etms;
+ struct atsc_event_info **events;
+};
+
+struct atsc_eit_info {
+ int num_eit_sections;
+ struct atsc_eit_section_info *section;
+};
+
+struct atsc_channel_info {
+ uint8_t num_eits;
+ uint8_t service_type;
+ char short_name[8];
+ uint16_t major_num;
+ uint16_t minor_num;
+ uint16_t tsid;
+ uint16_t prog_num;
+ uint16_t src_id;
+ struct atsc_eit_info *eit;
+ struct atsc_event_info *last_event;
+ int event_info_index;
+ struct atsc_event_info e[MAX_NUM_EVENTS_PER_CHANNEL];
+ struct atsc_string_buffer title_buf;
+ struct atsc_string_buffer msg_buf;
+};
+
+struct atsc_virtual_channels_info {
+ int num_channels;
+ uint16_t eit_pid[MAX_NUM_EVENT_TABLES];
+ uint16_t ett_pid[MAX_NUM_EVENT_TABLES];
+ struct atsc_channel_info ch[MAX_NUM_CHANNELS];
+}
Re: [linux-dvb] Support for Compro VideoMate S350
Hello Guys, I have one of these paper weights - that is a S350 , it has been sitting on the shelf for the past 2 years . And I would really like to use it . We have a driver for it here : http://article.gmane.org/gmane.linux.drivers.dvb/38163 . Please what needs to be done to get this driver merged into the tree ? C'mon guys lets get this one in . Best Regards Milorad -- 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: Sakar 57379 USB Digital Video Camera...
On Fri, 2009-06-19 at 19:26 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. And the upshot is that we may have the same camera, at least as a webcam, perhaps with a different name. I finally made mine to work in webcam mode. On mine, one has to press down a button labelled DV at the same time as pressing down the button with the picture of a camera beside it, to turn on the webcam mode. As opposed to just pressing the camera button to turn on the camera to shoot a picture. Ah, very nice. The secret handshake that only the manual (usually lost) can tell you. OK. I have two steps to take: 1. Installing the driver and software on my sole remaining Windows machine. It already has snoopy. 2. Getting the camera away from my daughter for more than 2 minutes. It's like the thing is glued to her hand. :) I hope that you can still manage to do these things. I did get a snoop log of my own, but it would be nice to have some confirmation, too, that the cameras really are acting the same way. That may look like a stupid thing to say until one realizes that things which have the same USB Vendor:Product number do _not_ necessarily act the same way. Yes. I might need a little time. This weekend is Father's day, and I got to go see family tomorrow and will be hosting more family on Saturday evening and Sunday. I doubt I'll have time to look at this before Sunday night (and by then I suspect I'll be drinking beer. :)) I did let gThumb import some files from my daughter's camera (Ireally should have pulled them over myself from the mass storage drive). Here's how they ended up: $ file * 1.jpg: JPEG image data, EXIF standard 2.2 2.jpg: JPEG image data, EXIF standard 2.2 3.jpg: JPEG image data, EXIF standard 2.2 4.avi: RIFF (little-endian) data, AVI, 320 x 240, 20.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 8000 Hz) 5.jpg: JPEG image data, EXIF standard 2.2 6.jpg: JPEG image data, EXIF standard 2.2 7.jpg: JPEG image data, EXIF standard 2.2 8.jpg: JPEG image data, EXIF standard 2.2 9.jpg: JPEG image data, EXIF standard 2.2 00010.jpg: JPEG image data, EXIF standard 2.2 All the photos were JPEGs and the movie was playable. Totem/gstreamer did a much better job of playing back the audio in the movie than mplayer. Surprising to me, but 8 ksps mono is just awful anyway. Well, here are some of the things I learned: As a stillcam, it is confirmed that my cam is a standard mass storage device, transparent SCSI, bulk. It uses outep 0x01 and inep 0x82 (the first pair of endpoints). Here it is as a mass storage device. T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0979 ProdID=0371 Rev= 1.00 S: Manufacturer=Jeilin S: Product=USB 1.1 Device S: SerialNumber=09790 ^ So much for a unique serial number. I haven't checked mine yet, but I bet it's the same. C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 4 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms and here it is as a webcam. T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 16 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0979 ProdID=0280 Rev= 1.00 S: Manufacturer=Jeilin S: Product=USB 1.1 Device C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 4 Cls=00(ifc ) Sub=00 Prot=00 Driver=(none) E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.
Ok, let me first summarize what I have done in order not to waste your time
again. I used Evolution client,
used preformatted option, sent it to my other email box, forwarded it back and
saved it as text file, then
patched the original tree, so far everything looks okay. Hopefully you guys can
do start to do next step.
I do apologize for your wasted time.
Signed-off-by: Yufei Yuan yfy...@gmail.com
diff -uprN dvb-apps/util/atsc_epg/atsc_epg.c
dvb-apps_new/util/atsc_epg/atsc_epg.c
--- dvb-apps/util/atsc_epg/atsc_epg.c 1969-12-31 18:00:00.0 -0600
+++ dvb-apps_new/util/atsc_epg/atsc_epg.c 2009-06-19 20:31:17.710924970
-0500
@@ -0,0 +1,1249 @@
+/*
+ * atsc_epg utility
+ *
+ * Copyright (C) 2009 Yufei Yuan yfy...@gmail.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include time.h
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include sys/ioctl.h
+#include sys/poll.h
+#include errno.h
+#include getopt.h
+#include stdarg.h
+#include libdvbapi/dvbfe.h
+#include libdvbapi/dvbdemux.h
+#include libucsi/dvb/section.h
+#include libucsi/atsc/section.h
+#include libucsi/atsc/types.h
+
+#define TIMEOUT60
+#define RRT_TIMEOUT60
+#define MAX_NUM_EVENT_TABLES 128
+#define TITLE_BUFFER_LEN 4096
+#define MESSAGE_BUFFER_LEN (16 * 1024)
+#define MAX_NUM_CHANNELS 16
+#define MAX_NUM_EVENTS_PER_CHANNEL (4 * 24 * 7)
+
+static int atsc_scan_table(int dmxfd, uint16_t pid, enum atsc_section_tag tag,
+ void **table_section);
+
+static const char *program;
+static int adapter = 0;
+static int period = 12; /* hours */
+static int frequency;
+static int enable_ett = 0;
+static int ctrl_c = 0;
+static const char *modulation = NULL;
+static char separator[80];
+void (*old_handler)(int);
+
+struct atsc_string_buffer {
+ int buf_len;
+ int buf_pos;
+ char *string;
+};
+
+struct atsc_event_info {
+ uint16_t id;
+ struct tm start;
+ struct tm end;
+ int title_pos;
+ int title_len;
+ int msg_pos;
+ int msg_len;
+};
+
+struct atsc_eit_section_info {
+ uint8_t section_num;
+ uint8_t num_events;
+ uint8_t num_etms;
+ uint8_t num_received_etms;
+ struct atsc_event_info **events;
+};
+
+struct atsc_eit_info {
+ int num_eit_sections;
+ struct atsc_eit_section_info *section;
+};
+
+struct atsc_channel_info {
+ uint8_t num_eits;
+ uint8_t service_type;
+ char short_name[8];
+ uint16_t major_num;
+ uint16_t minor_num;
+ uint16_t tsid;
+ uint16_t prog_num;
+ uint16_t src_id;
+ struct atsc_eit_info *eit;
+ struct atsc_event_info *last_event;
+ int event_info_index;
+ struct atsc_event_info e[MAX_NUM_EVENTS_PER_CHANNEL];
+ struct atsc_string_buffer title_buf;
+ struct atsc_string_buffer msg_buf;
+};
+
+struct atsc_virtual_channels_info {
+ int num_channels;
+ uint16_t eit_pid[MAX_NUM_EVENT_TABLES];
+ uint16_t ett_pid[MAX_NUM_EVENT_TABLES];
+ struct atsc_channel_info ch[MAX_NUM_CHANNELS];
+} guide;
+
+struct mgt_table_name {
+ uint16_t range;
+ const char *string;
+};
+
+struct mgt_table_name mgt_tab_name_array[] = {
+ {0x, terrestrial VCT with current_next_indictor=1},
+ {0x0001, terrestrial VCT with current_next_indictor=0},
+ {0x0002, cable VCT with current_next_indictor=1},
+ {0x0003, cable VCT with current_next_indictor=0},
+ {0x0004, channel ETT},
+ {0x0005, DCCSCT},
+ {0x00FF, reserved for future ATSC use},
+ {0x017F, EIT},
+ {0x01FF, reserved for future ATSC use},
+ {0x027F, event ETT},
+ {0x02FF, reserved for future ATSC use}, /* FIXME */
+ {0x03FF, RRT with rating region},
+ {0x0FFF, user private},
+ {0x13FF, reserved for future ATSC use},
+ {0x14FF, DCCT with dcc_id},
+ {0x, reserved for future ATSC use}
+};
+
+const char *channel_modulation_mode[] = {
+ ,
+ analog,
+ SCTE mode 1,
+ SCTE mode 2,
+ ATSC 8VSB,
+ ATSC 16VSB
+};
+
+const char *channel_service_type[] = {
+ ,
+
Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.
Am Freitag, den 19.06.2009, 21:38 -0500 schrieb Yufei Yuan:
Ok, let me first summarize what I have done in order not to waste your time
again. I used Evolution client,
used preformatted option, sent it to my other email box, forwarded it back
and saved it as text file, then
patched the original tree, so far everything looks okay. Hopefully you guys
can do start to do next step.
I do apologize for your wasted time.
Signed-off-by: Yufei Yuan yfy...@gmail.com
Manu,
please review.
Hermann
diff -uprN dvb-apps/util/atsc_epg/atsc_epg.c
dvb-apps_new/util/atsc_epg/atsc_epg.c
--- dvb-apps/util/atsc_epg/atsc_epg.c 1969-12-31 18:00:00.0 -0600
+++ dvb-apps_new/util/atsc_epg/atsc_epg.c 2009-06-19 20:31:17.710924970
-0500
@@ -0,0 +1,1249 @@
+/*
+ * atsc_epg utility
+ *
+ * Copyright (C) 2009 Yufei Yuan yfy...@gmail.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include time.h
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include sys/ioctl.h
+#include sys/poll.h
+#include errno.h
+#include getopt.h
+#include stdarg.h
+#include libdvbapi/dvbfe.h
+#include libdvbapi/dvbdemux.h
+#include libucsi/dvb/section.h
+#include libucsi/atsc/section.h
+#include libucsi/atsc/types.h
+
+#define TIMEOUT 60
+#define RRT_TIMEOUT 60
+#define MAX_NUM_EVENT_TABLES 128
+#define TITLE_BUFFER_LEN 4096
+#define MESSAGE_BUFFER_LEN (16 * 1024)
+#define MAX_NUM_CHANNELS 16
+#define MAX_NUM_EVENTS_PER_CHANNEL (4 * 24 * 7)
+
+static int atsc_scan_table(int dmxfd, uint16_t pid, enum atsc_section_tag
tag,
+ void **table_section);
+
+static const char *program;
+static int adapter = 0;
+static int period = 12; /* hours */
+static int frequency;
+static int enable_ett = 0;
+static int ctrl_c = 0;
+static const char *modulation = NULL;
+static char separator[80];
+void (*old_handler)(int);
+
+struct atsc_string_buffer {
+ int buf_len;
+ int buf_pos;
+ char *string;
+};
+
+struct atsc_event_info {
+ uint16_t id;
+ struct tm start;
+ struct tm end;
+ int title_pos;
+ int title_len;
+ int msg_pos;
+ int msg_len;
+};
+
+struct atsc_eit_section_info {
+ uint8_t section_num;
+ uint8_t num_events;
+ uint8_t num_etms;
+ uint8_t num_received_etms;
+ struct atsc_event_info **events;
+};
+
+struct atsc_eit_info {
+ int num_eit_sections;
+ struct atsc_eit_section_info *section;
+};
+
+struct atsc_channel_info {
+ uint8_t num_eits;
+ uint8_t service_type;
+ char short_name[8];
+ uint16_t major_num;
+ uint16_t minor_num;
+ uint16_t tsid;
+ uint16_t prog_num;
+ uint16_t src_id;
+ struct atsc_eit_info *eit;
+ struct atsc_event_info *last_event;
+ int event_info_index;
+ struct atsc_event_info e[MAX_NUM_EVENTS_PER_CHANNEL];
+ struct atsc_string_buffer title_buf;
+ struct atsc_string_buffer msg_buf;
+};
+
+struct atsc_virtual_channels_info {
+ int num_channels;
+ uint16_t eit_pid[MAX_NUM_EVENT_TABLES];
+ uint16_t ett_pid[MAX_NUM_EVENT_TABLES];
+ struct atsc_channel_info ch[MAX_NUM_CHANNELS];
+} guide;
+
+struct mgt_table_name {
+ uint16_t range;
+ const char *string;
+};
+
+struct mgt_table_name mgt_tab_name_array[] = {
+ {0x, terrestrial VCT with current_next_indictor=1},
+ {0x0001, terrestrial VCT with current_next_indictor=0},
+ {0x0002, cable VCT with current_next_indictor=1},
+ {0x0003, cable VCT with current_next_indictor=0},
+ {0x0004, channel ETT},
+ {0x0005, DCCSCT},
+ {0x00FF, reserved for future ATSC use},
+ {0x017F, EIT},
+ {0x01FF, reserved for future ATSC use},
+ {0x027F, event ETT},
+ {0x02FF, reserved for future ATSC use}, /* FIXME */
+ {0x03FF, RRT with rating region},
+ {0x0FFF, user private},
+ {0x13FF, reserved for future ATSC use},
+ {0x14FF, DCCT with dcc_id},
+ {0x, reserved for future ATSC use}
+};
+
+const char *channel_modulation_mode[] = {
+ ,
+ analog,
+ SCTE mode 1,
Re: Sakar 57379 USB Digital Video Camera...
On Fri, 19 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 19:26 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. And the upshot is that we may have the same camera, at least as a webcam, perhaps with a different name. I finally made mine to work in webcam mode. On mine, one has to press down a button labelled DV at the same time as pressing down the button with the picture of a camera beside it, to turn on the webcam mode. As opposed to just pressing the camera button to turn on the camera to shoot a picture. Ah, very nice. The secret handshake that only the manual (usually lost) can tell you. There is no longer any manual out there on the web. I looked. OK. I have two steps to take: 1. Installing the driver and software on my sole remaining Windows machine. It already has snoopy. 2. Getting the camera away from my daughter for more than 2 minutes. It's like the thing is glued to her hand. :) I hope that you can still manage to do these things. I did get a snoop log of my own, but it would be nice to have some confirmation, too, that the cameras really are acting the same way. That may look like a stupid thing to say until one realizes that things which have the same USB Vendor:Product number do _not_ necessarily act the same way. Yes. I might need a little time. This weekend is Father's day, and I got to go see family tomorrow and will be hosting more family on Saturday evening and Sunday. I doubt I'll have time to look at this before Sunday night (and by then I suspect I'll be drinking beer. :)) I did let gThumb import some files from my daughter's camera (Ireally should have pulled them over myself from the mass storage drive). Easily done. No problem with that at all. Here's how they ended up: $ file * 1.jpg: JPEG image data, EXIF standard 2.2 2.jpg: JPEG image data, EXIF standard 2.2 3.jpg: JPEG image data, EXIF standard 2.2 4.avi: RIFF (little-endian) data, AVI, 320 x 240, 20.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 8000 Hz) 5.jpg: JPEG image data, EXIF standard 2.2 6.jpg: JPEG image data, EXIF standard 2.2 7.jpg: JPEG image data, EXIF standard 2.2 8.jpg: JPEG image data, EXIF standard 2.2 9.jpg: JPEG image data, EXIF standard 2.2 00010.jpg: JPEG image data, EXIF standard 2.2 All the photos were JPEGs and the movie was playable. Totem/gstreamer did a much better job of playing back the audio in the movie than mplayer. Surprising to me, but 8 ksps mono is just awful anyway. Yes. The camera works perfectly in stilcam mode, as a mass storage device. Just mount it and treat it like a thumb drive. I tried the sound today, too, and the sound file is a .wav file. As far as my cam is concerned, I already knew all of this, but the camera has been gathering dust since 2005. Oh, it is convenient to take on a trip. So that has happened a couple of times. But otherwise it was not a very interesting camera. There is no challenge in a mass storage camera so I more or less forgot about it. Well, here are some of the things I learned: As a stillcam, it is confirmed that my cam is a standard mass storage device, transparent SCSI, bulk. It uses outep 0x01 and inep 0x82 (the first pair of endpoints). As I said, I was aware of this but did not remember the details, so this was all double-checking in order to clear up foggy memories. Here it is as a mass storage device. T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0979 ProdID=0371 Rev= 1.00 S: Manufacturer=Jeilin S: Product=USB 1.1 Device S: SerialNumber=09790 ^ So much for a unique serial number. I haven't checked mine yet, but I bet it's
