[linux-dvb] Looking for original source of an old DVB tree
Hello, Short version: I am looking for the original source code of a Linux DVB tree containing in particular drivers/media/dvb/dibusb/microtune_mt2060.c and the directory drivers/media/dvb/dibusb/mt2060_api Googling for microtune_mt2060.c and mt2060_api is no help. Could anyone kindly point me in the right direction, please? Longer version: I am trying to get my USB DVB-T stick running on my Xtreamer. Xtreamer uses an old 2.6.12.6 kernel heavily modified by Realtek and possibly also modified by MIPS. I have the source code but it would be a tremendous effort to change to a recent kernel. The DVB subtree seems to have been dirtily hacked by Realtek to support their frontends. In the process they seem to have lost support for other frontends. I have been trying to find the source code for the original version. I have found nothing resembling it in kernel.org, linux-mips.org and linuxtv.org. TIA. Cheers, Chris -- 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: CI USB
On Sun, Jan 24, 2010 at 11:49 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) No CI+ in there ... Generic USB bridge with microcontroller and possibly a FPGA programmed by Hauppauge themselves, most probably. The bridge would be similar to other DVB USB devices, Application on the FPGA would be more or less similar to the one found on general DVB CI devices. If it's not a Masked FPGA, it would need to load it's instructions some place, maybe an EEPROM or maybe from the firmware that you need load itself. Some part of the firmware that you load could be partly for the microcontroller on the USB bridge as well. Manu -- 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] sq905c: remove unused variable
On Sat, 23 Jan 2010 19:44:06 -0600 (CST) Theodore Kilgore kilg...@banach.math.auburn.edu wrote: If everyone else is agreeable, I would propose that the recent changes to sq905c.c should simply be pulled, and that is the best solution to the problem. A pull request for this change has been sent last sunday. Cheers. -- 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: CI USB
On Sun, Jan 24, 2010 at 10:12 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 11:49 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) No CI+ in there ... Generic USB bridge with microcontroller and possibly a FPGA programmed by Hauppauge themselves, most probably. The no, the whole Hauppauge device is actually made by SmartDTV even on the board there is a title SmartDTV Rev... also, Terratec device is the same as Hauppauge device, they even look the same: http://www.terratec.net/en/products/Cinergy_CI_USB_2296.html and Terratec driver for Windows says Copyright SmarDTV., which means it's made by SmarDTV. actually, Terratec driver for Windows is essentially the same as Hauppauge one, because firmware extracted from both drivers is the same (they update the firmware with driver updates, so matching versions of Terratec and Hauppauge driver is needed to check that the firmwares are the same). bridge would be similar to other DVB USB devices, Application on the FPGA would be more or less similar to the one found on general DVB CI devices. If it's not a Masked FPGA, it would need to load it's instructions some place, maybe an EEPROM or maybe from the firmware that you need load itself. Some part of the firmware that you load could be partly for the microcontroller on the USB bridge as well. i believe that 40 A3 firmware requests are for the USB controller and then the subsequent 40 A3 firmware requests are to load the FPGA instructions through the USB controller. Manu -- 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: CI USB
On Sun, Jan 24, 2010 at 10:54 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 10:12 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 11:49 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:43 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 24, 2010 at 1:45 AM, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: On Sat, Jan 23, 2010 at 1:31 AM, Manu Abraham abraham.m...@gmail.com wrote: On Sun, Jan 10, 2010 at 9:21 PM, Ian Wilkinson n...@sgtwilko.f9.co.uk wrote: HoP wrote: I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. If it is using a CI+ plus chip (I heard from someone that it is a CI+ chip inside) : http://www.smardtv.com/index.php?page=ciplus After reading the CI+ specifications, I doubt that it can be supported under Linux with open source support, without a paired decoder hardware or software decoder. A paired open source software decoder seems highly unlikely, as the output of the CI+ module is eventually an encrypted stream which can be descrambled with the relevant keys. The TS is not supposed to be stored on disk, or that's what the whole concept is for CI+ http://www.ci-plus.com/data/ci-plus_overview_v2009-07-06.pdf See pages 7, 8 , 12, 15 It could be possible to pair a software decoder with a key and hence under Windows, but under Linux I would really doubt it, if it happens to be a CI+ chip at least in Windows Hauppage WinTV-CI USB (which is OEM version of SmartDTV USB CI) allows you to capture the decrypted stream to your hard drive (i've just tested it). Maybe it is not CI+ itself in the first place so, i can't see a reason why even if it has CI+ chip inside same functionally as in Windows can't be provided in Linux if someone developed a driver. It would be interesting to know what chips the hardware has ... i can confirm the information here: * http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-CI and it contains: * an FX2 from Cypress (CY7C68013A) and a FPGA (Actel Proasic-plus, APA075-F) No CI+ in there ... Generic USB bridge with microcontroller and possibly a FPGA programmed by Hauppauge themselves, most probably. The no, the whole Hauppauge device is actually made by SmartDTV even on the board there is a title SmartDTV Rev... also, Terratec device is the same as Hauppauge device, they even look the same: http://www.terratec.net/en/products/Cinergy_CI_USB_2296.html and Terratec driver for Windows says Copyright SmarDTV., which means it's made by SmarDTV. actually, Terratec driver for Windows is essentially the same as Hauppauge one, because firmware extracted from both drivers is the same (they update the firmware with driver updates, so matching versions of Terratec and Hauppauge driver is needed to check that the firmwares are the same). bridge would be similar to other DVB USB devices, Application on the FPGA would be more or less similar to the one found on general DVB CI devices. If it's not a Masked FPGA, it would need to load it's instructions some place, maybe an EEPROM or maybe from the firmware that you need load itself. Some part of the firmware that you load could be partly for the microcontroller on the USB bridge as well. i believe that 40 A3 firmware requests are for the USB controller typo, 40 A0 firmware requests are for the USB controller and then the subsequent 40 A3 firmware requests are to load the FPGA instructions through the USB controller. Manu -- 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] dvb-apps/util/szap/czap.c ERROR: cannot parse service data
The czap utility (dvb-apps/util/szap/czap.c) cannot scan the channel configuration file when compiled on Fedora 12 with gcc-4.4.2. The czap output is: [kl...@myth2 szap]$ ./czap -c ~/.czap/ziggo-channels.conf Cartoon using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/local/klaas/.czap/ziggo-channels.conf' 1 Cartoon:35600:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:1660:1621 ERROR: cannot parse service data Problem is tha the sscanf function uses the %a[^:] format specifier. According to man sscanf you need to define _GNU_SOURCE if you want this to work because it is a gnu-only extension. Adding a first line #define _GNU_SOURCE to czap.c and recompiling solves the problem. The czap output is now: [kl...@myth2 szap]$ ./czap -c ~/.czap/ziggo-channels.conf Cartoon using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/local/klaas/.czap/ziggo-channels.conf' 1 Cartoon:35600:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:1660:1621 1 Cartoon: f 35600, s 6875000, i 2, fec 0, qam 3, v 0x67c, a 0x655 status 00 | signal | snr b7b7 | ber 000f | unc 0098 | status 1f | signal d5d5 | snr f3f3 | ber 06c0 | unc 009b | FE_HAS_LOCK status 1f | signal d5d5 | snr f4f4 | ber | unc | FE_HAS_LOCK This is done on a Linux 2.6.32.2 kernel with a TT C-1501 DVB-C card. Signed-off-by: Klaas de Waal klaas.de.w...@gmail.com --- diff -r 61b72047a995 util/szap/czap.c --- a/util/szap/czap.c Sun Jan 17 17:03:27 2010 +0100 +++ b/util/szap/czap.c Sun Jan 24 11:40:43 2010 +0100 @@ -1,3 +1,4 @@ +#define _GNU_SOURCE #include sys/types.h #include sys/stat.h #include sys/ioctl.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Looking for original source of an old DVB tree
On 01/24/2010 10:08 AM, Chris Moore wrote: Hello, Short version: I am looking for the original source code of a Linux DVB tree containing in particular drivers/media/dvb/dibusb/microtune_mt2060.c and the directory drivers/media/dvb/dibusb/mt2060_api Googling for microtune_mt2060.c and mt2060_api is no help. Could anyone kindly point me in the right direction, please? It is mt2060.c, mt2060_priv.h (IIRC) and mt2060.h. Longer version: I am trying to get my USB DVB-T stick running on my Xtreamer. Xtreamer uses an old 2.6.12.6 kernel heavily modified by Realtek and possibly also modified by MIPS. I have the source code but it would be a tremendous effort to change to a recent kernel. The DVB subtree seems to have been dirtily hacked by Realtek to support their frontends. In the process they seem to have lost support for other frontends. I have been trying to find the source code for the original version. I have found nothing resembling it in kernel.org, linux-mips.org and linuxtv.org. I am not sure what kind of device Xtreamer is, but try this: http://linuxtv.org/hg/~anttip/rtl2831u/ It is for Realtek RTL2831U + MT2060 based USB sticks. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 5/7] V4L: Events: Limit event queue length
Hans Verkuil wrote: Hi Sakari, Hi Hans, And thanks for the comments! ... @@ -103,7 +105,8 @@ int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event) ev = list_first_entry(events-available, struct _v4l2_event, list); list_del(ev-list); -ev-event.count = !list_empty(events-available); +atomic_dec(events-navailable); +ev-event.count = atomic_read(events-navailable); Combine these two lines to atomic_dec_return(). Will fix this. spin_unlock_irqrestore(events-lock, flags); @@ -159,6 +162,9 @@ void v4l2_event_queue(struct video_device *vdev, struct v4l2_event *ev) if (!v4l2_event_subscribed(fh, ev-type)) continue; +if (atomic_read(fh-events.navailable) = V4L2_MAX_EVENTS) +continue; + _ev = kmem_cache_alloc(event_kmem, GFP_ATOMIC); if (!_ev) continue; @@ -169,6 +175,8 @@ void v4l2_event_queue(struct video_device *vdev, struct v4l2_event *ev) list_add_tail(_ev-list, fh-events.available); spin_unlock(fh-events.lock); +atomic_inc(fh-events.navailable); + wake_up_all(fh-events.wait); } diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h index b11de92..69305c6 100644 --- a/include/media/v4l2-event.h +++ b/include/media/v4l2-event.h @@ -28,6 +28,10 @@ #include linux/types.h #include linux/videodev2.h +#include asm/atomic.h + +#define V4L2_MAX_EVENTS1024 /* Ought to be enough for everyone. */ I think this should be programmable by the driver. Most drivers do not use events at all, so by default it should be 0 or perhaps it can check whether the ioctl callback structure contains the event ioctls and set it to 0 or some initial default value. Right. I'll make the event queue size to be defined by the driver. I'm now planning to make a queue for free events common to file handles in video device. A statically allocated queue for each file handle is probably too much overkill. But a device global queue also means that a process that doesn't dequeue its events will starve the others. And you want this to be controlled on a per-filehandle basis even. If I look at ivtv, then most of the device nodes will not have events, only a few will support events. And for one device node type I know that there will only be a single event when stopping the streaming, while another device node type will get an event each frame. Instead of initialising the events by the V4L2, the driver could do this and specify the queue size at the same time. The overhead for the drivers not using events would be the event information in the video_device structure. That could be made a pointer as well. So being able to adjust the event queue dynamically will give more control and prevent unnecessary waste of memory resources. This sounds to me like trying to re-invent the kmem_cache now. :-) If the event queue is allocated in some other means than kmem_cache I think the size should be fixed. The driver probably knows the best what's the reasonable maximum event queue size and that could be allocated statically. If that overflows then so be it. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] media: dvb/af9015, implement eeprom hashing
Hei,
Comments below.
On 01/22/2010 05:10 PM, Jiri Slaby wrote:
We read the eeprom anyway for dumping. Switch the dumping to
print_hex_dump_bytes and compute hash above that by
hash = 0;
for (u32 VAL) in (eeprom):
hash *= GOLDEN_RATIO_PRIME_32
hash += VAL; // while preserving endinaness
The computation is moved earlier to the flow, namely from
af9015_af9013_frontend_attach to af9015_read_config, so that
we can access the sum in af9015_read_config already.
Signed-off-by: Jiri Slabyjsl...@suse.cz
Cc: Antti Palosaaricr...@iki.fi
Cc: Mauro Carvalho Chehabmche...@redhat.com
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/af9015.c | 65 +++
drivers/media/dvb/dvb-usb/af9015.h |1 +
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index a365c05..616b3ba 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -21,6 +21,8 @@
*
*/
+#includelinux/hash.h
+
#include af9015.h
#include af9013.h
#include mt2060.h
@@ -553,26 +555,45 @@ exit:
return ret;
}
-/* dump eeprom */
-static int af9015_eeprom_dump(struct dvb_usb_device *d)
+/* hash (and dump) eeprom */
+static int af9015_eeprom_hash(struct usb_device *udev)
{
- u8 reg, val;
+ static const unsigned int eeprom_size = 256;
+ unsigned int reg;
+ int ret;
+ u8 val, *eeprom;
+ struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1,val};
- for (reg = 0; ; reg++) {
- if (reg % 16 == 0) {
- if (reg)
- deb_info(KERN_CONT \n);
- deb_info(KERN_DEBUG %02x:, reg);
- }
- if (af9015_read_reg_i2c(d, AF9015_I2C_EEPROM, reg,val) == 0)
- deb_info(KERN_CONT %02x, val);
- else
- deb_info(KERN_CONT --);
- if (reg == 0xff)
- break;
+ eeprom = kmalloc(eeprom_size, GFP_KERNEL);
+ if (eeprom == NULL)
+ return -ENOMEM;
+
+ for (reg = 0; reg eeprom_size; reg++) {
+ req.addr = reg;
+ ret = af9015_rw_udev(udev,req);
+ if (ret)
+ goto free;
+ eeprom[reg] = val;
}
- deb_info(KERN_CONT \n);
- return 0;
+
+ if (dvb_usb_af9015_debug 0x01)
+ print_hex_dump_bytes(, DUMP_PREFIX_OFFSET, eeprom,
+ eeprom_size);
+
+ BUG_ON(eeprom_size % 4);
+
+ af9015_config.eeprom_sum = 0;
+ for (reg = 0; reg eeprom_size / sizeof(u32); reg++) {
+ af9015_config.eeprom_sum *= GOLDEN_RATIO_PRIME_32;
+ af9015_config.eeprom_sum += le32_to_cpu(((u32 *)eeprom)[reg]);
+ }
+
+ deb_info(%s: eeprom sum=%.8x\n, __func__, af9015_config.eeprom_sum);
Does this sum contain all 256 bytes from EEPROM? 256/4 is 64.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] media: dvb/af9015, implement eeprom hashing
On 01/24/2010 05:16 PM, Antti Palosaari wrote:
+af9015_config.eeprom_sum = 0;
+for (reg = 0; reg eeprom_size / sizeof(u32); reg++) {
+af9015_config.eeprom_sum *= GOLDEN_RATIO_PRIME_32;
+af9015_config.eeprom_sum += le32_to_cpu(((u32 *)eeprom)[reg]);
+}
+
+deb_info(%s: eeprom sum=%.8x\n, __func__,
af9015_config.eeprom_sum);
Does this sum contain all 256 bytes from EEPROM? 256/4 is 64.
Yes it does. It is computed as a hashed sum of 32-bit numbers (4 bytes)
-- speed (does not matter) and larger space of hashes. Hence the
division by 4. The cast does the trick: ((u32 *)eeprom)[reg] -- reg
index is on a 4-byte basis.
regards,
--
js
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC, PATCH] gspca pac7302: propagate footer to userspace
Hi, I'm dealing with Labtec Webcam 2200 and I found that the pac7302 driver does not forward the image footer information to userspace. This footer contains some information which might be interesting to the userspace. What exactly this footer means is not clear as of this writing, but it is easier to analyze the data in userspace than in kernel space. I modified the sd_pkt_scan() in order the footer is transfered to the userspace together with the image. This, however, breaks the image decoding in libv4lconvert. This is can be easily solved by passing the image buffer to v4lconvert_convert() truncated by 0x4f bytes. What do you think the right way would be to transfer image footer to userspace? Is it necessary to add a new V4L2_PIX_FMT_* format in order not to brake userspace programs? PAC7302 footer structure I could figure out so far is: Offset | Length |Description ---++-- 0x0 | 1| Seen values: 0x10, 0x11, 0x12, 0x13, 0x15, 0x16 || Some kind of sequence number or timestamp? ---++-- 0x1 | 1| Seen values: 0x50 ---++-- 0x2 | 1| Seen values: 0x00 ---++-- 0x3 | 1| Seen values: 0x00 ---++-- 0x4 | 1| Seen values: 0x00 ---++-- 0x5 | 1| Seen values: 0x00 ---++-- 0x6 | 25 | Picutre lumination related bytes. || The gain setting has influcence on the values || In test modes: || test mode 1 (white): filled with 0xFE || test mode 2 (black): filled with 0x00 || test mode 3 (red): filled with 0x4C || test mode 4 (green): filled with 0x96 || test mode 5 (blue):filled with 0x1C || test mode 6 (cyan):filled with 0xB3 || test mode 7 (magenta): filled with 0x69 || test mode 8 (yellow): filled with 0xE1 || test mode 9 (color bars): || 9B 6A 7B B1 52 71 68 6B 76 62 9F 9F 9F 9F 9F 8D 61 70 A1 4B 99 6A 7A AF 52 || test mode 10 (high resolution color pattern): || A8 AC A5 A6 A6 A3 A3 A1 A2 A4 A2 9F 9F A0 A5 A5 9F 9F 9C A5 A9 A5 A2 A2 A7 || test mode 11 (black to white gradient from top to bottom): || 4B 6E 8A A4 BF 48 6A 85 9E B8 47 68 83 9C B5 47 69 84 9D B7 49 6C 88 A1 BC || test mode 12 (white to black gradient from left to right): || 5A 57 57 57 59 80 7D 7D 7D 80 A0 9D 9C 9C A0 BF BB BA BB BE DC D7 D6 D7 DB || test mode 13 (white to black gradient repeats from left to right): || A8 A5 A4 A5 A7 A4 A0 9F A0 A4 A4 A0 A2 A0 A3 A5 A2 A2 A1 A5 A5 A3 A2 A2 A5 || test mode 14 (dark gray): filled with 0x00 || test mode 15 (dark gray2): filled with 0x00 ---++-- 0x1f |1 | Seen: 0x00 ---++-- 0x20 |2 | Picture content related? ---++-- 0x22 |1 | Seen: 0x00 ---++-- 0x23 |2 | Compressed picture size related? ---++-- 0x25 |1 | Seen: 0x00 ---++-- 0x26 |1 | Seen: 0x00 ---++-- 0x27 |1 | Seen: 0x00 ---++-- 0x28 |4 | Picture content related? ---++-- 0x2c |4 | Picture content related? ---++-- 0x30 |4 | Picture content related? ---++-- 0x34 |4 | Picture content related? ---++-- 0x38 |1 | Seen: fixed 0x01 ---++-- 0x39 |1 | Seen: fixed 0xAE ---++-- 0x3a |1 | Seen: fixed 0x01 ---++-- 0x3b |1 | Seen: fixed 0x04 ---++-- 0x3c |1 | Seen: fixed 0x16 ---++-- 0x3d |1 | Seen: fixed 0x14
Re: gitorious.org/omap3camera: Falied attempt to migrate sensor driver to Zoom2/3 platform
Hi Sergio, On Friday 22 January 2010 19:36:06 Aguirre, Sergio wrote: [snip] Ok, I was able to work around the kernel panic with the attached patch. I have the feeling that all your development is dependant on loading all camera/sensors as modules in the filesystem. Have you done validation with built-in option in kernel's menuconfig? You're right. I haven't done any validation, and I've been to reproduce the crash when compiling everything directly into the kernel image. I'm on holidays this week so I won't be able to look into the problem before February the 1st. If nobody beats me to it, I'll see how we can fix it properly then. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sq905c: remove unused variable and other topics
On Sun, 24 Jan 2010, Jean-Francois Moine wrote:
On Sat, 23 Jan 2010 19:44:06 -0600 (CST)
Theodore Kilgore kilg...@banach.math.auburn.edu wrote:
If everyone else is agreeable, I would propose that the recent
changes to sq905c.c should simply be pulled, and that is the best
solution to the problem.
A pull request for this change has been sent last sunday.
Jean-Francois,
Thanks.
I would also like to address three other items.
1. For a long time I was not getting the mail from this list. I could
not figure out what was the matter, but I finally remember what happened:
I went on a two week vacation last summer, and I unsubscribed before I
left home, since I did not want to deal with what seemed like several
hundred messages a day piling up unread in my inbox. Then when I got back
I was too busy trying to catch up with work to remember to resubscribe.
Fixed, now.
2. I hope that when you got the sq905c changes that you also pulled the
changes for mr97310a.c. Several things have been done there recently.
First, there was a patch to the initialization for one of the types of
supported cameras. Without that patch the camera will work only on a host
machine with OHCI USB support and will fail to stream when hooked to a
host machine with a UHCI controller. There was a desperate, last minute
attempt to get this patch into 2.6.32, the urgency of which apparently
failed to convince the higher-ups and it did not get in. The only excuse
for the bad timing is the obvious one, that who could imagine that such a
problem could occur until actually confronted with it? It is just too
weird. I do not know the current status of this patch.
Second, other cleanups have been done to mr97310a.c
Third, another camera with yet another init sequence and control
capabilities has been discovered, and it is added to mr97310a.c
I would say that the most recent version of the mr97310a driver is the
best and most bug-free of the versions, and I hope it gets used.
3. The sn9c2028 driver. It runs the three sn9c2028 cameras that I have on
hand and does so pretty well.
I would characterize the driver as unfinished, though. For, there are at
least two cameras supported there which I do not and never did personally
own, and therefore I cannot test them. I do have init sequences which are
based upon snoops previously done, and I put those in the driver.
Unfortunately, I have been unable to get anyone else to test those two
cameras, either. Apparently, the only way to get them tested is to send
the driver mainstream. After that, perhaps I will get reports whether they
work, or not!
The two cameras in question which are untested or are incompletely tested
are (quoting from sn9c2028.c)
{USB_DEVICE(0x0458, 0x7005)}, /* Genius Smart 300, version 2 */
/* The Genius Smart is untested. I can't find an owner ! */
and
{USB_DEVICE(0x0c45, 0x8008)}, /* Mini-Shotz ms-350 */
where the owner tells me that the code I sent him works, but he can not do
more testing right now because he is too busy (wife is having first
child). The Mini-Shotz has obvious redundancies and bactrackings in the
init sequence which is used in the OEM driver. I would very much like to
be able to clean out all the crud which is in the OEM init sequence, but I
have no way to know exactly what is needed, without testing.
Thus, if anyone who reads this has either of the above sn9c2028 cameras or
any other one which is not currently supported at all, please contact me.
There is a lot of unfinished business with the sn9c2028 driver. I would
very much like for it to get done. But said work depends upon finding
owners and testers.
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
problem with libdvben50221 and powercam pro V4 [almost solved]
Hello Powercam just made a new version of their cam, the version 4 Unfortunately this CAM doesn't work with gnutv and applications based on libdvben50221 This cam return TIMEOUT errors (en50221_stdcam_llci_poll: Error reported by stack:-3) after showing the supported ressource id. I found out that this cam works with the test application of the libdvben50221 The problem is that this camreturns two times the list of supported ids (as shown in the log) this behavior make the llci_lookup_callback (en50221_stdcam_llci.c line 338) failing to give the good ressource_id at the second call because there is already a session number (in the test app the session number is not tested) I solved the problem commenting out the test for the session number as showed in the joined patch (against the latest dvb-apps, cloned today) Since I'm not an expert of the libdvben50221, I'm asking the list if there is better way to solve this problem and improve my patch so it can be integrated upstream. Thank you -- Brice DUBOST A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? diff -r 61b72047a995 lib/libdvben50221/en50221_stdcam_llci.c --- a/lib/libdvben50221/en50221_stdcam_llci.c Sun Jan 17 17:03:27 2010 +0100 +++ b/lib/libdvben50221/en50221_stdcam_llci.c Sun Jan 24 20:56:05 2010 +0100 @@ -334,8 +334,8 @@ return -3; break; case EN50221_APP_CA_RESOURCEID: -if (llci-stdcam.ca_session_number != -1) - return -3; +//if (llci-stdcam.ca_session_number != -1) +// return -3; break; case EN50221_APP_MMI_RESOURCEID: if (llci-stdcam.mmi_session_number != -1) Found a CAM on adapter1... waiting... en50221_tl_register_slot slotid: 0 tcid: 1 Press a key to enter menu 00:Host originated transport connection 1 connected 00:Public resource lookup callback 1 1 1 00:CAM connecting to resource 00010041, session_number 1 00:CAM successfully connected to resource 00010041, session_number 1 00:test_rm_reply_callback 00:test_rm_enq_callback 00:Public resource lookup callback 2 1 1 00:CAM connecting to resource 00020041, session_number 2 00:CAM successfully connected to resource 00020041, session_number 2 00:test_ai_callback Application type: 01 Application manufacturer: 02ca Manufacturer code: 3000 Menu string: PCAM V4.1 00:Public resource lookup callback 3 1 1 00:CAM connecting to resource 00030041, session_number 3 00:CAM successfully connected to resource 00030041, session_number 3 00:test_ca_info_callback Supported CA ID: 4aa1 Supported CA ID: 0100 Supported CA ID: 0500 Supported CA ID: 0600 Supported CA ID: 0601 Supported CA ID: 0602 Supported CA ID: 0603 Supported CA ID: 0604 Supported CA ID: 0606 Supported CA ID: 0608 Supported CA ID: 0614 Supported CA ID: 0620 Supported CA ID: 0622 Supported CA ID: 0624 Supported CA ID: 0626 Supported CA ID: 0628 Supported CA ID: 0668 Supported CA ID: 0619 Supported CA ID: 1702 Supported CA ID: 1722 Supported CA ID: 1762 Supported CA ID: 0b00 Supported CA ID: 0b01 Supported CA ID: 0b02 Supported CA ID: 0d00 Supported CA ID: 0d01 Supported CA ID: 0d02 Supported CA ID: 0d03 Supported CA ID: 0d04 Supported CA ID: 0d05 Supported CA ID: 0d06 Supported CA ID: 0d07 Supported CA ID: 0d08 Supported CA ID: 0d0c Supported CA ID: 0d0f Supported CA ID: 0d22 Supported CA ID: 0d70 Supported CA ID: 4aa0 00:Connection to resource 00030041, session_number 3 closed 00:Public resource lookup callback 3 1 1 00:CAM connecting to resource 00030041, session_number 3 00:CAM successfully connected to resource 00030041, session_number 3 00:test_ca_info_callback Supported CA ID: 4aa1 Supported CA ID: 0100 Supported CA ID: 0500 Supported CA ID: 0600 Supported CA ID: 0601 Supported CA ID: 0602 Supported CA ID: 0603 Supported CA ID: 0604 Supported CA ID: 0606 Supported CA ID: 0608 Supported CA ID: 0614 Supported CA ID: 0620 Supported CA ID: 0622 Supported CA ID: 0624 Supported CA ID: 0626 Supported CA ID: 0628 Supported CA ID: 0668 Supported CA ID: 0619 Supported CA ID: 1702 Supported CA ID: 1722 Supported CA ID: 1762 Supported CA ID: 0b00 Supported CA ID: 0b01 Supported CA ID: 0b02 Supported CA ID: 0d00 Supported CA ID: 0d01 Supported CA ID: 0d02 Supported CA ID: 0d03 Supported CA ID: 0d04 Supported CA ID: 0d05 Supported CA ID: 0d06 Supported CA ID: 0d07 Supported CA ID: 0d08 Supported CA ID: 0d0c Supported CA ID: 0d0f Supported CA ID: 0d22 Supported CA ID: 0d70 Supported CA ID: 4aa0 00:Public resource lookup callback 64 1 1 00:CAM connecting to resource 00400041, session_number 4 00:CAM successfully connected to resource 00400041, session_number 4 00:test_mmi_display_control_callback cmd_id: 01 mode: 01 00:test_mmi_menu_callback title: PCAM V4.1 sub_title: bottom: item 1: English item 2: French item 3: Spanish item 4: German item 5:
[PATCH] dvb-apps scan: fix zero transport stream id
scan sometimes returns services with transport stream id = 0. This
happens when the service is allocated before the transport stream
id is known. This patch simply makes copy_transponder propagate
transport stream id changes to all services of the transponder.
Symptoms of zero transport stream id include VDR not showing EPG.
Signed-off-by: Anssi Hannula anssi.hann...@iki.fi
---
Index: dvb-apps-1181/util/scan/scan.c
===
--- dvb-apps-1181/util/scan/scan.c
+++ dvb-apps-1181/util/scan/scan.c 2010-01-24 22:22:25.092513605 +0200
@@ -236,6 +236,17 @@
static void copy_transponder(struct transponder *d, struct transponder *s)
{
+ struct list_head *pos;
+ struct service *service;
+
+ if (d-transport_stream_id != s-transport_stream_id) {
+ /* propagate change to any already allocated services */
+ list_for_each(pos, d-services) {
+ service = list_entry(pos, struct service, list);
+ service-transport_stream_id = s-transport_stream_id;
+ }
+ }
+
d-network_id = s-network_id;
d-original_network_id = s-original_network_id;
d-transport_stream_id = s-transport_stream_id;
--
Anssi Hannula
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-apps/util/szap/czap.c ERROR: cannot parse service data
Hi Klaas, On Sun, Jan 24, 2010 at 2:58 PM, klaas de waal klaas.de.w...@gmail.com wrote: The czap utility (dvb-apps/util/szap/czap.c) cannot scan the channel configuration file when compiled on Fedora 12 with gcc-4.4.2. The czap output is: [kl...@myth2 szap]$ ./czap -c ~/.czap/ziggo-channels.conf Cartoon using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/local/klaas/.czap/ziggo-channels.conf' 1 Cartoon:35600:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:1660:1621 ERROR: cannot parse service data Problem is tha the sscanf function uses the %a[^:] format specifier. According to man sscanf you need to define _GNU_SOURCE if you want this to work because it is a gnu-only extension. Adding a first line #define _GNU_SOURCE to czap.c and recompiling solves the problem. The czap output is now: [kl...@myth2 szap]$ ./czap -c ~/.czap/ziggo-channels.conf Cartoon using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/local/klaas/.czap/ziggo-channels.conf' 1 Cartoon:35600:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:1660:1621 1 Cartoon: f 35600, s 6875000, i 2, fec 0, qam 3, v 0x67c, a 0x655 status 00 | signal | snr b7b7 | ber 000f | unc 0098 | status 1f | signal d5d5 | snr f3f3 | ber 06c0 | unc 009b | FE_HAS_LOCK status 1f | signal d5d5 | snr f4f4 | ber | unc | FE_HAS_LOCK This is done on a Linux 2.6.32.2 kernel with a TT C-1501 DVB-C card. Signed-off-by: Klaas de Waal klaas.de.w...@gmail.com --- diff -r 61b72047a995 util/szap/czap.c --- a/util/szap/czap.c Sun Jan 17 17:03:27 2010 +0100 +++ b/util/szap/czap.c Sun Jan 24 11:40:43 2010 +0100 @@ -1,3 +1,4 @@ +#define _GNU_SOURCE #include sys/types.h #include sys/stat.h #include sys/ioctl.h There seems to be other instances where _GNU_SOURCE needs to be defined, from a quick look. Care to send a patch against the entire dvb-apps tree ? Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-apps scan: fix zero transport stream id
On Mon, Jan 25, 2010 at 12:39 AM, Anssi Hannula anssi.hann...@iki.fi wrote:
scan sometimes returns services with transport stream id = 0. This
happens when the service is allocated before the transport stream
id is known. This patch simply makes copy_transponder propagate
transport stream id changes to all services of the transponder.
Symptoms of zero transport stream id include VDR not showing EPG.
Signed-off-by: Anssi Hannula anssi.hann...@iki.fi
---
Index: dvb-apps-1181/util/scan/scan.c
===
--- dvb-apps-1181/util/scan/scan.c
+++ dvb-apps-1181/util/scan/scan.c 2010-01-24 22:22:25.092513605 +0200
@@ -236,6 +236,17 @@
static void copy_transponder(struct transponder *d, struct transponder *s)
{
+ struct list_head *pos;
+ struct service *service;
+
+ if (d-transport_stream_id != s-transport_stream_id) {
+ /* propagate change to any already allocated services */
+ list_for_each(pos, d-services) {
+ service = list_entry(pos, struct service, list);
+ service-transport_stream_id = s-transport_stream_id;
+ }
+ }
+
d-network_id = s-network_id;
d-original_network_id = s-original_network_id;
d-transport_stream_id = s-transport_stream_id;
--
Anssi Hannula
--
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
Applied, Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git problem with uvcvideo
Hi, I'm trying to fetch the uvcvideo from http://linuxtv.org/git/?p=pinchartl/uvcvideo.git;a=summary . I tryied to follow the instructions but at the third step I get fatal error messages: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb Initialized empty Git repository in /usr/src/linuxtv.org/pinchartl/uvcvideo/v4l-dvb/.git/ remote: Counting objects: 1455151, done. remote: Compressing objects: 100% (233826/233826), done. remote: Total 1455151 (delta 1210384), reused 1455044 (delta 1210312) Receiving objects: 100% (1455151/1455151), 317.25 MiB | 224 KiB/s, done. Resolving deltas: 100% (1210384/1210384), done. Checking out files: 100% (31566/31566), done. $ cd v4l-dvb/ v4l-dvb$ git remote add uvcvideo http://linuxtv.org/git//pinchartl/uvcvideo.git v4l-dvb$ git remote update Updating origin Updating uvcvideo fatal: http://linuxtv.org/git//pinchartl/uvcvideo.git/info/refs not found: did you run git update-server-info on the server? error: Could not fetch uvcvideo I also tried with the git:// link: v4l-dvb$ git remote rm uvcvideo v4l-dvb$ git remote add uvcvideo git://linuxtv.org//pinchartl/uvcvideo.git v4l-dvb$ git remote update Updating origin Updating uvcvideo fatal: The remote end hung up unexpectedly error: Could not fetch uvcvideo Am I doing something wrong? Regards, Márton Németh -- 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: problem with libdvben50221 and powercam pro V4 [almost solved]
DUBOST Brice dubost at crans.ens-cachan.fr writes: Manu Abraham a écrit : Hi Brice, On Mon, Jan 25, 2010 at 12:09 AM, DUBOST Brice dubost at crans.ens-cachan.fr wrote: Hello Powercam just made a new version of their cam, the version 4 Unfortunately this CAM doesn't work with gnutv and applications based on libdvben50221 This cam return TIMEOUT errors (en50221_stdcam_llci_poll: Error reported by stack:-3) after showing the supported ressource id. The problem is that this camreturns two times the list of supported ids (as shown in the log) this behavior make the llci_lookup_callback (en50221_stdcam_llci.c line 338) failing to give the good ressource_id at the second call because there is already a session number (in the test app the session number is not tested) I solved the problem commenting out the test for the session number as showed in the joined patch (against the latest dvb-apps, cloned today) Very strange that, it responds twice on the same session. Btw, What DVB driver are you using ? budget_ci or budget_av ? Hello The card is a DVB: registering new adapter (TT-Budget S2-3200 PCI) and the driver used is budget_ci Do you want me to run some more tests ? Hello Manu, Hello Brice, I will run some tests with a TT3200 card too and a Netup card tomorrow. Regarding the cam returning two times the list of valid cam ids, wouldn't be better if the manufacturer corrects it in the cam firmware ? What says the en50221 norm about it ? Regards -- Pierre -- 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/1] media: dvb-usb/af9015, fix disconnection crashes
On 01/20/2010 07:19 PM, Jiri Slaby wrote: When both remote controller and receiver intfs are handled by af9015, .probe do nothing for remote intf, but when .disconnect is called for both of them it touches intfdata every time. For remote it crashes obviously (as intfdata are unset). Altough there is test against data being NULL, it is not enough. It is because someone before us does not set intf drvdata to NULL. (In this case the hid layer.) But we cannot rely on intf being NULL anyway. Fix that by checking bInterfaceNumber in af9015_usb_device_exit and do actually nothing if it is not 0. I was a little bit surprised when saw this error, why it haven't detected earlier. When I initially added interface check for .probe it was surely needed, it was creating two instances without that check in that time. When I now test this patch with debugs enabled I don't see .probe and .disconnect be called for this HID interface (interface 1) at all and thus checks not needed. I have Fedora Kernel 2.6.31.12 running with latest v4l-dvb. Is there now some kind of check added recently which blocks .probe and disconnect from HID interface? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] media: dvb/af9015, implement eeprom hashing
On 01/24/2010 06:35 PM, Jiri Slaby wrote:
On 01/24/2010 05:16 PM, Antti Palosaari wrote:
+af9015_config.eeprom_sum = 0;
+for (reg = 0; reg eeprom_size / sizeof(u32); reg++) {
+af9015_config.eeprom_sum *= GOLDEN_RATIO_PRIME_32;
+af9015_config.eeprom_sum += le32_to_cpu(((u32 *)eeprom)[reg]);
+}
+
+deb_info(%s: eeprom sum=%.8x\n, __func__,
af9015_config.eeprom_sum);
Does this sum contain all 256 bytes from EEPROM? 256/4 is 64.
Yes it does. It is computed as a hashed sum of 32-bit numbers (4 bytes)
-- speed (does not matter) and larger space of hashes. Hence the
division by 4. The cast does the trick: ((u32 *)eeprom)[reg] -- reg
index is on a 4-byte basis.
OK, true. Anyhow, I don't know if this hashing formula is good enough -
changing it later could be really pain. I compared it to the one used
for em28xx driver and it was different. Could someone with better
knowledge check that?
Generally it is good and ready for submission.
Acked-by: Antti Palosaari cr...@iki.fi
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] media: dvb/af9015, factor out remote setting
On 01/22/2010 05:10 PM, Jiri Slaby wrote: This is just a code shuffle without functional changes. For easier review of later changes, i.e. preparation. Signed-off-by: Jiri Slabyjsl...@suse.cz Cc: Antti Palosaaricr...@iki.fi Cc: Mauro Carvalho Chehabmche...@redhat.com Cc: linux-media@vger.kernel.org Acked-by: Antti Palosaari cr...@iki.fi -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] media: dvb/af9015, refactor remote setting
On 01/22/2010 05:10 PM, Jiri Slaby wrote: Add af9015_setup structure to hold (right now only remote) setup of distinct receivers. Add af9015_setup_match for matching ids against tables. This is for easier matching different kind of ids against tables to obtain setups. Currently module parameters and usb vendor ids are switched into and matched against tables. Hashes will follow. Signed-off-by: Jiri Slabyjsl...@suse.cz Cc: Antti Palosaaricr...@iki.fi Cc: Mauro Carvalho Chehabmche...@redhat.com Cc: linux-media@vger.kernel.org --- drivers/media/dvb/dvb-usb/af9015.c | 222 ++- 1 files changed, 89 insertions(+), 133 deletions(-) Acked-by: Antti Palosaari cr...@iki.fi -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] media: dvb/af9015, add hashes support
On 01/22/2010 05:10 PM, Jiri Slaby wrote: So as a final patch, add support for hash and one hash entry for MSI digi vox mini II: iManufacturer 1 Afatech iProduct 2 DVB-T 2 iSerial 3 01010101061 It is now handled with proper IR and key map tables. Signed-off-by: Jiri Slabyjsl...@suse.cz Cc: Antti Palosaaricr...@iki.fi Cc: Mauro Carvalho Chehabmche...@redhat.com Cc: linux-media@vger.kernel.org Signed-off-by: Jiri Slabyjsl...@suse.cz --- drivers/media/dvb/dvb-usb/af9015.c | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) Acked-by: Antti Palosaari cr...@iki.fi -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
More details on Hauppauge 930C
So far all the posts I have been able to find about this device on wiki.linuxtv.org and in the archives of the linux-tv, linux-dvb and linux-media mailing lists have been unconfirmed guesswork of the form I think, Isn't that etc. I actually have this device (it was the first DVB-C device to hit the market in Denmark after our biggest cable TV provider offered unencrypted access to their basic packages in DVB-C format for anyone with a paid physical connection to their network). Ok, first the bad news: When looking inside the device I see two Micronas chips, thus *apparantly* confirming the rumors about this device being based on the Micronas chips for which Micronas lawyers blocked release of an already written FOSS driver back in 2008. But to be sure these are the banned chips, someone in the know should look closely at the photos I have taken of the actual chips in the 930C. Second bad news: When asking Hauppauge all the response I got was You need to post on the www.linuxtv.org site, that's where the devlopers are (and thats all the e-mail said, including the spelling mistake in devlopers). Now the observable facts: 1. Product name is Hauppauge 930C, model 16009 LF Rev B1F0, USB ID 2040:1605 . Retail package includes device, a short video cable adapter for the minisocket on the device, an IR remote, a small table-top retractable antenna and a CD with MS-Windows software and drivers. 2. Device is a combined DVB-C/DVB-T receiver with additional inputs for raw analog video as S-VHS or composite (either with separate analog stereo sound). I do not recall if the device has support for analog TV reception too. 3. Device is not yet listed in the device tables at linuxtv.org with any status (not even doesn't work). 4. Device is a large (= wide body) USB stick, with a standard size coaxial antenna input at the back, two indicator LEDs and an IR receiver on the right and a proprietary mini-socket for analog video/audio input on the left. The underside has a sticker with bar code, model number and MAC address. 4. I have taken close up photos of the device with and without the covers off. The inside of the device holds two circuit boards with some components hidden between them, I have taken photos or the outward facing sides of the two boards. I have posted the photos at these URLs: http://www.jbohm.org/930C/frontAndCable.jpg http://www.jbohm.org/930C/back.jpg http://www.jbohm.org/930C/boardFront.jpg http://www.jbohm.org/930C/boardBack.jpg (Please copy the photos to your own archives, these are temporary URLs). And finally something worth investigating: Some time has passed since Micronas Lawyers blocked the release of the FOSS driver for their chipset, maybe they have cooled down now and someone from the linuxtv project could approach Hauppauge or Pinacle (who seem FOSS-friendly) to put business pressure on their chipset supplier Micronas to reverse their decision and permit the release of the FOSS driver that was previously developped in cooperation between Pinacle, Micronas techs and Devin Heitmueller (one of the linuxtv developers). Sincerely, and hoping this helps things move forward in at least some direction Jakob Bohm -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More details on Hauppauge 930C
On Mon, Jan 25, 2010 at 3:11 AM, Jakob Bohm saotowjokkoujux...@jbohm.dk wrote: So far all the posts I have been able to find about this device on wiki.linuxtv.org and in the archives of the linux-tv, linux-dvb and linux-media mailing lists have been unconfirmed guesswork of the form I think, Isn't that etc. I actually have this device (it was the first DVB-C device to hit the market in Denmark after our biggest cable TV provider offered unencrypted access to their basic packages in DVB-C format for anyone with a paid physical connection to their network). Ok, first the bad news: When looking inside the device I see two Micronas chips, thus *apparantly* confirming the rumors about this device being based on the Micronas chips for which Micronas lawyers blocked release of an already written FOSS driver back in 2008. But to be sure these are the banned chips, someone in the know should look closely at the photos I have taken of the actual chips in the 930C. Second bad news: When asking Hauppauge all the response I got was You need to post on the www.linuxtv.org site, that's where the devlopers are (and thats all the e-mail said, including the spelling mistake in devlopers). Now the observable facts: 1. Product name is Hauppauge 930C, model 16009 LF Rev B1F0, USB ID 2040:1605 . Retail package includes device, a short video cable adapter for the minisocket on the device, an IR remote, a small table-top retractable antenna and a CD with MS-Windows software and drivers. 2. Device is a combined DVB-C/DVB-T receiver with additional inputs for raw analog video as S-VHS or composite (either with separate analog stereo sound). I do not recall if the device has support for analog TV reception too. 3. Device is not yet listed in the device tables at linuxtv.org with any status (not even doesn't work). 4. Device is a large (= wide body) USB stick, with a standard size coaxial antenna input at the back, two indicator LEDs and an IR receiver on the right and a proprietary mini-socket for analog video/audio input on the left. The underside has a sticker with bar code, model number and MAC address. 4. I have taken close up photos of the device with and without the covers off. The inside of the device holds two circuit boards with some components hidden between them, I have taken photos or the outward facing sides of the two boards. I have posted the photos at these URLs: http://www.jbohm.org/930C/frontAndCable.jpg http://www.jbohm.org/930C/back.jpg http://www.jbohm.org/930C/boardFront.jpg http://www.jbohm.org/930C/boardBack.jpg (Please copy the photos to your own archives, these are temporary URLs). And finally something worth investigating: Some time has passed since Micronas Lawyers blocked the release of the FOSS driver for their chipset, maybe they have cooled down now and someone from the linuxtv project could approach Hauppauge or Pinacle (who seem FOSS-friendly) to put business pressure on their chipset supplier Micronas to reverse their decision and permit the release of the FOSS driver that was previously developped in cooperation between Pinacle, Micronas techs and Devin Heitmueller (one of the linuxtv developers). It hasn't been in Micronas hands for a long time anymore. Micronas had financial trouble and sold this devision to Trident. So far we (Sundtek) found an agreement to publish their propriertary work under closed source but with support for opensource applications in Linux in userspace not affecting the kernel. Best Regards, Markus -- 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
