Re: [cron job] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
On Saturday 28 February 2009 01:32:42 Mauro Carvalho Chehab wrote: On Fri, 27 Feb 2009 19:49:56 +0100 (CET) Hans Verkuil hverk...@xs4all.nl wrote: (This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below.) Results of the daily build of v4l-dvb: linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: ERRORS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29-rc5-i686: ERRORS Wow! Lots of errors! Ok, I've removed tvmixer and marked the minimal version for firedtv. This should fix the issues. Cheers, Mauro I've started an extra build to see what (if any) errors/warnings remain after all these big merges. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Sat Feb 28 09:45:19 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10778:c770b20d15c6 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc5-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc5-armv5-omap2: OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc5-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-rc5-m32r: OK linux-2.6.16.61-mips: ERRORS linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc5-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-rc5-powerpc64: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29-rc5-x86_64: WARNINGS fw/apps: WARNINGS spec: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc5): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits
On Fri, 2009-02-27 at 21:05 +0200, Igor M. Liplianin wrote:
On 27 февраля 2009, Igor M. Liplianin liplia...@tut.by wrote:
On Fri, 27 Feb 2009, Igor M. Liplianin wrote:
01/02: dm1105: not demuxing from interrupt context.
http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=6
faf0753950b
I'm not sure if you considered this, but the default work queue is
multi-threaded with a kernel thread for each CPU. This means that if the
IRQ handler calls schedule_work() while your work function is running then
you can get a second copy running of your work function running at the same
time. It doesn't look like your work function uses atomit_t or locking, so
I'm guessing it's not safe to run concurrently.
For the pluto2 patch, I created a single threaded work queue. This avoids
the concurrency problem and it's not like the demuxer can run in parallel
anyway. Having your own work queue also means that you don't have to worry
about latency from whatever other tasks might be in the default work queue.
Also consider that the work function is queued mutliple times before it
runs, it will only run once. I.e. queuing a work func that's already in
the queue does nothing (one the function starts to run, it's no longer in
the queue and can be added again before it's finished). The pluto2 patch I
posted didn't take this into account, but I've since fixed it.
I'll return to this :)
But it complicates things more and more :(
Yes it does complicate things. Here are some excerpts from what I had
to do for cx18. Perhaps it will help you. (Or perhaps it will not help
at all. The CX23418 chip put alot of requirements on me that drove my
solution.)
-
cx18-driver.h:
-
struct cx18_epu_work_order {
struct work_struct work;
atomic_t pending;
struct cx18 *cx;
unsigned long flags;
int rpu;
struct cx18_mailbox mb;
...
};
struct cx18 {
...
struct workqueue_struct *work_queue;
struct cx18_epu_work_order epu_work_order[CX18_MAX_EPU_WORK_ORDERS];
...
};
-
cx18-driver.c:
-
static int __devinit cx18_init_struct1(struct cx18 *cx)
{
int i;
...
cx-work_queue = create_singlethread_workqueue(cx-v4l2_dev.name);
if (cx-work_queue == NULL) {
CX18_ERR(Unable to create work hander thread\n);
return -ENOMEM;
}
for (i = 0; i CX18_MAX_EPU_WORK_ORDERS; i++) {
cx-epu_work_order[i].cx = cx;
...
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 20)
INIT_WORK(cx-epu_work_order[i].work, cx18_epu_work_handler);
#else
INIT_WORK(cx-epu_work_order[i].work, cx18_epu_work_handler,
cx-epu_work_order[i].work);
#endif
}
...
}
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 22)
static void cx18_cancel_epu_work_orders(struct cx18 *cx)
{
int i;
for (i = 0; i CX18_MAX_EPU_WORK_ORDERS; i++)
cancel_work_sync(cx-epu_work_order[i].work);
}
#endif
static void cx18_remove(struct pci_dev *pci_dev)
{
...
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 22)
cx18_sw2_irq_disable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
cx18_halt_firmware(cx);
cx18_cancel_epu_work_orders(cx);
#else
flush_workqueue(cx-work_queue);
cx18_sw2_irq_disable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
cx18_halt_firmware(cx);
#endif
destroy_workqueue(cx-work_queue);
...
}
--
cx18-irq.c:
--
static void epu_cmd(struct cx18 *cx, u32 sw1)
{
if (sw1 IRQ_CPU_TO_EPU)
cx18_api_epu_cmd_irq(cx, CPU);
if (sw1 IRQ_APU_TO_EPU)
cx18_api_epu_cmd_irq(cx, APU);
}
irqreturn_t cx18_irq_handler(int irq, void *dev_id)
{
struct cx18 *cx = (struct cx18 *)dev_id;
u32 sw1, sw2, hw2;
sw1 = cx18_read_reg(cx, SW1_INT_STATUS) cx-sw1_irq_mask;
...
if (sw1)
cx18_write_reg_expect(cx, sw1, SW1_INT_STATUS, ~sw1, sw1);
...
if (sw1)
epu_cmd(cx, sw1);
...
}
--
cx18-mailbox.c:
--
static inline
struct cx18_epu_work_order *alloc_epu_work_order_irq(struct cx18 *cx)
{
int i;
struct cx18_epu_work_order *order = NULL;
for (i = 0; i CX18_MAX_EPU_WORK_ORDERS; i++) {
/*
* We only need pending atomic to inspect its contents,
* and need not do a check and set because:
* 1. Any work handler thread only clears pending and only
* on one, particular work order at a time, per handler thread.
* 2. pending is only set here, and we're serialized because
* we're called in an IRQ handler context.
*/
Cinergy HTC USB XS HD, DVB-C suported ?
Hi, Can anyone verify if the Cinergy HTC USB XS HD is working in DVB-C mode ? http://www.terratec.net/en/products/technical-data/produkte_technische_daten_en_57350.html Sorry for adding to the signal noise ratio, I´ll promise to update the wiki. /Henrik -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cinergy HTC USB XS HD, DVB-C suported ?
On Sat, Feb 28, 2009 at 3:20 PM, Henrik Beckman henrik.l...@gmail.com wrote: Hi, Can anyone verify if the Cinergy HTC USB XS HD is working in DVB-C mode ? http://www.terratec.net/en/products/technical-data/produkte_technische_daten_en_57350.html Sorry for adding to the signal noise ratio, I´ll promise to update the wiki. it is fully working (DVB-C, DVB-T, analog TV and radio), some things have to be cleared up before the drivers will be published. http://mcentral.de/wiki/index.php5/Terratec_HTC_XS 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
[PULL] http://udev.netup.ru/hg/v4l-dvb-netup
Mauro, It is driver for NetUP Dual DVB-S2 CI PCI-e card. You can find short description of it on linuxtv wiki. Please pull from http://udev.netup.ru/hg/v4l-dvb-netup for the following 11 changesets: 01/11: Add init code for NetUP Dual DVB-S2 CI card http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=f752e18dc395 02/11: Add EEPROM code for NetUP Dual DVB-S2 CI card. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=5c764157d510 03/11: Add CIMax(R) SP2 Common Interface code for NetUP Dual DVB-S2 CI card http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=7af6715bacec 04/11: Add support for ST STV6110 silicon tuner. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=68ca5a26e7a5 05/11: Add support for ST LNBH24 LNB power controller. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=3b65476f39a9 06/11: Add headers for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=8dd572ce00ae 07/11: Add more headers for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=d29394751223 08/11: Add core code for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=59492f22aebe 09/11: Add support for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=df4fbc0c5b7e 10/11: Add support for NetUP Dual DVB-S2 CI card http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=5b9ba251e7dc 11/11: stv0900 fixes http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=e5c9e5d75291 b/linux/drivers/media/dvb/frontends/cimax2.c | 531 ++ b/linux/drivers/media/dvb/frontends/cimax2.h | 45 b/linux/drivers/media/dvb/frontends/lnbh24.h | 55 b/linux/drivers/media/dvb/frontends/netup-init.c | 143 b/linux/drivers/media/dvb/frontends/netup-init.h | 25 b/linux/drivers/media/dvb/frontends/stv0900.h | 62 b/linux/drivers/media/dvb/frontends/stv0900_core.c | 1961 ++ b/linux/drivers/media/dvb/frontends/stv0900_init.h | 428 ++ b/linux/drivers/media/dvb/frontends/stv0900_priv.h | 430 ++ b/linux/drivers/media/dvb/frontends/stv0900_reg.h | 3787 + b/linux/drivers/media/dvb/frontends/stv0900_sw.c | 2847 +++ b/linux/drivers/media/dvb/frontends/stv6110.c | 457 ++ b/linux/drivers/media/dvb/frontends/stv6110.h | 62 b/linux/drivers/media/video/cx23885/netup-eeprom.c | 117 b/linux/drivers/media/video/cx23885/netup-eeprom.h | 42 linux/Documentation/video4linux/CARDLIST.cx23885 | 1 linux/drivers/media/dvb/frontends/Kconfig | 21 linux/drivers/media/dvb/frontends/Makefile | 4 linux/drivers/media/dvb/frontends/lnbp21.c | 33 linux/drivers/media/dvb/frontends/lnbp21.h | 50 linux/drivers/media/dvb/frontends/stv0900_core.c | 2 linux/drivers/media/dvb/frontends/stv0900_init.h | 17 linux/drivers/media/video/cx23885/Kconfig | 1 linux/drivers/media/video/cx23885/Makefile | 4 linux/drivers/media/video/cx23885/cx23885-cards.c | 50 linux/drivers/media/video/cx23885/cx23885-dvb.c | 106 linux/drivers/media/video/cx23885/cx23885.h | 2 27 files changed, 11255 insertions(+), 28 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
Re: Topro 6800 driver
Jean-Francois Moine wrote: On Fri, 27 Feb 2009 23:15:54 +0100 Anders Blomdell anders.blomd...@control.lth.se wrote: Hi, I'm trying to write a driver for a webcam based on Topro TP6801/CX0342 (06a2:0003). My first attempt (needs gspca) can be found on: http://www.control.lth.se/user/andersb/tp6800.c Unfortunately the JPEG images (one example dump is in http://www.control.lth.se/user/andersb/topro_img_dump.txt), seems to be bogus, they start with (data is very similar to windows data): : 0xff,0xd8,0xff,0xfe,0x28,0x3c,0x01,0xe8,... ... c340: ...,0xf4,0xc0,0xff,0xd9 Anybody who has a good idea of how to find a DQT/Huffman table that works with this image data? Hi Anders, Thomas Champagne (See To:) was also writing a driver for this webcam. Maybe you may merge your codes... Thomas, if you have DQT/Huffman tables for this camera, please drop me a note. About the JPEG images, the Huffman table is always the same Does this mean that it's the same for all JPEG images or only for one camera? If it's the same for all images, it should mean that I have a way to determine how much I have to chop off after the 0xfffe tag (no illegal huffman codes - possibly chop at the correct position). Comments anyone? and the quantization tables depend on the compression quality. From the USB trace I had from Thomas, I saw that: - when a packet starts with '55 ff d8', it is the first part of the image. This one should start at the offset 8 of the packet. - when a packet starts with 'cc', it is the next part of the image. This is even in the docs, and is implemented in the driver. In the function pkt_scan, when finding the image start, you must add the JPEG header: 'ff d8', DQT, huffman table, SOF0 and SOS. OK, will see if I can find the DQT (and possibly the Huffman table) in the windows driver (as suggested by Thomas Kaiser). As we don't know the quality used by the webcam, in my test repository, I added a control for that: the JPEG header is created at streamon time, and the quantization tables may be modified by the control on the fly (have a look at stk014.c for an example). This solution is not the right one: the JPEG quality must be set by the VIDIOC_S_JPEGCOMP ioctl instead of VIDIOC_S_CTRL. I think I will update the concerned subdrivers next week. I'll look into that monday. BTW, don't use the video4linux-l...@redhat.com mailing-list anymore: all the video discussions are now done in linux-me...@vger.kernel.org. OK, so Google hit http://www.linuxtv.org/v4lwiki/index.php/Main_Page is no hit then... Thanks Anders Blomdell -- 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: Topro 6800 driver
Hello Anders Anders Blomdell wrote: Jean-Francois Moine wrote: On Fri, 27 Feb 2009 23:15:54 +0100 About the JPEG images, the Huffman table is always the same Does this mean that it's the same for all JPEG images or only for one camera? If it's the same for all images, it should mean that I have a way to determine how much I have to chop off after the 0xfffe tag (no illegal huffman codes - possibly chop at the correct position). Comments anyone? As per definition of JPEG, the Huffman table is always calculated especially for each picture to get the best compression. Thus the Huffman table and the DQT has to be in the JPEG stream like you see on JPEG picture on your HD. With webcams, it is a bit an other story. The webcam hardware is usually not powerful enough to calculate the Huffman table for each frame. Therefor a static Huffman table is used. This Huffman table should fit more less to the image the camera is producing. With the drawback that we cannot achieve the highest compression possible. On the other hand the Huffman table is always the same the cam has not to send this in the video stream and the stream has less overhead. In short, the Huffman table is always the same for a given webcam. I don't think 0xfffe is a valid JPEG marker. 0xfffe is a comment marker and the next 2 bytes after this markers tells the length of the comment (including the two length byte). So, your comment would be 10300 Bytes long. I don't think that such many Bytes are used for a comment when they try to have as less as possible overhead. I think 0xfffe is the start of the compressed data stream and has nothing to do with JPEG markers. Thomas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx18
On Thu, 2009-02-26 at 22:25 -0300, Mauro Carvalho Chehab wrote: On Sat, 21 Feb 2009 21:22:22 -0500 Andy Walls awa...@radix.net wrote: cx18: Change log lines for internal subdevs and fix tveeprom reads + strncpy(c.name, cx18 tveeprom tmp, sizeof(c.name)); + c.name[sizeof(c.name)-1] = '\0'; Please use strlcpy() instead. Sure. I'm checking the change now. I'll issue a pull request later this weekend. cx18: Convert the integrated A/V decoder core interface to a v4l2_subdev There were some merge conflicts. I've fixed it by hand, but I suspect that you'll need to properly tune the default values for v4l2_ctrl_query_fill(). Please review my last patch and fix it accordingly with the limits of each V4L2_CID. Sorry I didn't get to this sooner (I was traveling). I see you've already fixed the values. Your fixes are as Hans had intended them for cx18. Thanks. Regards, Andy Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Vote please: DVB developers opinion is wanted!
Hi, I would like to know if anyone of you has any objections against the following patch: It remove two obsolete text files in /Documentation/dvb. 1. They do not contain any technical information that is making sense. 2. The correct place for mentioning a developer's or contributor's name is a file header, but not a text file in case we're talking about a driver file, not a documentation text file. 3. These two files are NEVER administered or maintained, that is why they are not only useless but furthermore completely out of date. --- a/Documentation/dvb/contributors.txt2008-12-25 00:26:37.0 +0100 +++ b/Documentation/dvb/contributors.txt1970-01-01 01:00:00.0 +0100 @@ -1,96 +0,0 @@ -Thanks go to the following people for patches and contributions: - -Michael Hunold m.hun...@gmx.de - for the initial saa7146 driver and it's recent overhaul - -Christian Theiss - for his work on the initial Linux DVB driver - -Marcus Metzler m...@metzlerbros.de -Ralph Metzler r...@metzlerbros.de - for their continuing work on the DVB driver - -Michael Holzt k...@debian.org - for his contributions to the dvb-net driver - -Diego Picciani d.picci...@novacomp.it - for CyberLogin for Linux which allows logging onto EON - (in case you are wondering where CyberLogin is, EON changed its login - procedure and CyberLogin is no longer used.) - -Martin Schaller mar...@smurf.franken.de - for patching the cable card decoder driver - -Klaus Schmidinger klaus.schmidin...@cadsoft.de - for various fixes regarding tuning, OSD and CI stuff and his work on VDR - -Steve Brown sbr...@cortland.com - for his AFC kernel thread - -Christoph Martin mar...@uni-mainz.de - for his LIRC infrared handler - -Andreas Oberritter o...@linuxtv.org -Dennis Noermann dennis.noerm...@noernet.de -Felix Domke tmb...@elitedvb.net -Florian Schirmer j...@tuxbox.org -Ronny Strutz 3...@elitedvb.de -Wolfram Joost db...@frokaschwei.de -...and all the other dbox2 people - for many bugfixes in the generic DVB Core, frontend drivers and - their work on the dbox2 port of the DVB driver - -Oliver Endriss o.endr...@gmx.de - for many bugfixes - -Andrew de Quincey adq_...@lidskialf.net - for the tda1004x frontend driver, and various bugfixes - -Peter Schildmann peter.schildm...@web.de - for the driver for the Technisat SkyStar2 PCI DVB card - -Vadim Catana skys...@moldova.cc -Roberto Ragusa r.rag...@libero.it -Augusto Cardoso augu...@carhil.net - for all the work for the FlexCopII chipset by B2C2,Inc. - -Davor Emard em...@softhome.net - for his work on the budget drivers, the demux code, - the module unloading problems, ... - -Hans-Frieder Vogt hfv...@arcor.de - for his work on calculating and checking the crc's for the - TechnoTrend/Hauppauge DEC driver firmware - -Michael Dreher mich...@5dot1.de -Andreas 'randy' Weinberger - for the support of the Fujitsu-Siemens Activy budget DVB-S - -Kenneth Aafløy ke...@frisurf.no - for adding support for Typhoon DVB-S budget card - -Ernst Peinlich e.peinl...@inode.at - for tuning/DiSEqC support for the DEC 3000-s - -Peter Beutner p.beut...@gmx.net - for the IR code for the ttusb-dec driver - -Wilson Michaels wilsonmicha...@earthlink.net - for the lgdt330x frontend driver, and various bugfixes - -Michael Krufky mkru...@m1k.net - for maintaining v4l/dvb inter-tree dependencies - -Taylor Jacob rtja...@earthlink.net - for the nxt2002 frontend driver - -Jean-Francois Thibert jeanfranc...@sagetv.com - for the nxt2004 frontend driver - -Kirk Lapray kirk.lap...@gmail.com - for the or51211 and or51132 frontend drivers, and - for merging the nxt2002 and nxt2004 modules into a - single nxt200x frontend driver. - -(If you think you should be in this list, but you are not, drop a - line to the DVB mailing list) --- a/Documentation/dvb/readme.txt 2008-12-25 00:26:37.0 +0100 +++ b/Documentation/dvb/readme.txt 1970-01-01 01:00:00.0 +0100 @@ -1,62 +0,0 @@ -Linux Digital Video Broadcast (DVB) subsystem -= - -The main development site and CVS repository for these -drivers is http://linuxtv.org/. - -The developer mailing list linux-dvb is also hosted there, -see http://linuxtv.org/lists.php. Please check -the archive http://linuxtv.org/pipermail/linux-dvb/ -and the Wiki http://linuxtv.org/wiki/ -before asking newbie questions on the list. - -API documentation, utilities and test/example programs -are available as part of the old driver package for Linux 2.4 -(linuxtv-dvb-1.0.x.tar.gz), or from CVS (module DVB). -We plan to split this into separate packages, but it's not -been done yet. - -http://linuxtv.org/downloads/ - -What's inside this directory: - -avermedia.txt -contains detailed information about the -Avermedia DVB-T cards. See also bt8xx.txt. - -bt8xx.txt -contains detailed information about the -various bt8xx based budget DVB cards. - -cards.txt -contains a list of supported hardware. - -ci.txt -contains detailed
[PATCH] Add support for GeoVision GV-800(S)
Hello all, I have a GeoVision GV-800(S) card, it has 4 CONEXANT BT878A chips. It has 16 video inputs and 4 audio inputs, and it is almost identical to the GV-800, as seen on http://bttv-gallery.de . The only difference appears to be the analog mux, it has a CD22M3494 in place of the MT8816AP. The card has a blue PCB, as seen in this picture: http://www.gsbr.com.br/imagem/kits/GeoVision%20GV%20800.jpg . This card wasn't originally supported, and it was detected as UNKNOWN/GENERIC. The video inputs weren't working, so I tried forcing a few cards like the GeoVision GV-600, but there was still no video. So I made a patch to support this card, based on the Kodicom 4400r. The GV-800(S) is identified as follows: # lspci ... 02:00.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 02:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 02:04.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 02:04.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 02:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 02:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 02:0c.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 02:0c.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) # lspci -nv ... 02:00.0 0400: 109e:036e (rev 11) Subsystem: 800a:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdfff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Kernel modules: bttv 02:00.1 0480: 109e:0878 (rev 11) Subsystem: 800a:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 02:04.0 0400: 109e:036e (rev 11) Subsystem: 800b:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffd000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Kernel modules: bttv 02:04.1 0480: 109e:0878 (rev 11) Subsystem: 800b:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffc000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 02:08.0 0400: 109e:036e (rev 11) Subsystem: 800c:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffb000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Kernel modules: bttv 02:08.1 0480: 109e:0878 (rev 11) Subsystem: 800c:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffa000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 02:0c.0 0400: 109e:036e (rev 11) Subsystem: 800d:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdff9000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Kernel modules: bttv 02:0c.1 0480: 109e:0878 (rev 11) Subsystem: 800d:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdff8000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 As you can see, the GV-800(S) card is almost identical to the GV-800 on bttv-gallery, so this patch might also work for that card. If not, only a few changes should be required on the gv800s_write() function. After this patch, the video inputs work correctly. The input order may seem a little odd, but it's the order the original software/driver uses, and I decided to keep that order to get the most out of the card. I tried to get the audio working with the snd-bt87x module, but I only get noise from every audio input, even after selecting a different mux with alsamixer. Also, after trying to play sound from those sources, I randomly get a RISC error about an invalid RISC opcode, and then that output stops working. I also can't change the sampling rate when recording. Any pointers to adding audio support are welcome. Signed-off-by: Bruno Christo bchri...@inf.ufsm.br diff -r c770b20d15c6 linux/Documentation/video4linux/CARDLIST.bttv --- a/linux/Documentation/video4linux/CARDLIST.bttv Fri Feb 27 21:29:59 2009 -0300 +++ b/linux/Documentation/video4linux/CARDLIST.bttv Fri Feb 27 22:12:29 2009 -0300 @@ -155,3 +155,5 @@ 154 - PHYTEC VD-012-X1
HVR3000 v4l no longer compiles with any branch and/or patch in 64bitOS
I get this error when compiling v4l-dvb 7285 and 7879 (can't find patch via the links, their in the tmp directory?) under ubuntu hardy 2.6.24-23-rt amd64: /home/vivy/v4l-dvb/v4l/saa7134-video.c: In function 'saa7134_s_fmt_overlay': /home/vivy/v4l-dvb/v4l/saa7134-video.c:1674: error: size of array 'type name' is negative /home/vivy/v4l-dvb/v4l/saa7134-video.c:1674: warning: comparison of distinct pointer types lacks a cast /home/vivy/v4l-dvb/v4l/saa7134-video.c:1677: error: size of array 'type name' is negative /home/vivy/v4l-dvb/v4l/saa7134-video.c:1677: warning: comparison of distinct pointer types lacks a cast make[3]: *** [/home/vivy/v4l-dvb/v4l/saa7134-video.o] Error 1 make[2]: *** [_module_/home/vivy/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-23-rt' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/vivy/v4l-dvb/v4l' make: *** [all] Error 2 which compiled and worked before I had to reinstall (from 32bit to 64bit)ubuntu from scratch. think I mite be missing some installed source code somewhere or is not amd64 compatible code. as for 8894 I think I remember it compiling but just no dvb-s even though its mfe. dvb-s is really what I want -- 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/RFC 1/4] ipu_idmac: code clean-up and robustness improvements
Hi Guennadi,
I am having trouble while probing ipu idmac:
At boot:
ipu-core: probe of ipu-core failed with error -22
Which is apparently happening at ipu_idmac:1706:
1695 static int __init ipu_probe(struct platform_device *pdev)
...
1703 mem_ipu = platform_get_resource(pdev, IORESOURCE_MEM, 0);
1704 mem_ic = platform_get_resource(pdev, IORESOURCE_MEM, 1);
1705 if (!pdata || !mem_ipu || !mem_ic)
1706 return -EINVAL;
Later on, I get error 16, Device or resource busy on VIDIOC_S_FMT, apparently
because mx3_camera can't get its dma channel.
Any clue?
--
Agustin Ferrin Pozuelo
Embedded Systems Consultant
http://embedded.ferrin.org/
--- On 18/2/09, Guennadi Liakhovetski wrote:
From: Guennadi Liakhovetski l...@denx.de
General code clean-up: remove superfluous semicolons, update comments.
Robustness improvements: add DMA error handling to the ISR, move common code
fragments to functions, fix scatter-gather element queuing in the ISR, survive
channel freeing and re-allocation in a quick succession.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
As mentioned in PATCH 0/4 this one is only for completeness / testing
here, will be submitted separately to the dmaengine queue. Dan, would be
good if you could review it here to save time.
drivers/dma/ipu/ipu_idmac.c | 300 ---
1 files changed, 196 insertions(+), 104 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index 1f154d0..91e6e4e 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -28,6 +28,9 @@
#define FS_VF_IN_VALID 0x0002
#define FS_ENC_IN_VALID0x0001
+static int ipu_disable_channel(struct idmac *idmac, struct idmac_channel
*ichan,
+ bool wait_for_stop);
+
/*
* There can be only one, we could allocate it dynamically, but then we'd
have
* to add an extra parameter to some functions, and use something as ugly as
@@ -107,7 +110,7 @@ static uint32_t bytes_per_pixel(enum pixel_fmt fmt)
}
}
-/* Enable / disable direct write to memory by the Camera Sensor Interface */
+/* Enable direct write to memory by the Camera Sensor Interface */
static void ipu_ic_enable_task(struct ipu *ipu, enum ipu_channel channel)
{
uint32_t ic_conf, mask;
@@ -126,6 +129,7 @@ static void ipu_ic_enable_task(struct ipu *ipu, enum
ipu_channel channel)
idmac_write_icreg(ipu, ic_conf, IC_CONF);
}
+/* Called under spin_lock_irqsave(ipu_data.lock) */
static void ipu_ic_disable_task(struct ipu *ipu, enum ipu_channel channel)
{
uint32_t ic_conf, mask;
@@ -422,7 +426,7 @@ static void ipu_ch_param_set_size(union chan_param_mem
*params,
break;
default:
dev_err(ipu_data.dev,
- mxc ipu: unimplemented pixel format %d\n, pixel_fmt);
+ mx3 ipu: unimplemented pixel format %d\n, pixel_fmt);
break;
}
@@ -433,20 +437,20 @@ static void ipu_ch_param_set_burst_size(union
chan_param_mem *params,
uint16_t burst_pixels)
{
params-pp.npb = burst_pixels - 1;
-};
+}
static void ipu_ch_param_set_buffer(union chan_param_mem *params,
dma_addr_t buf0, dma_addr_t buf1)
{
params-pp.eba0 = buf0;
params-pp.eba1 = buf1;
-};
+}
static void ipu_ch_param_set_rotation(union chan_param_mem *params,
enum ipu_rotate_mode rotate)
{
params-pp.bam = rotate;
-};
+}
static void ipu_write_param_mem(uint32_t addr, uint32_t *data,
uint32_t num_words)
@@ -571,7 +575,7 @@ static uint32_t dma_param_addr(uint32_t dma_ch)
{
/* Channel Parameter Memory */
return 0x1 | (dma_ch 4);
-};
+}
static void ipu_channel_set_priority(struct ipu *ipu, enum ipu_channel
channel,
bool prio)
@@ -611,7 +615,8 @@ static uint32_t ipu_channel_conf_mask(enum ipu_channel
channel)
/**
* ipu_enable_channel() - enable an IPU channel.
- * @channel: channel ID.
+ * @idmac: IPU DMAC context.
+ * @ichan: IDMAC channel.
* @return:0 on success or negative error code on failure.
*/
static int ipu_enable_channel(struct idmac *idmac, struct idmac_channel
*ichan)
@@ -649,7 +654,7 @@ static int ipu_enable_channel(struct idmac *idmac, struct
idmac_channel *ichan)
/**
* ipu_init_channel_buffer() - initialize a buffer for logical IPU channel.
- * @channel: channel ID.
+ * @ichan: IDMAC channel.
* @pixel_fmt: pixel format of buffer. Pixel format is a FOURCC ASCII code.
* @width: width of buffer in pixels.
* @height:height of buffer in pixels.
@@ -687,7 +692,7 @@ static int ipu_init_channel_buffer(struct idmac_channel
*ichan,
}
/* IC channel's stride must be a multiple of 8 pixels */
- if
Re: [PATCH/RFC 1/4] ipu_idmac: code clean-up and robustness improvements
On Sat, 28 Feb 2009, Agustin wrote: Hi Guennadi, I am having trouble while probing ipu idmac: At boot: ipu-core: probe of ipu-core failed with error -22 Which is apparently happening at ipu_idmac:1706: 1695 static int __init ipu_probe(struct platform_device *pdev) ... 1703 mem_ipu = platform_get_resource(pdev, IORESOURCE_MEM, 0); 1704 mem_ic = platform_get_resource(pdev, IORESOURCE_MEM, 1); 1705 if (!pdata || !mem_ipu || !mem_ic) 1706 return -EINVAL; Later on, I get error 16, Device or resource busy on VIDIOC_S_FMT, apparently because mx3_camera can't get its dma channel. Any clue? Are you sure it is failing here, have you verified with a printk? If it is indeed this place, then you probably didn't register all required resources in your platfom code. Look at my platform-bindings patch. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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
Recommendation for good example i2c driver code
When writing a new driver, which existing driver would be a good model to use for handing the i2c bus? Bill -- 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: Recommendation for good example i2c driver code
On Saturday 28 February 2009 23:18:54 William M. Brack wrote: When writing a new driver, which existing driver would be a good model to use for handing the i2c bus? Hi Bill, I recommend reading Documents/video4linux/v4l2-framework.txt. It's not clear from your question whether you want an example driver for an i2c device, or an example for how to use i2c devices in an PCI or USB driver. A simple, but decent example source for the first would be wm8739.c and for the second we have saa7134 or cx18. It's a bit in flux at the moment since we are moving all drivers over to the v4l2_device/v4l2_subdev structure, but some still use the old model. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Recommendation for good example i2c driver code
On Sun, 2009-03-01 at 00:01 +0100, Hans Verkuil wrote: On Saturday 28 February 2009 23:18:54 William M. Brack wrote: When writing a new driver, which existing driver would be a good model to use for handing the i2c bus? Hi Bill, I recommend reading Documents/video4linux/v4l2-framework.txt. It's not clear from your question whether you want an example driver for an i2c device, or an example for how to use i2c devices in an PCI or USB driver. A simple, but decent example source for the first would be wm8739.c and for the second we have saa7134 or cx18. It's a bit in flux at the moment since we are moving all drivers over to the v4l2_device/v4l2_subdev structure, but some still use the old model. Bill, Your question also did not specify if this was a driver for an analog (V4L2) or DTV (DVB) capture unit. Hans' comments regarding v4l2_device/v4l2_subdev currently only apply to analog capture units or the analog side of hybrid capture units. If you have a DTV-only capture unit, the v4l2_device/v4l2_subdevice framework doesn't apply at present. AFAICT, the saa7134 and cx18 drivers both have code to deal with hybrid analog/DTV units. Regards, Andy Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx88: Add IR support to pcHDTV HD3000 HD5500
cx88: Add IR support to pcHDTV HD3000 HD5500 Signed-off-by: Erik S. Beiser er...@bu.edu --- Idea originally from http://www.pchdtv.com/forum/viewtopic.php?t=1529 I made it into this small patch and added the HD3000 support also, which I have I've actually been using this for over a year, updating for new kernel versions. I'm tired of doing so, and would like to try and have it merged upstream -- I hope I got all the patch-mechanics correct. I just updated and tested it today on 2.6.28.7 vanilla. Thanks. --- linux/drivers/media/video/cx88/cx88-input.c.orig2009-02-20 17:41:27.0 -0500 +++ linux/drivers/media/video/cx88/cx88-input.c 2009-02-28 15:58:34.0 -0500 @@ -226,6 +226,8 @@ int cx88_ir_init(struct cx88_core *core, case CX88_BOARD_HAUPPAUGE_HVR3000: case CX88_BOARD_HAUPPAUGE_HVR4000: case CX88_BOARD_HAUPPAUGE_HVR4000LITE: + case CX88_BOARD_PCHDTV_HD3000: + case CX88_BOARD_PCHDTV_HD5500: ir_codes = ir_codes_hauppauge_new; ir_type = IR_TYPE_RC5; ir-sampling = 1; @@ -466,6 +468,8 @@ void cx88_ir_irq(struct cx88_core *core) case CX88_BOARD_HAUPPAUGE_HVR3000: case CX88_BOARD_HAUPPAUGE_HVR4000: case CX88_BOARD_HAUPPAUGE_HVR4000LITE: + case CX88_BOARD_PCHDTV_HD3000: + case CX88_BOARD_PCHDTV_HD5500: ircode = ir_decode_biphase(ir-samples, ir-scount, 5, 7); ir_dprintk(biphase decoded: %x\n, ircode); /* -- 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
Lifeview FlyDVB Hybrid PCI (LR-306N): doesn't work anymore
Hi, I own a Lifeview FlyDVB Hybrid LR-306N model; it is a PCI model, and I've been happily using it with my Mythtv for a couple of years, despite it was identified as a Cardbus model. About two months ago, I have upgraded kernel, and since then DVB function doesn't work anymore. I've checked what's changed, and I've noticed /var/log/messages once was something like: Dec 28 14:07:02 mumonkan kernel: [ 56.651901] saa7130/34: v4l2 driver version 0.2.14 loaded Dec 28 14:07:02 mumonkan kernel: [ 57.249000] saa7133[0]: found at :00:09.0, rev: 208, irq: 19, latency: 32, mmio: 0xfebfe800 Dec 28 14:07:02 mumonkan kernel: [ 57.249083] saa7133[0]: subsystem: 5168:3306, board: LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [card=94,autodetected] Dec 28 14:07:02 mumonkan kernel: [ 57.249173] saa7133[0]: board init: gpio is 21 Dec 28 14:07:02 mumonkan kernel: [ 57.381216] saa7133[0]: i2c eeprom 00: 68 51 06 33 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 Dec 28 14:07:02 mumonkan kernel: [ 57.382161] saa7133[0]: i2c eeprom 10: 00 00 62 08 ff 20 ff ff ff ff ff ff ff ff ff ff Dec 28 14:07:02 mumonkan kernel: [ 57.383096] saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff 01 16 ff ff ff ff Dec 28 14:07:02 mumonkan kernel: [ 57.384032] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Dec 28 14:07:02 mumonkan kernel: [ 57.384967] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 05 01 01 16 32 15 ff ff ff ff Dec 28 14:07:02 mumonkan kernel: [ 57.385911] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Dec 28 14:07:02 mumonkan kernel: [ 57.386848] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Dec 28 14:07:02 mumonkan kernel: [ 57.387783] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Dec 28 14:07:02 mumonkan kernel: [ 57.400815] saa7133[0]: registered device video0 [v4l2] Dec 28 14:07:02 mumonkan kernel: [ 57.400995] saa7133[0]: registered device vbi0 Dec 28 14:07:02 mumonkan kernel: [ 57.401173] saa7133[0]: registered device radio0 Dec 28 14:07:02 mumonkan kernel: [ 129.568135] DVB: registering new adapter (saa7133[0]) Dec 28 14:07:02 mumonkan kernel: [ 129.568234] DVB: registering frontend 0 (Philips TDA10046H DVB-T)... Dec 28 14:07:02 mumonkan kernel: [ 129.638878] tda1004x: setting up plls for 48MHz sampling clock Dec 28 14:07:02 mumonkan kernel: [ 131.632829] tda1004x: found firmware revision 29 -- ok Dec 28 14:07:31 mumonkan kernel: [ 214.693005] tda1004x: setting up plls for 48MHz sampling clock Dec 28 14:07:33 mumonkan kernel: [ 216.647008] tda1004x: found firmware revision 29 -- ok Now it goes like this: Feb 13 22:53:06 mumonkan [ 7.138352] saa7130/34: v4l2 driver version 0.2.14 loaded Feb 13 22:53:06 mumonkan [ 8.089793] saa7134 :00:09.0: PCI INT A - GSI 17 (level, low) - IRQ 17 Feb 13 22:53:06 mumonkan [ 8.089800] saa7133[0]: found at :00:09.0, rev: 208, irq: 17, latency: 32, mmio: 0xfebfe800 Feb 13 22:53:06 mumonkan [ 8.089808] saa7133[0]: subsystem: 5168:3306, board: LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [card=94,autodetected] Feb 13 22:53:06 mumonkan [ 8.089827] saa7133[0]: board init: gpio is 21 Feb 13 22:53:06 mumonkan [ 8.240008] saa7133[0]: i2c eeprom 00: 68 51 06 33 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 Feb 13 22:53:06 mumonkan [ 8.240019] saa7133[0]: i2c eeprom 10: 00 00 62 08 ff 20 ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240027] saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff 01 16 ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240036] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240044] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 05 01 01 16 32 15 ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240052] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240060] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240068] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240076] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240084] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240092] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240100] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240108] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240116] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan [ 8.240124] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Feb 13 22:53:06 mumonkan
Re: Topro 6800 driver
On Sat, 28 Feb 2009 16:11:36 +0100 Anders Blomdell anders.blomd...@control.lth.se wrote: Jean-Francois Moine wrote: Thomas Champagne (See To:) was also writing a driver for this webcam. Maybe you may merge your codes... Thomas, if you have DQT/Huffman tables for this camera, please drop me a note. About the JPEG images, the Huffman table is always the same Does this mean that it's the same for all JPEG images or only for one camera? If it's the same for all images, it should mean that I have a way to determine how much I have to chop off after the 0xfffe tag (no illegal huffman codes - possibly chop at the correct position). Comments anyone? I already explained it: - when a packet starts with '55 ff d8', it is the first part of the image. This one should start at the offset 8 of the packet. and the quantization tables depend on the compression quality. From the USB trace I had from Thomas, I saw that: - when a packet starts with '55 ff d8', it is the first part of the image. This one should start at the offset 8 of the packet. - when a packet starts with 'cc', it is the next part of the image. This is even in the docs, and is implemented in the driver. In the function pkt_scan, when finding the image start, you must add the JPEG header: 'ff d8', DQT, huffman table, SOF0 and SOS. OK, will see if I can find the DQT (and possibly the Huffman table) in the windows driver (as suggested by Thomas Kaiser). See below. As we don't know the quality used by the webcam, in my test repository, I added a control for that: the JPEG header is created at streamon time, and the quantization tables may be modified by the control on the fly (have a look at stk014.c for an example). This solution is not the right one: the JPEG quality must be set by the VIDIOC_S_JPEGCOMP ioctl instead of VIDIOC_S_CTRL. I think I will update the concerned subdrivers next week. I'll look into that monday. In gspca, the file jpeg.h contains all the material to build a complete JPEG header. With the new mechanism of my test repository, you must: - at streamon time (function sd_start): - allocate a buffer for the JPEG header, - set the resolution and number of samplesY (0x22 or 0x21) by the function jpeg_define, - set the quantization tables by the function jpeg_set_qual, the quality being in percent (15..95). - when getting the start of a new image in sd_pkt_scan, add the JPEG header as the first packet. - at streamoff time (function sd_stop0), free the JPEG header. - on VIDIOC_S_JPEGCOMP (function sd_set_jcomp which you must create), redefine the quantization tables by jpeg_set_qual. 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
